Private alliance chain-based service authorization method and apparatus, and electronic device

Abstract

The invention discloses a service authorization method and device based on a private alliance chain and electronic equipment. The method relates to the technical field of block chains, and comprises the steps of obtaining a current block height of a target block chain node in a private alliance chain at a current moment; under the condition that the current block height is greater than a preset height, based on a preset timed task, verifying a current authorization code held by the target block chain node through an authorization smart contract to obtain a verification result; when the verification result indicates that the verification of the current authorization code is passed, authorizing the target block chain node to use the target block chain node, and generating a target authorization code based on the authorization smart contract; and sending the target authorization code to the target block chain node, so that the target block chain node replaces the current authorization code with the target authorization code. According to the invention, the technical problem of low security of private alliance chain service authorization in a private cloud environment is solved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a service authorization method, device, and electronic device based on a private alliance chain. Background Art

[0002] With the rapid development of cloud computing, virtualization, and blockchain technologies, software service authorization management faces unprecedented challenges and opportunities. In traditional software authorization models, authorization is typically tied to a specific host based on hardware fingerprints, Media Access Control (MAC) addresses, or fixed IP addresses, limiting the scope of software use and copying. However, with the proliferation of cloud services and the increasing complexity of private cloud environments, traditional authorization management approaches have exposed serious limitations and security risks. In private cloud environments, data and applications often run across multiple servers and virtual machines, making traditional hardware-identity-based authorization approaches difficult to adapt to this dynamic landscape. On the one hand, user data and applications may frequently migrate within a cloud environment, rendering hardware-identity binding ineffective. On the other hand, virtualization technology allows multiple virtual machines to run on a single physical server, making fixed IP address-based authorization unreliable and making unauthorized copying and use of software service authorizations extremely easy. Furthermore, as an emerging distributed ledger technology, private consortium blockchains, deployed and used within private cloud environments, provide efficient and transparent transaction processing and data sharing platforms for all parties. However, the authorization management of alliance chain nodes also faces similar problems as traditional software authorization, especially in private cloud environments. Due to the dynamic nature of node deployment and network isolation, how to ensure that the authorization status of the node is consistent with the service provider's policy while preventing unauthorized copying and use of authorization codes has become a difficult problem that needs to be solved urgently.

[0003] Currently, technical solutions for authorization management of private consortium blockchain services are still in the exploratory stage, lacking effective methods to address the authorization challenges in private cloud environments. Existing authorization management mechanisms are often limited to static hardware bindings and cannot adapt to the frequent migration and dynamic changes of consortium blockchain nodes in private cloud environments. They also cannot guarantee the validity and security of authorization when nodes are isolated from the service provider network.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] Embodiments of the present invention provide a service authorization method, device, and electronic device based on a private alliance chain to at least solve the technical problem of low security of private alliance chain service authorization in a private cloud environment.

[0006] According to one aspect of an embodiment of the present invention, a service authorization method based on a private alliance chain is provided, comprising: obtaining a current block height of a target blockchain node in the private alliance chain at a current moment, wherein the target blockchain node is a blockchain node deployed in a private cloud environment of a service purchasing end of the private alliance chain; when the current block height is greater than a preset height, based on a preset timed task, verifying the current authorization code held by the target blockchain node through an authorization smart contract to obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code, and record the service authorization behavior of the corresponding blockchain node; when the verification result indicates that the current authorization code has passed the verification, authorizing the target blockchain node to use the target blockchain node, and generating a target authorization code based on the authorization smart contract; and sending the target authorization code to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

[0007] According to another aspect of an embodiment of the present invention, a service authorization device based on a private alliance chain is also provided, including: a block height acquisition module, which is equivalent to obtaining the current block height of a target blockchain node in the private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in a private cloud environment of a service purchasing end of the private alliance chain; a verification module, which is equivalent to, when the current block height is greater than a preset height, verifying the current authorization code held by the target blockchain node through an authorization smart contract based on a preset timed task to obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code, and record the service authorization behavior of the corresponding blockchain node; the authorization module, which is equivalent to, when the verification result indicates that the current authorization code has passed the verification, authorizing the target blockchain node to use the target blockchain node and generating a target authorization code based on the authorization smart contract; a replacement module, which is equivalent to sending the target authorization code to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

[0008] According to another aspect of an embodiment of the present invention, a non-volatile storage medium is further provided, wherein the non-volatile storage medium stores a plurality of instructions, and the instructions are suitable for being loaded and executed by a processor according to any one of the private alliance chain-based service authorization methods.

[0009] According to another aspect of an embodiment of the present invention, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the private alliance chain-based service authorization methods.

