CN116471018A - Certificate management method and device and electronic equipment - Google Patents
Certificate management method and device and electronic equipment Download PDFInfo
- Publication number
- CN116471018A CN116471018A CN202310357740.XA CN202310357740A CN116471018A CN 116471018 A CN116471018 A CN 116471018A CN 202310357740 A CN202310357740 A CN 202310357740A CN 116471018 A CN116471018 A CN 116471018A
- Authority
- CN
- China
- Prior art keywords
- node
- certificate
- nodes
- block
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000007726 management method Methods 0.000 title claims abstract description 39
- 238000000034 method Methods 0.000 claims abstract description 40
- 230000007246 mechanism Effects 0.000 claims description 25
- 238000012544 monitoring process Methods 0.000 claims description 10
- 238000012795 verification Methods 0.000 claims description 8
- 238000004590 computer program Methods 0.000 claims description 7
- 230000005540 biological transmission Effects 0.000 claims description 2
- 230000008520 organization Effects 0.000 description 16
- 230000006854 communication Effects 0.000 description 13
- 238000004891 communication Methods 0.000 description 12
- 230000008569 process Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000013475 authorization Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
One or more embodiments of the present specification disclose a certificate management method, which relates to the technical field of blockchain. The method comprises the following steps: based on a consensus event between a first node in a blockchain and one or more second nodes in the blockchain, determining whether a certificate critical node exists in the second nodes, so that a certificate issuing authority corresponding to the certificate critical node updates a certificate of the certificate critical node in the case that the certificate critical node exists in the second nodes.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for certificate management, and an electronic device.
Background
The consensus among the nodes of some blockchains (e.g., federation chains, private chains) requires mutual authentication using certificates to secure the data on the chains. If the certificate of a certain node expires, communication between other nodes and the node with the expired certificate is impossible, so that the service is stopped.
It follows that timely discovery of certificate expiration nodes is critical to the stable operation of services supported by these blockchains.
Disclosure of Invention
In view of this, one or more embodiments of the present disclosure provide a certificate management method and apparatus, and an electronic device.
In a first aspect, a certificate management method is provided, the method comprising: based on a consensus event between a first node in the blockchain and one or more second nodes in the blockchain, determining whether a certificate critical node exists in the second nodes, so that a certificate issuing authority corresponding to the certificate critical node updates a certificate of the certificate critical node if the certificate critical node exists in the second nodes.
In a second aspect, there is provided a certificate management apparatus comprising: a determination module configured to determine whether a credential grace node exists in one or more second nodes in the blockchain based on a consensus event between the first node and the second node in the blockchain, such that a credential issuing authority corresponding to the credential grace node updates a credential of the credential grace node if the credential grace node exists in the second node.
In a third aspect, a federation chain is provided that includes a first node and one or more second nodes. Wherein the first node is configured to: based on a consensus event between the first node and the second node, determining whether a certificate critical node exists in the second node, so that a certificate issuing mechanism corresponding to the certificate critical node updates a certificate of the certificate critical node under the condition that the certificate critical node exists in the second node.
In a fourth aspect, a private chain is provided that includes a first node and one or more second nodes. Wherein the first node is configured to: based on a consensus event between the first node and the second node, determining whether a certificate critical node exists in the second node, so that a certificate issuing mechanism corresponding to the certificate critical node updates a certificate of the certificate critical node under the condition that the certificate critical node exists in the second node.
In a fifth aspect, there is provided an electronic device comprising: a processor and a memory for storing computer program instructions which, when executed by the processor, cause the processor to perform the method as mentioned in the first aspect above.
In a sixth aspect, a computer readable storage medium is provided, the storage medium storing instructions that, when executed, enable the method mentioned in the first aspect to be carried out.
In a seventh aspect, a computer program product is provided comprising instructions which, when executed, enable the method mentioned in the first aspect to be carried out.
One or more embodiments of the present disclosure provide a certificate management method that determines whether a certificate critical node exists in a second node based on a consensus event between the first node and the second node, thereby achieving the purpose of monitoring whether the certificate critical node exists in a blockchain by using a node in the blockchain. In addition, under the condition that the existence of the certificate temporary node is determined, the certificate issuing mechanism corresponding to the certificate temporary node can update the certificate of the certificate temporary node in time so as to ensure the stable operation of the business supported by the blockchain.
Drawings
Fig. 1 is a schematic system architecture diagram of a certificate management application scenario according to an embodiment of the present disclosure.
Fig. 2 is a flow chart of a certificate management method according to an embodiment of the present disclosure.
Fig. 3 is a schematic flow chart of determining whether data in a certificate temporary node is legal according to an embodiment of the present disclosure.
Fig. 4 is a schematic structural diagram of a certificate management apparatus according to an embodiment of the present disclosure.
Fig. 5 is a schematic structural diagram of a certificate management apparatus according to another embodiment of the present disclosure.
Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure.
Detailed Description
The technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is apparent that the described embodiments are only some embodiments, not all embodiments.
Blockchains are a distributed storage billing technique based on cryptography. The blockchain technology can organize and maintain a large amount of data in a decentralization or multicentric mode, has the characteristics of distribution, non-tamper property, traceability, safety, reliability and the like, and is widely applied to a plurality of fields. Specifically, a Block-Chain (Block-Chain) is a Chain of blocks one by one. Each block holds certain information which is linked in a chain according to the time sequence of their respective generation. This chain is kept in all servers, and the entire blockchain is secure as long as one server in the entire system can work. These servers, referred to as nodes in the blockchain, provide storage space and computational power support for the entire blockchain. If information in the blockchain is to be modified, more than half of the nodes must be granted and the information in all nodes modified. However, these nodes are typically held in different subject hands, so it is an extremely difficult matter to tamper with the information in the blockchain.
Blockchains are largely divided into three types: public chains (PublicBlockchain), private chains (Private Blockchain), and federated chains (Consortium blockchain). Of course, blockchains may also have combinations of the types described above, such as private chains plus federated chains, and federated chains plus public chains, among others.
A public chain, any individual or group in the world can send a transaction, and the transaction can get a valid confirmation of the blockchain, anyone can participate in the consensus process. The private chain, also called private chain, is a non-public "chain" and usually requires authorization to join a node, and the write rights of each node in the private chain are strictly controlled, and the read rights are selectively opened to the outside as needed. A federated chain refers to a blockchain that is commonly participated in management by multiple organizations, each organization or organization managing one or more nodes whose data only allows different organizations within the system to read, write and send.
Among public, private and federated chains, the most decentralised is the public chain. Participants joining the public chain can read data records on the chain, participate in transactions, and compete for billing rights for new blocks, etc. Moreover, each node can freely join or leave the network and perform relevant operations. The private chain is opposite, the write authority of the private chain is controlled by a certain organization or organization, and the data read authority is regulated by the organization. In short, the private chain may be a weakly centralized system with strict restrictions on nodes and a smaller number of nodes, which is more suitable for use within a particular organization. In contrast, federation chains are interposed between public and private chains, allowing for "partial decentralization. Each node in the federation chain typically has an entity authority or organization corresponding thereto, and the nodes join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation. That is, a federated chain is a blockchain that is commonly managed by several organizations or organizations, each running one or more nodes, the data in the federated chain only allowing the organizations or organizations to read and send.
Typically, some blockchains (such as federation chains) employ the HyperText transfer security protocol (HyperText TransferProtocoloverSecureSocketLayer, HTTPS) for mutual authentication, i.e., both the node (i.e., server) and the client invoking the server need to mutually authenticate using certificates to secure the data on the chain. The certificate of the client expires, and the client cannot log in the corresponding server. If the certificate of a certain node expires, communication between other nodes and the node with the expired certificate is impossible, so that the service is stopped. Therefore, it is necessary to monitor whether the certificates of the nodes of these blockchains are imminent.
Currently, for blockchains (such as federation chains and private chains) that need to perform certificate monitoring, the following three methods are mainly adopted for certificate management. First, the node certificate is indirectly managed by managing the certificate of the server using the blockchain, however, the certificate issuing mechanism on the node is different from the certificate issuing mechanism on the HTTP protocol, that is, the certificate of the node and the certificate of the client are not completely synchronous, so that the situation that the certificate of the node has been invalidated, but the certificate of the client has not been invalidated is easy to occur, and therefore, the node certificate invalidation cannot be found in time by using the method. Second, the validity period of the certificates of the nodes in the blockchain is monitored using a centralized third party certificate management platform. This approach is contrary to the aim of "weak centralization" of the blockchain and is therefore rarely adopted. Third, since the external organization or organization of the blockchain runs one or more nodes each, the external organization or organization monitors the deadlines of each other's certificates between one or more nodes, but the monitoring purpose cannot be achieved without logging in the nodes managed by the external organization or organization.
In order to solve the above problems, one or more embodiments of the present disclosure provide a certificate management method, which determines whether a certificate critical node exists in a second node based on a common event between a first node in a blockchain and one or more second nodes in the blockchain, thereby achieving the purpose of monitoring whether the certificate critical node exists in the blockchain by using the nodes in the blockchain. In addition, under the condition that the existence of the certificate temporary node is determined, a certificate issuing mechanism (CertificateAuthorities, CA) corresponding to the certificate temporary node can timely update the certificate of the certificate temporary node so as to ensure the stable operation of the business supported by the blockchain.
The system architecture of a certificate management application scenario in a federated chain is illustrated below in connection with FIG. 1.
As shown in fig. 1, in one or more embodiments of the present description, a certificate management application scenario involves a federation chain 10 and a certificate issuing authority 20. Wherein the federation chain 10 includes a first node 110 and a plurality of second nodes (including a second node 121, a second node 122, a second node 123, a second node 12X, etc.).
The nodes (including the first node and the second node) in the federation chain 10 may be servers. One node is invoked by at least one client, that is, an off-link user invokes a node in the federation chain via the client to perform operations such as reading block data, executing contracts, etc. The client can be arranged at a place such as a bank, and can be a smart phone, a tablet personal computer and the like.
Illustratively, the server of the first node 110 has deployed thereon the certificate management methods provided in one or more embodiments of the present specification. In the actual operation process, the server of the first node 110 monitors consensus events between the first node 110 and the plurality of second nodes, acquires respective certificate information of the plurality of second nodes, so as to determine whether a certificate critical node exists in the plurality of second nodes, and notifies a certificate issuing mechanism corresponding to the certificate critical node when the certificate critical node exists in the plurality of second nodes, so that the certificate issuing mechanism updates the certificate of the certificate critical node. For example, if the second node 12X in fig. 1 has a certificate expiration (i.e., the second node 12X is a certificate expiration node), the second node 12X is notified of the corresponding certificate authority 20 so that the certificate authority 20 updates the certificate of the second node 12X.
In other application scenarios, when the server of the first node 110 determines that there are certificate critical nodes in the plurality of second nodes, the manager of the first node 110 notifies the staff of the certificate critical nodes, so that the staff of the certificate critical nodes sends an update notification to the certificate issuing authority corresponding to the certificate critical nodes.
Therefore, in the application scenario, the first node 110 monitors the validity periods of the certificates of each of the plurality of second nodes through the consensus event with the plurality of second nodes, that is, the purpose of monitoring whether the certificates of all the nodes in the federation chain 10 are in the clinic period by using one node in the federation chain 10 is achieved, so that the purpose of ensuring the stable operation of the services supported by the federation chain is achieved.
The certificate management method referred to in one or more embodiments of the present specification is described in detail below in conjunction with fig. 2 and 3.
Fig. 2 is a flow chart of a certificate management method according to an embodiment of the present disclosure. In particular, the certificate management method mentioned in the embodiments of the present specification is applied to a blockchain requiring certificate monitoring, and specifically to a first node in the blockchain, where one or more second nodes are further included in the blockchain. As shown in fig. 2, the certificate management method provided in this embodiment includes the following steps for the first node.
Step S210, determining whether a credential lifetime node exists in one or more second nodes in the blockchain based on consensus events between the first node and the second nodes in the blockchain.
Specifically, step S210 is performed so that, in the case where a certificate authority exists in the second node, the certificate issuing authority corresponding to the certificate authority updates the certificate of the certificate authority.
The blockchain is used as a distributed system, and different nodes can jointly participate in the execution process of calculation and common witness transaction, and the final calculation result is confirmed. The process of collaboration of the loosely coupled and mutually untrusted participants to achieve trust relationship and guarantee consistency and persistence collaboration can be abstracted into a consensus process, and the involved algorithms and strategies are collectively called a consensus mechanism. The process of nodes in a blockchain (such as a first node and a plurality of second nodes) sharing one another is referred to as a consensus event.
The consensus mechanism in the blockchain is a mechanism by which the blockchain nodes achieve a full-network consensus on the blocks, thereby ensuring that the latest block is accurately added to the blockchain. The consensus mechanisms of the current mainstream include: a workload certification mechanism (ProofofWork, POW), a stock right certification mechanism (ProofofStake, POS), a commission right certification mechanism (DelegatedProofof Stake, DPOS), a practical bayer fault tolerance algorithm (PracticalByzantineFaultTolerance, PBFT), and the like.
Some blockchains are described herein based on federation chains to require the necessity of certificate monitoring. In contrast to public chains, federated chains are not completely decentralised, allowing only authorized nodes to agree on. Thus, the federation chain has more "authorized" operations than the public chain, which is done in the form of "issuing digital certificates". The main body issuing the digital certificate is a certificate issuing organization, and the node with the qualified certificate can be added into the alliance chain. That is, the certificate issuing authority is configured to issue a certificate for a node to indicate that the node is legitimate.
The process of issuing the certificate is a process that a certificate issuing mechanism carries out digital signature on the associated information of the node through a private key of the certificate issuing mechanism. Specifically, the node generates its public and private key pair by using an asymmetric encryption technology, and the public key of the node and part of information (such as organization information or personal information) form a certificate request file csr and send the certificate request file csr to a certificate issuing authority. The certificate issuing mechanism verifies the authenticity of information provided by the applicant through various means such as online or offline, and issues a certificate crt to the node after the verification is passed. The certificate crt generally contains the following information: the public key of the applicant, the organization information and personal information of the applicant, the information of the certificate issuing authority, the validity time, the plaintext of the information such as the certificate serial number, the signature of the certificate issuing authority, and the like. In the embodiment of the present specification, the certificate issuing authority generates the update certificate crt from the update certificate request file csr of the certificate temporary node.
In the embodiment of the present specification, in the case where there is a certificate authority among the plurality of second nodes, step S220 is performed to send an update notification to the certificate issuing authority corresponding to the certificate authority. Specifically, the first node transmits an update notification about the certificate authority to the certificate issuing authority to which the certificate authority corresponds. The update notification includes an update certificate request file regarding the certificate expiration node such that the certificate issuing authority updates the certificate of the certificate expiration node based on the update certificate request file.
One or more embodiments of the present disclosure provide a certificate management method that determines whether a certificate critical node exists in a second node based on a consensus event between the first node and the second node, thereby achieving the purpose of monitoring whether the certificate critical node exists in a blockchain by using a node in the blockchain. In addition, under the condition that the existence of the certificate temporary node is determined, the certificate issuing mechanism corresponding to the certificate temporary node can update the certificate of the certificate temporary node in time so as to ensure the stable operation of the business supported by the blockchain. In addition, the first node directly sends the update notification to the certificate issuing mechanism corresponding to the certificate temporary node, so that the operation efficiency of the blockchain system can be improved.
In some other embodiments, when there are certificate temporary nodes in the plurality of second nodes, a list of the certificate temporary nodes is displayed on a client corresponding to the first node, so that a worker of the first node can check the list, and the worker of the certificate temporary nodes is notified by the worker of the first node, so that the worker of the certificate temporary nodes notifies a certificate issuing mechanism corresponding to the certificate temporary nodes to update the certificates.
In one example, based on a consensus event between a first node in a blockchain and one or more second nodes in the blockchain, determining whether a credential deadline node exists in the second nodes may be performed as: under the condition that the first node and any second node are in consensus, acquiring a certificate of the second node; based on the expiration date of the second node's certificate, it is determined whether the second node is a certificate expiration node. Specifically, since the nodes in the blockchain need to be constantly identified, each time the first node and any second node are identified, the certificate of the second node is acquired, so as to determine whether the second node is a certificate critical node according to the certificate. Because the certificate has an effective date, the expiration date can be determined according to the effective date, and if the duration between the current time for the current consensus and the expiration date in the certificate is less than or equal to the preset duration, the second node is determined to be the certificate temporary node.
In another example, based on a consensus event between a first node in the blockchain and one or more second nodes in the blockchain, determining whether a credential deadline node exists in the second nodes may be performed as: under the condition that the first node and any second node are subjected to first consensus, acquiring an Internet protocol (Internet Protocol, IP) and a port corresponding to the second node; and inquiring the certificate of the second node by utilizing the Internet protocol and the port corresponding to the second node at preset inquiring time, and determining whether the second node is a certificate temporary node or not based on the effective date of the certificate of the second node. The preset inquiry time can be realized as that inquiry is performed every 12 hours. Alternatively, the preset query time may be implemented as that 10 and 20 fixed monthly queries are respectively performed once.
In yet another example, based on a consensus event between a first node in the blockchain and one or more second nodes in the blockchain, determining whether a credential expiration node exists in the second nodes may be performed as: under the condition that the first node and any second node carry out first consensus, acquiring an Internet interconnection protocol and a port corresponding to the second node; and at preset inquiry time, the first node communicates with the second node by utilizing an Internet interconnection protocol and a port corresponding to the second node, acquires a certificate of the second node in the communication process, and determines whether the second node is a certificate temporary node or not based on the effective date of the certificate of the second node.
Considering that the server of the certificate critical node needs to be shutdown and restarted after the completion of the certificate update in the process of updating the certificate of the certificate critical node, the certificate critical node cannot acquire a new block generated by the co-identification in the blockchain during the shutdown and the restart. Therefore, even if the data of the certificate temporary node can be obtained by other nodes after the certificate temporary node is restarted, the data of the latest block of the certificate temporary node cannot be proved to be legal. Therefore, after the certificate updating is completed, data consistency verification needs to be performed on the certificate temporary node and other nodes.
How to perform data consistency verification on the certificate expiration node and other nodes after the completion of the certificate updating is described in detail below with reference to fig. 3. As shown in fig. 3, in one or more embodiments of the present description, determining whether data in a credential expiration node is legitimate includes the following steps.
Step S310, the latest block of the certificate temporary node and the blocks with the same block height as the latest block in other nodes are obtained. Wherein the other nodes are nodes in the blockchain except for the certificate expiration node.
In a blockchain, data is packaged together in the form of a plurality of files, similar to placing the files in a box, called a data block, i.e., a block (block). The blocks in the blockchain are constructed in time sequence, the first block is called a genessisblock, and subsequently generated blocks are identified by block heights (simply referred to as block heights). Among the blocks included in the blockchain, new blocks introduce hash information of the previous block, so the block height is gradually increased.
In some embodiments, the specific implementation manner of step S310 is that, after the certificate updating is completed, the block with the largest block height in the certificate temporary node is determined as the latest block of the certificate temporary node, and then the blocks with the same block height as the latest block in other nodes are determined. For example, if the block height of the latest block of the certificate temporary node is 10006, the block with the block height of 10006 in other nodes is obtained.
In step S320, it is determined whether the data in the latest block and the data in the block with the same block height as the latest block are the same.
If the determination result in step S320 is yes, that is, the data in the latest block is the same as the data in the block with the same block height as the latest block, step S330 is performed. If the determination result in step S320 is no, that is, the data in the latest block is different from the data in the block with the same block height as the latest block, step S310 is re-executed, that is, the latest block of the certificate temporary node and the block with the same block height as the latest block in other nodes are re-acquired until the data in the latest block and the data in the block with the same block height as the latest block are the same.
Step S330, determining that the data in the certificate temporary node is legal.
In some other embodiments, if the data in the latest block, the data in the block with the same block height as the latest block, and the difference between the block height of the latest block and the block height when the certificate temporary node stops running is greater than a preset difference, it is determined that the data in the certificate temporary node is legal. By the arrangement, the bifurcation problem can be effectively prevented. For example, the preset difference is 6, the block height of the certificate temporary node when the operation is stopped is 10000, and after the certificate updating of the certificate temporary node is completed, the block height of the latest block of the obtained certificate temporary node is 10008. Then, if the data in the latest block is the same as the data in the block with the same block height as the latest block, since the difference between 10008 and 10000 is 8 larger than 6, it is determined that the data in the certificate temporary node is legal.
In some other embodiments, if the data in the most recent block, the data in the same block as the block height of the most recent block, is different, the first node tags the credential expiration node indicating that it is in a state to be validated. The certificate critical node in the state to be confirmed cannot be commonly recognized with other nodes, but can communicate with other nodes to obtain new block data generated by other nodes during shutdown and restarting, thereby generating own new block data so that the data in the latest block is the same as the data in the block with the same block height as the latest block.
According to the embodiment of the specification, the aim of verifying whether the data in the updated certificate temporary node is legal or not is achieved by verifying whether the data in the latest block and the data in the block with the same block height as the latest block are identical or not, so that the handshake reliability of each node in the block chain is ensured.
One or more embodiments of the present specification also refer to a federated chain that includes a first node and one or more second nodes. Wherein the first node is configured to: based on a consensus event between the first node and the second node, determining whether a certificate critical node exists in the second node, so that a certificate issuing mechanism corresponding to the certificate critical node updates a certificate of the certificate critical node under the condition that the certificate critical node exists in the second node.
One or more embodiments of the present specification also refer to a private chain that includes a first node and one or more second nodes. Wherein the first node is configured to: based on a consensus event between the first node and the second node, determining whether a certificate critical node exists in the second node, so that a certificate issuing mechanism corresponding to the certificate critical node updates a certificate of the certificate critical node under the condition that the certificate critical node exists in the second node.
In some further embodiments, the first node is further configured to perform the methods mentioned in the above embodiments of the present description, and thus, parts not described in detail may be referred to the previous method embodiments.
The method embodiments of the present specification are described above in detail with reference to fig. 2 and 3, and the apparatus embodiments of the present specification are described below in detail with reference to fig. 4 and 5. Furthermore, it should be understood that the description of the method embodiments corresponds to the description of the device embodiments, and that parts not described in detail can therefore be seen in the previous method embodiments.
Fig. 4 is a schematic structural diagram of a certificate management apparatus according to an embodiment of the present disclosure, and as shown in fig. 4, a certificate management apparatus 400 according to an embodiment of the present disclosure is applied to a first node in a blockchain, and the blockchain further includes a plurality of second nodes. The certificate management apparatus 400 comprises a determination module 410 and a transmission module 420. In this illustrative embodiment, the determination module 410 is configured to determine whether a credential expiration node exists in the second node based on a consensus event between the first node in the blockchain and one or more second nodes in the blockchain, such that in the event that a credential expiration node exists in the second node, a credential issuing authority corresponding to the credential expiration node updates a credential of the credential expiration node. The sending module 420 is configured to send an update notification to a certificate issuing authority corresponding to the certificate critical node, in case it is determined that the certificate critical node exists.
In some embodiments, the determining module 410 is further configured to obtain a certificate of the second node if the first node is in consensus with any of the second nodes; based on the expiration date of the second node's certificate, it is determined whether the second node is a certificate expiration node.
In other embodiments, the determining module 410 is further configured to, in the case where the first node performs first consensus with any second node, obtain an internet protocol and a port corresponding to the second node; inquiring a certificate of the second node by using an Internet interconnection protocol and a port corresponding to the second node at preset inquiring time; based on the expiration date of the second node's certificate, it is determined whether the second node is a certificate expiration node.
It is understood that the sending module 420 in fig. 4 may be omitted, that is, the certificate management apparatus 400 may include the determining module 410.
Fig. 5 is a schematic structural diagram of a certificate management apparatus according to another embodiment of the present disclosure. The embodiment shown in fig. 5 is extended from the embodiment shown in fig. 4, and differences between the embodiment shown in fig. 5 and the embodiment shown in fig. 4 are described in detail, so that the description is omitted.
As shown in fig. 5, the certificate management apparatus 500 mentioned in the embodiment of the present specification further includes a verification module 510. Specifically, the verification module 510 is configured to obtain, after the certificate of the certificate critical node is updated, the latest block of the certificate critical node, and a block with the same block height as the latest block in other nodes, where the other nodes are nodes in the blockchain except the certificate critical node; if the data in the latest block and the data in the block with the same block height as the latest block are the same, determining that the data in the certificate temporary node is legal, and after determining that the data in the certificate temporary node is legal, enabling the certificate temporary node to be in consensus with other nodes.
In some embodiments, the verification module 510 is further configured to re-acquire the latest block of the certificate temporary node, the block of the other nodes having the same block height as the latest block, at least once, until the data in the latest block, the data in the block having the same block height as the latest block, are the same, if the data in the latest block, the data in the block having the same block height as the latest block, are different.
Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure. As shown in fig. 6, an electronic device 600 (which may be a computer device in particular) includes a memory 601, a processor 602, a communication interface 603, and a bus 604. The memory 601, the processor 602, and the communication interface 603 are connected to each other by a bus 604.
The memory 601 may be a read only memory (ReadOnlyMemory, ROM), a static storage device, a dynamic storage device or a random access memory (RandomAccessMemory, RAM). The memory 601 may store a program, and the processor 602 and the communication interface 603 are configured to perform the steps of the certificate management method of one or more embodiments of the present specification when the program stored in the memory 601 is executed by the processor 602.
The processor 602 may employ a microprocessor, application specific integrated circuit (ApplicationSpecificIntegrated Circuit, ASIC), graphics processor (GraphicsProcessingUnit, GPU), or one or more integrated circuits for executing associated programs to perform the functions required by the modules and/or units in the credential management device in accordance with one or more embodiments of the present disclosure.
The processor 602 may also be an integrated circuit chip with signal processing capabilities. In implementation, various steps of the certificate management methods of one or more embodiments of the present description may be performed by integrated logic circuitry in hardware or instructions in software in processor 602. The processor 602 described above may also be a general purpose processor, a digital signal processor (DigitalSignalProcessing, DSP), an Application Specific Integrated Circuit (ASIC), a field programmable gate array (FieldProgrammableGateArray, FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component. The various methods, steps, and logic blocks disclosed in one or more embodiments of the present description may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with one or more embodiments of the present disclosure may be embodied directly in a hardware decoding processor or in a combination of hardware and software modules in a decoding processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory 601, and a processor 602 reads information in the memory 601, and in combination with hardware thereof, performs functions required to be performed by units included in a certificate management apparatus of one or more embodiments of the present specification, or performs a certificate management method of one or more method embodiments of the present specification.
The communication interface 603 enables communication between the electronic device 600 and other devices or communication networks using transceiving means such as, but not limited to, a transceiver.
A bus 604 may include a path for transferring information between components of the electronic device 600 (e.g., the memory 601, the processor 602, the communication interface 603).
It should be noted that while the electronic device 600 shown in fig. 6 shows only a memory, a processor, and a communication interface, those skilled in the art will appreciate that in a particular implementation, the electronic device 600 also includes other components necessary to achieve proper operation. Also, those skilled in the art will appreciate that the electronic device 600 may also include hardware devices that implement other additional functions, as desired. Furthermore, those skilled in the art will appreciate that the electronic device 600 may also include only the devices necessary to implement one or more embodiments of the present description, and not necessarily all of the devices shown in FIG. 6.
In addition to the methods, apparatus and devices described above, one or more embodiments of the present description may also be a computer program product comprising computer program instructions which, when executed by a processor, cause the processor to perform the steps of the certificate management method provided by the various embodiments of the present description.
The computer program product may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional step programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server.
Furthermore, one or more embodiments of the present description may also be a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, cause the processor to perform the steps of the certificate management method provided by the various embodiments of the present description.
A computer readable storage medium may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may include, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the one or more embodiments of the present disclosure.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.
In the several embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in each embodiment of the present specification may be integrated in one similar area dividing unit, each unit may exist alone physically, or two or more units may be integrated in one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present specification may be essentially or, what contributes to the prior art, or the part of the technical solution may be embodied in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, or the like) to execute all or part of the steps of the method described in the embodiments of the present specification. And the aforementioned storage medium includes: various media capable of storing program codes, such as a U disk, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
The foregoing is merely specific embodiments of the present disclosure, but the scope of the disclosure is not limited thereto, and any person skilled in the art who is skilled in the art can easily think about variations or substitutions within the scope of the disclosure of the present disclosure, and it is intended to cover the variations or substitutions within the scope of the disclosure. Therefore, the protection scope of the present specification shall be subject to the protection scope of the claims.
Claims (14)
1. A certificate management method, comprising:
based on a consensus event between a first node in a blockchain and one or more second nodes in the blockchain, determining whether a credential grace node exists in the second nodes, such that a credential issuing authority corresponding to the credential grace node updates a credential of the credential grace node if the credential grace node exists in the second nodes.
2. The method of claim 1, the determining whether a credential lifetime node exists in one or more second nodes in a blockchain based on consensus events between the second nodes and the first nodes in the blockchain, comprising:
acquiring a certificate of the second node under the condition that the first node and any second node are in consensus;
based on the expiration date of the second node's certificate, it is determined whether the second node is a certificate expiration node.
3. The method of claim 1, the determining whether a credential lifetime node exists in one or more second nodes in a blockchain based on consensus events between the second nodes and the first nodes in the blockchain, comprising:
under the condition that the first node and any second node carry out first consensus, acquiring an Internet interconnection protocol and a port corresponding to the second node;
inquiring a certificate of the second node by using an Internet interconnection protocol and a port corresponding to the second node at preset inquiring time;
based on the expiration date of the second node's certificate, it is determined whether the second node is a certificate expiration node.
4. A method according to any one of claims 1 to 3, further comprising:
after the certificate of the certificate temporary node is updated, acquiring the latest block of the certificate temporary node and blocks with the same block height as the latest block in other nodes, wherein the other nodes are nodes except the certificate temporary node in the block chain;
if the data in the latest block and the data in the block with the same block height as the latest block are the same, determining that the data in the certificate temporary node is legal, and after determining that the data in the certificate temporary node is legal, enabling the certificate temporary node to be identified with other nodes.
5. The method of claim 4, further comprising:
and if the data in the latest block and the data in the block with the same block height as the latest block are different, re-acquiring the latest block of the certificate temporary node and the block with the same block height as the latest block in the other nodes at least once until the data in the latest block and the data in the block with the same block height as the latest block are the same.
6. A method according to any one of claims 1 to 3, further comprising:
and under the condition that the existence of the certificate temporary node is determined, sending an update notification to a certificate issuing mechanism corresponding to the certificate temporary node.
7. A method according to any one of claims 1 to 3, the blockchain being a blockchain requiring certificate monitoring, the blockchain requiring certificate monitoring comprising a federated chain and/or a private chain.
8. A certificate management apparatus comprising:
a determination module configured to determine whether a credential grace period node exists in one or more second nodes in a blockchain based on a consensus event between the first node and the second node, such that a credential issuing authority corresponding to the credential grace period node updates a credential of the credential grace period node if the credential grace period node exists in the second node.
9. The apparatus of claim 8, wherein the determining module is further configured to,
acquiring a certificate of the second node under the condition that the first node and any second node are in consensus;
based on the expiration date of the second node's certificate, it is determined whether the second node is a certificate expiration node.
10. The apparatus of claim 8, wherein the determining module is further configured to,
under the condition that the first node and any second node carry out first consensus, acquiring an Internet interconnection protocol and a port corresponding to the second node;
inquiring a certificate of the second node by using an Internet interconnection protocol and a port corresponding to the second node at preset inquiring time;
based on the expiration date of the second node's certificate, it is determined whether the second node is a certificate expiration node.
11. The apparatus according to any one of claims 8 to 10, further comprising a verification module,
wherein the verification module is configured to:
after the certificate of the certificate temporary node is updated, acquiring the latest block of the certificate temporary node and blocks with the same block height as the latest block in other nodes, wherein the other nodes are nodes except the certificate temporary node in the block chain;
if the data in the latest block and the data in the block with the same block height as the latest block are the same, determining that the data in the certificate temporary node is legal, and after determining that the data in the certificate temporary node is legal, enabling the certificate temporary node to be identified with other nodes.
12. The apparatus of claim 11, wherein the authentication module is further configured to,
and if the data in the latest block and the data in the block with the same block height as the latest block are different, re-acquiring the latest block of the certificate temporary node and the block with the same block height as the latest block in the other nodes at least once until the data in the latest block and the data in the block with the same block height as the latest block are the same.
13. The apparatus according to any one of claims 8 to 10, further comprising a transmission module,
wherein the transmitting module is configured to:
and sending an update notification to a certificate issuing mechanism corresponding to the certificate temporary node under the condition that the existence of the certificate temporary node is determined.
14. An electronic device, comprising:
a processor; and
a memory in which computer program instructions are stored which, when executed by the processor, cause the processor to perform the method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310357740.XA CN116471018A (en) | 2023-04-04 | 2023-04-04 | Certificate management method and device and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310357740.XA CN116471018A (en) | 2023-04-04 | 2023-04-04 | Certificate management method and device and electronic equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116471018A true CN116471018A (en) | 2023-07-21 |
Family
ID=87174478
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310357740.XA Pending CN116471018A (en) | 2023-04-04 | 2023-04-04 | Certificate management method and device and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116471018A (en) |
-
2023
- 2023-04-04 CN CN202310357740.XA patent/CN116471018A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110569674B (en) | Authentication method and device based on block chain network | |
| US20210083856A1 (en) | Improved hardware security module management | |
| US8417964B2 (en) | Software module management device and program | |
| KR101418799B1 (en) | System for providing mobile OTP service | |
| JP7479393B2 (en) | SYSTEM AND METHOD FOR A VIRTUAL DISTRIBUTED LEDGER NETWORK | |
| JP7202692B2 (en) | Dual blockchain-based digital electronic device with virtual blockchain and its operation method | |
| CN112612856B (en) | Block chain-based data processing method and device | |
| EP2110981A1 (en) | Personal information managing device for preventing personal information form being falsely altered and preventing personal information from being denied | |
| CN111769956B (en) | Service processing method, device, equipment and medium | |
| JP2022525551A (en) | Preventing erroneous transmission of copies of data records to distributed ledger systems | |
| JP2021089657A (en) | Authentication approving system and method for approving authentication | |
| Chen et al. | TrustBuilder: A non-repudiation scheme for IoT cloud applications | |
| CN111274597B (en) | Data processing method and device | |
| Fartitchou et al. | Security on blockchain technology | |
| CN117155685A (en) | Trusted acquisition and transmission method, system and storage medium for key data of DCS (distributed control system) | |
| Zhang et al. | Cross-Chain Interoperability and Collaboration for Keyword-Based Embedded Smart Contracts in the Internet of Things | |
| Dong et al. | Anonymous cross-domain authentication scheme for medical PKI system | |
| Lin et al. | User-managed access delegation for blockchain-driven IoT services | |
| CN110493008B (en) | Block chain authentication method, device, equipment and medium | |
| US9361435B1 (en) | Multi-tier digital supply chain management | |
| CN116471018A (en) | Certificate management method and device and electronic equipment | |
| US9602546B2 (en) | Accurate license counting in synchronized servers | |
| CN116961892A (en) | Block chain-based key generation method, device, electronic equipment and readable medium | |
| CN113869901B (en) | Key generation method, key generation device, computer-readable storage medium and computer equipment | |
| CN112163917B (en) | Bill processing method and device based on blockchain, medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40093276 Country of ref document: HK |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20240221 Address after: Guohao Times City # 20-01, 128 Meizhi Road, Singapore Applicant after: Advanced Nova Technology (Singapore) Holdings Ltd. Country or region after: Singapore Address before: 51 Belarusian Bashar Road, Singapore, Lai Zanda 1 # 04-08 Applicant before: Alipay laboratories (Singapore) Ltd. Country or region before: Singapore |
|
| TA01 | Transfer of patent application right |