[0010] In an embodiment of the present invention, by obtaining the current block height of the target blockchain node in the private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in the private cloud environment of the service purchasing end of the private alliance chain; when the current block height is greater than a preset height, based on a preset timed task, the current authorization code held by the target blockchain node is verified through an authorization smart contract to obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code, and record the service authorization behavior of the corresponding blockchain node; when the verification result indicates that the current authorization code verification passes, the target blockchain node is authorized to use the target blockchain node, and a target authorization code is generated based on the authorization smart contract; the target authorization code is sent to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code, thereby achieving the purpose of implementing dynamic verification and updating of the authorization code based on the current block height, thereby achieving the technical effect of enhancing the reliability and security of service authorization without affecting data security, and thus solving the technical problem of low security of private alliance chain service authorization in a private cloud environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0012] Figure 1 This is a flow chart of a service authorization method based on a private alliance chain according to an embodiment of the present invention;

[0013] Figure 2 This is a schematic diagram of the relationship between a service provider and a purchasing end of an optional privatized alliance chain according to an embodiment of the present invention;

[0014] Figure 3 is a schematic diagram of an optional device code structure according to an embodiment of the present invention;

[0015] Figure 4 is a schematic diagram of the structure of an optional authorization smart contract according to an embodiment of the present invention;

[0016] Figure 5 is a flowchart of an optional service authorization method based on a private alliance chain according to an embodiment of the present invention;

[0017] Figure 6 2 is a schematic diagram of a service authorization device based on a private alliance chain according to an embodiment of the present invention. DETAILED DESCRIPTION

[0018] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0019] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0020] First, to facilitate understanding of the embodiments of the present invention, some of the terms or nouns involved in the present invention are explained below:

[0021] A private consortium chain refers to a blockchain network jointly maintained and used by a specific group of members, in which data access and transaction permissions are strictly restricted. It aims to provide secure, private and controllable distributed ledger services.

[0022] According to an embodiment of the present invention, a method embodiment of service authorization based on a private alliance chain is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0023] Figure 1 Flowchart of a service authorization method based on a private alliance chain according to an embodiment of the present invention. Figure 1 As shown, the method includes the following steps:

[0024] Step S102: Obtain the current block height of the target blockchain node in the private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in the private cloud environment of the service purchasing end of the private alliance chain;

[0025] Optionally, the target blockchain node's block height refers to the location identifier of the most recent block on the blockchain verified and recorded by the node in the private consortium chain. The target blockchain node is the blockchain node authorized by the service provider of the private consortium chain to the service purchaser. Figure 2 This is a schematic diagram of the relationship between the service provider and the purchasing end of an optional private alliance chain according to an embodiment of the present invention. Figure 2 The figure shows the relationship between the privatized alliance chain provider P and the privatized alliance chain purchasing end C (including purchasing ends C1, C2, ..., Cn). The privatized alliance chain authorization provider P and the privatized alliance chain purchasing end C are in different local area networks. For system security reasons, the network between the purchasing end C and the provider P is not connected. The provider P cannot obtain the actual usage and authorization status of the purchasing end C through direct authorization by the system.

[0026] In theory, the most direct way for the provider (P) to ensure that the consortium chain authorization it provides cannot be compromised (copied) by the purchaser (C) is for the provider (P) to directly access the blockchain software deployed on the purchaser. However, in reality, the provider (P) and the purchaser (C) are disconnected from the network, and to ensure system buyout and data security, the purchaser (C) does not allow the provider (P) to access the private consortium chain system it purchased.

[0027] Step S104: When the current block height is greater than the preset height, the authorization code held by the target blockchain node is verified by the authorization smart contract based on the preset timed task to obtain a verification result. The authorization smart contract is used to generate and verify the authorization code and record the service authorization behavior of the corresponding blockchain node.

[0028] Optionally, the preset height can be 0. The authorization code authorizes the target blockchain node to use the target blockchain node. The authorization smart contract dynamically verifies the authorization code based on the current block height, ensuring its validity matches the latest blockchain status. When the block height exceeds the preset height, indicating new blockchain activity or updates, the authorization smart contract will revalidate the authorization code to confirm that the node maintains legal access rights. The preset height serves as a checkpoint. Once the block height exceeds this checkpoint, the authorization smart contract will automatically trigger verification of the authorization code. This prevents static authorization codes from being used indefinitely without authorization, improving the dynamicity and security of authorization management. The authorization smart contract not only generates and verifies authorization codes but also records the details of each authorization, including the time of authorization, authorization code, node status, and other information. This record provides immutable evidence for future authorization disputes.

[0029] In an optional embodiment, based on a preset timed task, the current authorization code held by the target blockchain node is verified through an authorized smart contract to obtain a verification result, including: based on the preset timed task, obtaining the current system time of the target blockchain node and the current block height corresponding to the current system time; obtaining the historical system time of the target blockchain node and the historical block height corresponding to the historical system time, wherein the historical block height is the block height collected before the current block height; detecting whether the current block height is greater than the historical block height and whether the current system time is greater than the historical system time; based on the authorized smart contract, performing signature verification on the current authorization code; when the current block height is greater than the historical block height, and the current system time is greater than the historical system time, and the current authorization code signature verification passes, determining the verification result as: the current authorization code verification passes; when the current block height is less than or equal to the historical block height, or the current system time is less than or equal to the historical system time, or the current authorization code signature verification fails, determining the verification result as: the current authorization code verification fails.

[0030] Optionally, by comparing the current block height with historical block heights, as well as the current system time with historical system time, the validity and timeliness of the authorization code can be accurately determined. This helps prevent misjudgment of authorization codes due to time synchronization issues or incorrect block height recording. The authorization code's signature verification and verification based on time and block height provide a dual guarantee for authorization code verification. Even if the authorization code's signature verification passes, if the system time and block height checks fail, the authorization code will still be considered invalid, making it more difficult to compromise authorization. Ensuring that the authorization code is used not only requires signature verification but also aligns with the actual operating status of the target blockchain node (i.e., time and block height). This prevents the authorization code from being unauthorizedly copied or tampered with and then used on non-compliant nodes, protecting the use rights of private consortium chain services from abuse. The above verification mechanism helps maintain the stability of the blockchain network. Only after the authorization code passes all verification steps, ensuring time and block height consistency and integrity, is the target blockchain node authorized to start and run, preventing interference and potential threats to the blockchain network from unauthorized access nodes.

[0031] Step S106: If the verification result indicates that the current authorization code verification has passed, the target blockchain node is authorized to use the target blockchain node, and a target authorization code is generated based on the authorization smart contract;

[0032] Optionally, in order to ensure that the authorization of the private alliance chain provider P is not compromised in the private alliance chain scenario, this embodiment proposes a more secure authorization method, namely, dynamically verifying and updating the authorization code based on the current block height, thereby ensuring that the reliability and security of service authorization are enhanced without affecting data security.

[0033] In an optional embodiment, generating a target authorization code based on an authorization smart contract includes: obtaining current device information of a target blockchain node, wherein the current device information includes at least: the IP address of a server or virtual machine on which the target blockchain node is currently running, the port number to which the target blockchain node is bound at the current moment, the current system time of the target blockchain node at the current moment, and the current block height of the target blockchain node at the current moment; and generating a target authorization code based on the current device information using a preset signature algorithm in the authorization smart contract.

[0034] Optionally, the smart contract collects detailed device information about the target blockchain node at a specific moment, including the IP address of the server or virtual machine on which the node runs, the bound port number, the current system time, and the current block height. This collection of information not only identifies the node but also reflects its real-time status, closely tied to the blockchain's data state. The smart contract uses a pre-defined signature algorithm, taking this collected current device information as input, to generate a target authorization code. This signature algorithm can be based on asymmetric encryption technology and signed using the private key of the private consortium chain provider P. The generated authorization code can be verified using the public key in the smart contract, thereby ensuring its authenticity and non-tampering.

[0035] This approach allows the authorization code to be tied to the specific device status of the target node and the real-time data status of the blockchain. By dynamically generating authorization codes, the difficulty of breaching the authorization mechanism is increased. Even if someone obtains an authorization code, without the correct matching device information and block height, they cannot start or continue running the target blockchain node, as the smart contract verifies this information to ensure the timeliness and compliance of the authorization code. Simultaneously, automating this process through smart contracts can reduce human intervention, improve the efficiency and automation of authorization management, lower operational costs, ensure the transparency and immutability of the entire authorization process, and provide technical support for the compliant use of private consortium chain services and the maintenance of service contracts between providers and purchasers.

[0036] Optionally, in order to ensure that the authorization code is not broken by the private alliance chain purchasing terminal C, the device code DevID is generated based on the current device information of the blockchain node Bi. Figure 3 is a schematic diagram of an optional device code structure according to an embodiment of the present invention, such as Figure 3 As shown in the figure, the DevID consists of the following four parts. Since the authorization code is dynamically generated and is associated with the block height (essentially business data), it means that if you want to break the authorization code, you must copy the business data as well, which greatly reduces the security of the business data and the motivation to break the authorization code.

[0037] IP: indicates the system IP address bound to the current blockchain node Bi;

[0038] PORT: indicates the system port to which the current blockchain node Bi is bound;

[0039] systemTime: indicates the timestamp of the host where the current blockchain node Bi is located;

[0040] Hi: indicates the block height of the current blockchain node Bi;

[0041] Among them, in order to increase the difficulty of breaking the attack, the DevID displayed here waiting for input should be transformed, and the DevID can be encrypted using asymmetric encryption. The specific encryption method is as follows: EncyDevID = sm2Ency (IP, PORT, systemTime, Hi, PPublicKey), where EncyDevID represents the encrypted device code, sm2Ency represents the function encrypted using the SM2 encryption algorithm, and PPublicKey represents the public key held by the private alliance chain provider P; the operation and maintenance personnel upload EncyDevID to the authorized business system of the private alliance chain provider P, and the authorized business system decrypts the encrypted device code using the corresponding private key to obtain the decrypted device code DevID. The specific decryption method is as follows: DevID = sm2Decry (EncyDevID, PPrivateKey), which records the latest height to the system and verifies whether the authorization has been broken. Among them, sm2Decry represents the function decrypted using the SM2 encryption algorithm; PPrivateKey represents the private key of the private alliance chain provider P.

[0042] Optional, Figure 4 This is a structural diagram of an optional authorization smart contract according to an embodiment of the present invention. The authorization smart contract of the privatized alliance chain is mainly used to: store the public key PPublicKey of the privatized alliance chain provider P, verify the signature of the input verification code Lj0, calculate the device information EncryDevID of the current blockchain node Bi, calculate the latest authorization code Lji (Lji = Sign (Hi, EncryDevID, systemTime)), and record the L0 input authorization process.

[0043] Step S108: Send the target authorization code to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

[0044] Optionally, sending the target authorization code to the target blockchain node is intended to update the node's authorization status, ensuring that its authorization information matches the latest blockchain state. This mechanism ensures dynamic and real-time authorization management, allowing authorization codes to be updated based on blockchain developments and changes. Regularly updating authorization codes prevents them from expiring or being permanently used, maintaining the timeliness and controllability of authorization. Whenever a pre-set scheduled task is triggered, the target blockchain node must replace the old current authorization code with the newly generated target authorization code to ensure system security and compliance.

[0045] In an optional embodiment, the method further includes: when the verification result indicates that the target blockchain node has failed the verification, controlling the current authorization code held by the target blockchain to be switched to an invalid state, and prohibiting the target blockchain node from using the target blockchain node.

[0046] Optionally, if the authorization code verification fails, switching the authorization code to an invalid state can immediately prevent non-compliant use of the node, ensuring that the usage status of the private consortium chain service is strictly consistent with the authorization contract and preventing unauthorized use. Prohibiting the target blockchain node that fails the verification from continuing to use the service can effectively prevent potential security threats, such as a node copied by an abnormal access end attempting to obtain the same permissions as the original node, or attempting to use an expired or tampered authorization code after the node is hacked. By controlling the usage status of the node, a clear list of authorized nodes can be maintained in the consortium chain, ensuring that all active nodes are compliantly authorized, which contributes to the stability of the entire system and the integrity of the data.

[0047] In an optional embodiment, when the current block height is equal to the preset height, the method further includes: receiving a first authorization code sent by the service provider of the private alliance chain, wherein the first authorization code is generated by the service provider of the private alliance chain based on encrypted device information, and the encrypted device information is obtained by encrypting the collected current device information by the target blockchain node and sending it to the service provider, and the current device information includes at least: the IP address of the server or virtual machine running at the current moment, the port number bound to the target blockchain node at the current moment, the current system time of the target blockchain node at the current moment, and the current block height of the target blockchain node at the current moment; verifying the first authorization code based on the authorization smart contract; and if the first authorization code passes the verification, storing the first authorization code and the current device information in the authorization smart contract.

[0048] Optionally, when the block height of the target blockchain node reaches a preset height (such as equal to 0), the system will receive a first authorization code sent by the private alliance chain service provider. This first authorization code is generated by the service provider based on the encrypted device information sent by the target node. The encrypted device information is sent to the service provider by the target blockchain node after encrypting its current device information, where the current device information includes at least the IP address, port number, system time and block height. This process can ensure the secure transmission of device information and prevent possible information leakage during the transmission process. After receiving the first authorization code, the target blockchain node will use the authorization smart contract to verify the authorization code. The verification process includes verifying the correctness of the signature of the authorization code, the matching of the device information and the validity of the authorization code, thereby ensuring that the first authorization code is generated in compliance with the regulations by the private alliance chain service provider, and preventing abnormal use of forged or tampered authorization codes. If the first authorization code is verified as valid by the authorization smart contract, the target blockchain node will store the first authorization code and its associated current device information in the authorization smart contract. This not only records the validity of the authorization code but also preserves the device status associated with the authorization code, providing basic data for subsequent dynamic authorization code generation and verification. The immutability of the stored information also ensures the transparency and traceability of the authorization history.

[0049] In the above method, when the block height reaches the preset value, through the transmission of encrypted device information, the generation and verification of the first authorization code, and the storage of the verification results, it can be ensured that the authorization status of the target node is strictly consistent with the authorization policy of the service provider, thereby maintaining the normal operation and data security of the private alliance chain service.

[0050] In an optional embodiment, when the first authorization code passes the verification, the first authorization code and the current device information are stored in the authorization smart contract, including: detecting whether the first authorization code has been used; when the first authorization code has not been used and the first authorization code passes the verification, the first authorization code and the current device information are stored in the authorization smart contract.

[0051] Optionally, before verifying the first authorization code through the authorization smart contract, it is checked whether the authorization code has been used. This can prevent the authorization code from being reused or abused on multiple different nodes, ensure that each first authorization code can only be used for authorization verification once, maintain the uniqueness of the authorization code and the compliance of the authorization behavior. When the first authorization code passes the verification of the authorization smart contract, proves that its source and integrity are compliant, and also confirms that the authorization code has not been used, the first authorization code is allowed to be stored in the authorization smart contract together with the current device information, thereby ensuring that the authorization information stored in the smart contract is the latest, valid, and matches the current state and environment of the target node. Ultimately, only when the first authorization code passes all the above checks (including signature verification and usage status detection) will the first authorization code and its related current device information (such as IP address, port number, system time, block height, etc.) be stored in the authorization smart contract. This storage mechanism can not only record authorization events, but also ensure that when subsequent dynamic authorization codes are generated, they can be based on the latest authorization information and device status, enhancing the dynamic authorization management capabilities and security of private alliance chain services.

[0052] Through the above approach, private consortium chain service providers can more strictly control and manage the authorized use of their services, preventing unauthorized duplication or reuse of authorization codes and ensuring that each node operates under compliant authorization. This mechanism also strengthens the overall security of the private consortium chain network, providing a more reliable and secure service environment for service buyers, and safeguarding the rights and interests of both service providers and buyers. The automated processing and storage capabilities of smart contracts can further improve the efficiency and transparency of authorization management and reduce the risks of manual manipulation.

[0053] In an optional embodiment, the service provider is further configured to send the first authorization code to the target blockchain node.

[0054] Optionally, when the target blockchain node's block height reaches a preset height, the node collects and encrypts its current device information (including IP address, port number, system time, block height, etc.), then sends the encrypted device information to the private consortium chain service provider. Upon receiving the encrypted device information, the service provider uses its private key to sign it based on the signature algorithm pre-set in the smart contract, generating a first authorization code. The transmission of the first authorization code between the service provider and the target blockchain node is secure because the encrypted device information is encrypted during transmission. Even if intercepted by a third party, the information remains confidential due to the lack of the private key required for decryption. The generation and transmission of the first authorization code fully leverages blockchain encryption technology and asymmetric encryption to ensure the security of the authorization information. Upon receiving the first authorization code, the target blockchain node verifies it through the authorization smart contract. This verification process includes verifying the correctness of the authorization code's signature and checking whether the authorization code has been used before. Only if the verification passes and is confirmed to be unused is the first authorization code considered valid. The first authorization code and the current device information are stored in the authorization smart contract as the basis for subsequent dynamic authorization verification. The above method can ensure the timeliness of the first authorization code, that is, it is only generated and sent when the current block height reaches the preset height. At the same time, it also ensures the uniqueness and validity of the first authorization code, prevents the reuse of the authorization code, and ensures the compliance of the private alliance chain service.

[0055] Through the above steps S102 to S108, the purpose of implementing dynamic verification and updating of the authorization code based on the current block height can be achieved, thereby realizing the technical effect of enhancing the reliability and security of service authorization without affecting data security, and further solving the technical problem of low security of private alliance chain service authorization in a private cloud environment.

[0056] Based on the above embodiments and optional embodiments, the present invention proposes an optional implementation mode: Figure 5 This is a flow chart of an optional service authorization method based on a private alliance chain according to an embodiment of the present invention. Figure 5 As shown, Bi represents the i-th node of the blockchain; Hi represents the blockchain height of the i-th node of the blockchain; L0 represents the authorization code. The service provider and service purchaser in the private alliance chain of this method meet the following requirements: Figure 2 The relationship shown in FIG. 1 includes:

[0057] S1: When the current block height Hi of the blockchain node Bi is greater than 0, the service authorization verification of the blockchain node i is performed as follows:

[0058] S11, the i-th node Bi of the blockchain is started;

[0059] S12, query the current height Hi of the local blockchain (where Hi has a value range of Hi>=0);

[0060] S13, if the current height Hi>0, directly obtain the latest authorization code generated by the blockchain node Bi calling the authorization smart contract. The authorization code is automatically generated by the blockchain node Bi.

[0061] S14: Verify the authorization code through the authorization smart contract and record this authorization in the smart contract.

[0062] S15, verification is started by node Bi;

[0063] S16, after the blockchain node Bi is started, every 24 hours the blockchain node Bi generates a dynamic authorization code by accessing the authorization smart contract and updates the authorization code to the local.

[0064] S2, when the current block height Hi of blockchain node Bi = 0, perform service authorization verification on blockchain node i in the following way:

[0065] S21, the i-th node Bi of the blockchain is started;

[0066] S22, query the current height Hi (Hi=0) of the local blockchain, where Hi=0 indicates the initial startup. In actual situations, the initial startup is generally performed by the operation and maintenance personnel arranged by the private alliance chain provider P.

[0067] S23, verify the current local authorization code. If this step passes, go directly to the above process. If not, the authorization smart contract prints out the device code (DevID), where the device code is obtained based on the device information of the blockchain node.

[0068] S24, the operation and maintenance personnel obtain the device code DevID and paste the device code DevID into the authorization business system of the private alliance chain provider P ( Figure 2 Cn in the authorization business system Cn returns the initial authorization code Li0 (where Li0 = Sign(DevID, PPrivateKey)). At the same time, Cn records the application authorization process and the device code DevID. PPrivateKey represents the private key held by the privatized alliance chain provider P. The private key is used to digitally sign the device code DevID and generate the authorization code Li0 to ensure the security and non-tamperability of the authorization code. Sign represents the signature function.

[0069] S25. The operation and maintenance personnel obtain the single authorization code Li0 and enter it into the authorization business system. The authorization smart contract verifies Li0 (the verification can be done through the signature verification function CheckSign(DevID, PPublicKey, Li0)). At the same time, the verification result and Li0 initiated by this authorization are recorded in the authorization smart contract. Among them, CheckSign represents the signature verification function, and PPublicKey represents the public key of the privatized alliance chain provider P.

[0070] S26, after verification, start the blockchain node Bi.

[0071] As an optional embodiment, assuming that the private alliance chain provider is P, the private alliance chain software purchaser is C, and four blockchain nodes (B1, B2, B3, B4) are purchased, the specific implementation process is as follows:

[0072] S31, the software provider P designates the operation and maintenance personnel X to deploy a blockchain node in the private cloud environment E of the purchasing end C, where the corresponding four host IPs are IP1, IP2, IP3, and IP4, the ports are Port1, Port2, Port3, and Port4, and the current time is T.

[0073] S32, start the blockchain node B1 on IP1, PORT1, B1 collects host information IP1, Poprt1, Time, H (block height, current H=0), calls the asymmetric encryption sm2Encry method of the authorized smart contract, obtains EncryDevID, and prints it to the console.

[0074] S33, the operation and maintenance personnel X sends EncryDevID to the authorization registration system of P on the privatized alliance chain authorization. The authorization registration system decrypts EncryDevID through the private key PPrivateKey and obtains IP1, Port1, Time, and H. The authorization registration system records IP1, Port1, Time, H, X's work number, and the purchasing enterprise credit code in the authorization registration system.

[0075] S34, after the authorization registration system records, the EncryDevID is signed by PPrivateKey, and the signature string Sign is returned to the operation and maintenance personnel X.

[0076] S35: Operations and maintenance personnel X obtains the latest Sign and enters it into the console.

[0077] S36, after the authorization smart contract obtains the signature, it records the signature to the smart contract and checks whether the authorization sign has been used. If the signature verification passes and the sign has not been used, the authorization is passed and the system is started successfully.

[0078] S37, system operation, assuming that at 1:00 every day (the time can be adjusted according to the actual business processing peak), the blockchain node B1 obtains the latest block height H1, the current system time T1, and EncryDevID, and passes the relevant parameters to the authorization smart contract. The authorization smart contract verifies the parameters, where H1 must be greater than or equal to H in the last authorization record, the system time T1 must be greater than T in the last authorization record, and the authorization code must be signature-verified. The authorization smart contract calculates the latest authorization code Sign by calling the calculation authorization code method and returns it to the blockchain node B1.

[0079] S38, blockchain node B1 records the latest Sign locally and will pass it in when dynamic authorization is initiated next time, and so on to form a new cycle.

[0080] The above operations are all normal business operations. To ensure the integrity of the technical solution, we can further consider several scenarios of breaking the authorization code and provide explanations:

[0081] 1) Copy Bi to another host (with at least one of the IP / PORT being inconsistent) and start it: Since the authorization smart contract is started after authorization by the operation and maintenance personnel, dynamic verification will obtain the latest IP / PORT. After changing to another host, the startup fails.

[0082] 2) Copy the entire private cloud and start it: In fact, if the entire cloud is copied, the current technical solution still cannot solve the problem of authorization breach. However, since authorization startup is highly related to the blockchain (essentially, it is associated with data), after the copy, the data will also be synchronously copied to the new cloud environment, threatening the system's data security and increasing the difficulty of breaching to a certain extent.

[0083] In this embodiment, leveraging the blockchain's highly positive correlation with blocks over time, dynamically modifying authorization permissions maximizes the security of the authorization service, making it more difficult to copy or compromise authorizations. Furthermore, leveraging the blockchain's immutable nature, authorization actions are recorded, providing a technical basis for non-compliant authorizations.

[0084] It should be noted that the relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. For example, an interface is set up between this system and the relevant user or organization. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving the consent information fed back by the aforementioned user or organization.

[0085] In this embodiment, a service authorization device based on a private alliance chain is also provided. The device is used to implement the above-mentioned embodiments and preferred implementation methods. The details that have been described will not be repeated here. As used below, the terms "module" and "device" can refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0086] According to an embodiment of the present invention, there is also provided an embodiment of a device for implementing the above-mentioned service authorization method based on a private alliance chain. Figure 6 is a structural diagram of a service authorization device based on a private alliance chain according to an embodiment of the present invention. Figure 6 As shown, the service authorization device based on the private alliance chain includes: a block height acquisition module 600, a verification module 602, an authorization module 604, and a replacement module 606, wherein:

[0087] The block height acquisition module 600 is used to obtain the current block height of the target blockchain node in the private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in the private cloud environment of the service purchasing end of the private alliance chain;

[0088] Verification module 602, connected to block height acquisition module 600, is used to verify the current authorization code held by the target blockchain node through the authorization smart contract based on a preset timer task when the current block height is greater than a preset height, and obtain a verification result. The authorization smart contract is used to generate and verify the authorization code and record the service authorization behavior of the corresponding blockchain node;

[0089] The authorization module 604 is connected to the verification module 602 and is used to authorize the target blockchain node to use the target blockchain node when the verification result indicates that the current authorization code verification has passed, and to generate a target authorization code based on the authorization smart contract;

[0090] The replacement module 606 is connected to the authorization module 604 and is used to send a target authorization code to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

[0091] In an embodiment of the present invention, a block height acquisition module 600 is provided for obtaining the current block height of the target blockchain node in the private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in the private cloud environment of the service purchasing end of the private alliance chain; a verification module 602 is connected to the block height acquisition module 600 and is used to verify the current authorization code held by the target blockchain node through the authorization smart contract based on a preset timed task when the current block height is greater than a preset height, and obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code, and record the service authorization behavior of the corresponding blockchain node; an authorization module 604 , connected to the verification module 602, and used to authorize the target blockchain node to use the target blockchain node when the verification result indicates that the current authorization code verification has passed, and generate a target authorization code based on the authorization smart contract; the replacement module 606, connected to the authorization module 604, is used to send the target authorization code to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code, thereby achieving the purpose of implementing dynamic verification and updating of the authorization code based on the current block height, thereby achieving the technical effect of enhancing the reliability and security of service authorization without affecting data security, and thus solving the technical problem of low security of private alliance chain service authorization in a private cloud environment.

[0092] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0093] It should be noted that the block height acquisition module 600, verification module 602, authorization module 604, and replacement module 606 correspond to steps S102 to S108 in the embodiment. The examples and application scenarios implemented by the modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above embodiment. It should be noted that the modules as part of the device can be run in a computer terminal.

[0094] It should be noted that the optional or preferred implementation of this embodiment can be found in the relevant description in the embodiment, which will not be repeated here.

[0095] The above-mentioned service authorization device based on the private alliance chain may also include a processor and a memory. The above-mentioned block height acquisition module 600, verification module 602, authorization module 604, replacement module 606, etc. are all stored in the memory as program modules, and the processor executes the above-mentioned program modules stored in the memory to realize the corresponding functions.

[0096] The processor includes a core, which retrieves corresponding program modules from memory. There can be one or more cores. Memory may include non-permanent memory in a computer-readable medium, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory includes at least one memory chip.

[0097] According to an embodiment of the present application, an embodiment of a non-volatile storage medium is also provided. Optionally, in this embodiment, the non-volatile storage medium includes a stored program, wherein, when the program is executed, the device containing the non-volatile storage medium is controlled to execute any of the above-mentioned private alliance chain-based service authorization methods.

[0098] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group, and the non-volatile storage medium includes a stored program.

[0099] Optionally, when the program is running, the device where the non-volatile storage medium is located is controlled to perform the following functions: obtain the current block height of the target blockchain node in the private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in the private cloud environment of the service purchasing end of the private alliance chain; when the current block height is greater than the preset height, based on the preset timed task, the current authorization code held by the target blockchain node is verified through the authorization smart contract to obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code, and record the service authorization behavior of the corresponding blockchain node; when the verification result indicates that the current authorization code verification has passed, the target blockchain node is authorized to use the target blockchain node, and a target authorization code is generated based on the authorization smart contract; the target authorization code is sent to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

[0100] According to an embodiment of the present application, an embodiment of a processor is further provided. Optionally, in this embodiment, the processor is used to run a program, wherein the program executes any of the above-mentioned service authorization methods based on a private alliance chain when running.

[0101] According to an embodiment of the present application, an embodiment of a computer program product is also provided, which, when executed on a data processing device, is suitable for executing a program that initializes any of the steps of the above-mentioned private alliance chain-based service authorization method.

[0102] Optionally, the above-mentioned computer program product, when executed on a data processing device, is suitable for executing a program initialized with the following method steps: obtaining the current block height of the target blockchain node in the private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in the private cloud environment of the service purchasing end of the private alliance chain; when the current block height is greater than a preset height, based on a preset timed task, the current authorization code held by the target blockchain node is verified through the authorization smart contract to obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code, and record the service authorization behavior of the corresponding blockchain node; when the verification result indicates that the current authorization code verification has passed, the target blockchain node is authorized to use the target blockchain node, and a target authorization code is generated based on the authorization smart contract; the target authorization code is sent to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

[0103] An embodiment of the present invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and capable of running on the processor. When the processor executes the program, the following steps are implemented: obtaining the current block height of a target blockchain node in a private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in a private cloud environment of a service purchasing end of the private alliance chain; when the current block height is greater than a preset height, based on a preset timed task, verifying the current authorization code held by the target blockchain node through an authorization smart contract to obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code, and record the service authorization behavior of the corresponding blockchain node; when the verification result indicates that the current authorization code verification has passed, authorizing the target blockchain node to use the target blockchain node, and generating a target authorization code based on the authorization smart contract; sending the target authorization code to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

[0104] The above sequence of the embodiments of the present invention is for description only and does not represent the superiority or inferiority of the embodiments.

[0105] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0106] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the above modules can be a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, modules or indirect coupling or communication connection of modules, which can be electrical or other forms.

[0107] The modules described above as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment.

[0108] In addition, the functional modules in various embodiments of the present invention may be integrated into a single processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or software functional modules.

[0109] If the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable non-volatile storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a non-volatile storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the various embodiments of the present invention. The aforementioned non-volatile storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, and other media that can store program codes.

[0110] The above are only preferred embodiments of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A service authorization method based on a private alliance chain, characterized in that: include: Obtaining the current block height of a target blockchain node in a private alliance chain at the current moment, wherein the target blockchain node is a blockchain node deployed in a private cloud environment of a service purchasing end of the private alliance chain; When the current block height is greater than a preset height, based on a preset timed task, the current authorization code held by the target blockchain node is verified through the authorization smart contract to obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code, and record the service authorization behavior of the corresponding blockchain node; If the verification result indicates that the current authorization code verification has passed, authorizing the target blockchain node to use the target blockchain node, and generating a target authorization code based on the authorization smart contract; The target authorization code is sent to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

2. The method according to claim 1, characterized in that The method further comprises: When the verification result indicates that the target blockchain node fails the verification, the current authorization code held by the target blockchain is controlled to be switched to an invalid state, and the target blockchain node is prohibited from using the target blockchain node.

3. The method according to claim 1, characterized in that Based on the preset timed task, the current authorization code held by the target blockchain node is verified through the authorization smart contract to obtain the verification result, including: Based on the preset timed task, obtain the current system time of the target blockchain node and the current block height corresponding to the current system time; Obtain the historical system time of the target blockchain node and the historical block height corresponding to the historical system time, wherein the historical block height is the block height collected before the current block height; Detect whether the current block height is greater than the historical block height, and whether the current system time is greater than the historical system time; Perform signature verification on the current authorization code based on the authorization smart contract; If the current block height is greater than the historical block height, the current system time is greater than the historical system time, and the current authorization code signature verification passes, determining the verification result as: the current authorization code verification passes; When the current block height is less than or equal to the historical block height, or the current system time is less than or equal to the historical system time, or the current authorization code signature verification fails, the verification result is determined to be: the current authorization code verification fails.

4. The method according to claim 1, wherein The generating a target authorization code based on the authorization smart contract includes: Obtaining current device information of the target blockchain node, wherein the current device information includes at least: the IP address of the server or virtual machine on which the target blockchain node is running at the current moment, the port number bound to the target blockchain node at the current moment, the current system time of the target blockchain node at the current moment, and the current block height of the target blockchain node at the current moment; Based on the current device information, the target authorization code is generated using the preset signature algorithm in the authorization smart contract.

5. The method according to claim 1, wherein When the current block height is equal to the preset height, the method further includes: Receive a first authorization code sent by the service provider of the private consortium chain, where the first authorization code is generated by the service provider of the private consortium chain based on encrypted device information, the encrypted device information is obtained by the target blockchain node by encrypting the collected current device information and sending it to the service provider, the current device information including at least: the IP address of the server or virtual machine on which the target blockchain node is running at the current moment, the port number bound to the target blockchain node at the current moment, the current system time of the target blockchain node at the current moment, and the current block height of the target blockchain node at the current moment; Verifying the first authorization code based on the authorization smart contract; If the first authorization code passes the verification, the first authorization code and the current device information are stored in the authorization smart contract.

6. The method according to claim 5, characterized in that If the first authorization code passes verification, storing the first authorization code and the current device information in the authorization smart contract includes: Detecting whether the first authorization code has been used; If the first authorization code has not been used and the first authorization code passes verification, the first authorization code and the current device information are stored in the authorization smart contract.

7. The method according to claim 5, characterized in that The service provider is further configured to send the first authorization code to the target blockchain node.

8. A service authorization device based on a private alliance chain, characterized in that: include: A block height acquisition module, configured to acquire the current block height of a target blockchain node in a private alliance chain at a current moment, wherein the target blockchain node is a blockchain node deployed in a private cloud environment of a service purchasing end of the private alliance chain; A verification module is configured to verify the current authorization code held by the target blockchain node through an authorization smart contract based on a preset timed task when the current block height is greater than a preset height, and obtain a verification result, wherein the authorization smart contract is used to generate and verify the authorization code and record the service authorization behavior of the corresponding blockchain node; An authorization module, configured to authorize the target blockchain node to use the target blockchain node if the verification result indicates that the current authorization code verification has passed, and generate a target authorization code based on the authorization smart contract; A replacement module is used to send the target authorization code to the target blockchain node, so that the target blockchain node replaces the current authorization code with the target authorization code.

9. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a plurality of instructions, which are suitable for being loaded by a processor and executing the service authorization method based on a private alliance chain as described in any one of claims 1 to 7.

10. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the service authorization method based on the private alliance chain as described in any one of claims 1 to 7.

Images