WO2020143470A1 - 发放数字证书的方法、数字证书颁发中心和介质 - Google Patents

发放数字证书的方法、数字证书颁发中心和介质 Download PDF

Info

Publication number
WO2020143470A1
WO2020143470A1 PCT/CN2019/128755 CN2019128755W WO2020143470A1 WO 2020143470 A1 WO2020143470 A1 WO 2020143470A1 CN 2019128755 W CN2019128755 W CN 2019128755W WO 2020143470 A1 WO2020143470 A1 WO 2020143470A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
tpki
private key
authentication
digital certificate
Prior art date
Application number
PCT/CN2019/128755
Other languages
English (en)
French (fr)
Inventor
藏军
张建俊
郑罗海
史俊杰
陈湖佳
唐子超
蔡弋戈
秦青
戴传兵
蓝虎
陈金龙
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to JP2021518941A priority Critical patent/JP7273148B2/ja
Publication of WO2020143470A1 publication Critical patent/WO2020143470A1/zh
Priority to US17/171,937 priority patent/US11924358B2/en

Links

Images

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]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/321—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 a third party or a trusted authority
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/3247—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 digital signatures
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • This application relates to the field of blockchain, and specifically relates to a technology for issuing digital certificates for nodes in a blockchain network.
  • Public chains can be highly decentralized, with the highest credibility and security, but the slowest transaction speed; private chains The degree of decentralization that can be achieved is very low, but the transaction speed is fast, and it is most suitable for regulation; while the alliance chain can achieve partial decentralization, the degree of decentralization is between public and private chains, and the transaction speed is relatively slow. Fast and supervisable.
  • the three types of blockchains have different characteristics and different applicable scenarios.
  • One purpose of this application is to propose a method, digital certificate issuing center and medium for issuing digital certificates for nodes in the blockchain network, which can improve the proving power of the issued digital certificates and improve the security of data exchange in the blockchain network Sex.
  • a method for issuing digital certificates for nodes in a blockchain network is disclosed.
  • the method is performed by a digital certificate issuing center that includes a public and private key generation module and an authentication
  • the module includes: in response to a request for a public and private key from a node in the blockchain network, through the public and private key generation module, generate the public and private keys of the node for the node and send it to the node;
  • the authentication module receives the public key and registration information of the node; authenticates the registration information through the authentication module; if the authentication is successful, generates a digital certificate of the node through the authentication module and sends it to the node, the digital
  • the certificate contains plaintext information and a signature formed by using the private key of the authentication module to form the plaintext information, so that the node uses the public key of the authentication module to verify the signature, and the plaintext information includes the public key of the node.
  • a digital certificate issuing center includes: a public and private key generation module for responding to a request for a public and private key from a node in a blockchain network.
  • the node generates a public key and a private key of the node and sends it to the node; an authentication module is used to receive the public key and registration information of the node and authenticate the registration information, and if the authentication is successful, generate the The digital certificate of the node is sent to the node.
  • the digital certificate contains plaintext information and a signature formed by using the private key of the authentication module to form the plaintext information, so that the node uses the public key of the authentication module to verify the signature ,
  • the plaintext information includes the public key of the node.
  • a digital certificate issuing center including: a memory that stores computer-readable instructions; a processor that reads the computer-readable instructions stored in the memory to perform the method described above.
  • a computer program medium on which computer readable instructions are stored, and when the computer readable instructions are executed by a processor of a computer, the computer is caused to perform the method as described above.
  • a computer program product including instructions that, when run on a computer, cause the computer to execute the method as described above.
  • FIG. 1A-1C show three system architecture diagrams of a method for issuing digital certificates for nodes in a blockchain network according to an embodiment of the present application
  • FIG. 2 shows a scenario architecture diagram under the application scenario of an electronic invoice application method for issuing digital certificates for nodes in a blockchain network according to an embodiment of the present application
  • 3A-3K show a node display interface diagram of a method for issuing digital certificates for nodes in a blockchain network in an electronic invoice application scenario according to an embodiment of the present application;
  • 4A-4K show a node display interface diagram of a method for issuing digital certificates for nodes in a blockchain network in an electronic invoice application scenario according to an embodiment of the present application;
  • FIG. 5 shows a flowchart of a method for issuing digital certificates for nodes in a blockchain network according to an embodiment of the present application
  • FIG. 6 shows a schematic diagram of interaction between each module in the digital certificate issuing center and the node according to an embodiment of the present application
  • FIG. 10 shows a flowchart of a method for receiving a private key sent by a node according to an embodiment of the present application
  • FIG. 11 shows an interaction flow chart when a node escrows a private key to a private key management module according to an embodiment of the present application
  • FIG. 13 shows a flowchart of a method for a private key management module TPKI_pks to send a node's private key to a node according to an embodiment of the present application
  • FIG. 14 shows an interaction flowchart when a node obtains a managed private key from a private key management module according to an embodiment of the present application
  • FIG. 15 shows a flowchart of a method for issuing digital certificates for nodes in a blockchain network according to an embodiment of the present application
  • 16 shows a detailed module diagram of a digital certificate issuing center according to an embodiment of the present application
  • 17A-17B show a schematic diagram of a digital certificate issued by a digital certificate issuing center according to an embodiment of the present application
  • FIG. 18 shows a hardware structure diagram of a digital certificate issuing center according to an embodiment of the present application.
  • Blockchain is essentially a decentralized database. It is a series of data blocks that are generated by using cryptographic methods. Each data block contains a batch of network transaction information to verify its Information validity (anti-counterfeiting) and generating the next block.
  • the blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.
  • the underlying platform of the blockchain can include processing modules such as user management, basic services, smart contracts, and operation monitoring.
  • the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between the user's true identity and blockchain address (authority management), etc., and in In the case of authorization, supervise and audit certain real-identity transactions and provide rules configuration for risk control (risk control audit); basic service modules are deployed on all blockchain node devices to verify the validity of business requests, After completing the consensus on the effective request, it is recorded on the storage. For a new business request, the basic service first analyzes the interface adaptation and authentication (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management).
  • the platform product service layer provides the basic capabilities and implementation framework of typical applications. Based on these basic capabilities, developers can superimpose the characteristics of the business to complete the blockchain implementation of business logic.
  • the application service layer provides application services based on blockchain solutions to business participants for use.
  • FIG. 1A shows an architecture of a blockchain network applied in embodiments of the present application.
  • the architecture includes an accounting node network 100, a transaction information producer node 102, and a digital certificate issuing center 103, where the accounting node sub-network 100 includes multiple accounting nodes 101.
  • the transaction information generator node 102 and the accounting node 101 have different permissions under the entire blockchain system architecture.
  • the accounting node 101 has the accounting right (the right to generate data blocks and upload the data blocks to the chain), and the transaction information
  • the producer node 102 has no accounting right but only the right to generate transaction information and apply for accounting, and cannot verify whether the accounting of the accounting node 101 is correct, and can only passively believe the accounting of the accounting node 101.
  • Each transaction information producer node 102 has its corresponding accounting node 101. After the transaction information generating node 102 generates the transaction information, it can send the transaction information to the corresponding accounting node 101 to apply for accounting, thereby completing the on-chain.
  • the accounting nodes 101 included in the accounting node sub-network 100 need to exchange various information between each other and between the accounting node 101 and the transaction information generating node 102 during the above-mentioned data block on-chain process.
  • the sender needs to sign the information using the sender's private key and transmit it with the information.
  • the node receiving the signature and information can verify the signature using the sender's public key. Due to the existence of the public and private keys, the role of the digital certificate issuing center 103 is reflected, and the digital certificate issuing center 103 can confirm the legality of the public and private keys.
  • FIG. 1B shows another architecture of the blockchain network applied in the embodiments of the present application.
  • the system architecture includes an accounting node sub-network 100, a business node sub-network 104, and a digital certificate issuing center 103.
  • This architecture is different from the architecture of FIG. 1A in that it includes a service node sub-network 104 composed of service nodes 102.
  • the difference between the business node 103 and the transaction information producer node 102 in FIG. 1A is that although the business node 102 cannot record bills, it can verify the billing of the billing node 101.
  • the accounting node sub-network 100 and the service node sub-network 104 are connected through a proxy node 105.
  • the business node 102 only receives the block header sent from the accounting node 101. If it wants to query the specific transaction information in the block body, it needs to send a query request for the transaction information to the proxy node 105. In order to verify that the query request is issued by a legitimate business node 102, the business node 102 needs to sign the query request with the private key of the business node 102, and the proxy node 105 signs the query request with the public key of the business node 102 to prove The query request is issued by the service node 102, and the transmission is not lost. Here, the public and private keys of the service node are involved. Therefore, a digital certificate issued by the digital certificate issuing center 103 is required to ensure the legality of the public and private keys of the service node.
  • FIG. 1C shows another architecture of the blockchain network applied in the embodiments of the present application.
  • This system architecture differs from the system architecture of FIG. 1B in that its accounting node sub-network 100 is divided into a plurality of branch accounting node sub-networks.
  • Each branch accounting node sub-network can be responsible for recording a certain type of transaction information.
  • the accounting node in the branch accounting node sub-network A is responsible for recording blockchain financial transaction information
  • the accounting node in the branch accounting node sub-network B is responsible for recording electronic invoice transaction information.
  • the public and private keys of the lead accounting node or the public and private keys of the service node 102 are also required for signature and signature verification. The process is similar to that of FIG. 1B.
  • FIG. 2 shows a scenario architecture diagram of a method for issuing digital certificates for nodes in a blockchain network in an application scenario of electronic invoices according to an embodiment of the present application.
  • the business node 102 such as the terminal of the local tax bureau and the invoicing unit sends transaction information such as invoice issuance and invoicing to the billing node sub-network 100 on the chain .
  • the leader accounting node is on-chain, as described in conjunction with FIG. 1B, in the process of the leader accounting node sending the block header to the business node 102 and the business node 102 querying the transaction information in the block body, they need to use
  • the private key of the leader accounting node signs the block body, and the private key of the business node 102 signs the query request.
  • FIGS. 3A-3K show a display interface diagram of an invoicing terminal node applied to an electronic invoice application scenario according to an embodiment of the present application of a method for issuing digital certificates for nodes in a blockchain network.
  • These interface diagrams represent an electronic invoice application Under the scenario shown in FIG. 1A, the general process of the transaction information generating node 102 outside the accounting node network 100 applying for a digital certificate and chaining the transaction information under the architecture shown in FIG. 1A.
  • the transaction information needs to be signed, and it must first have a public and private key. Therefore, in the interface of FIG. 3A, a prompt of "request for issuing public and private keys" is displayed, and when "OK" is clicked, the terminal of the invoicing unit requests the digital certificate issuing center 103 to issue the public and private keys.
  • the digital certificate issuing center 103 generates a pair of public and private key pairs according to the request of the invoicing unit terminal, and returns the public and private key pair to the invoicing unit terminal.
  • the terminal of the invoicing unit can choose to save the private key by itself, or it can trust the private key to the digital certificate issuing center to prevent the loss of the private key stored in its own terminal when the terminal fails.
  • a prompt of "whether to host the private key” may be displayed.
  • the administrator may click “Yes” as shown in FIG. 3B.
  • the certificate issuing center 103 is hosted.
  • a prompt of "Private Key Escrow Successful” is displayed.
  • the digital certificate issuing center 103 After receiving the registration information, the digital certificate issuing center 103 authenticates the registration information, and if it passes, issues a digital certificate to the terminal of the invoicing unit.
  • the digital certificate contains plain text information such as the version number, signature algorithm, public key of the authentication module, and public key of the invoicing unit shown in FIG. 3E, and the signature of the plain text information with the private key of the authentication module. Since the digital certificate contains the public key of the invoicing unit, it forms a binding relationship with the public and private keys, which proves that the issued public and private keys are legal.
  • the administrator can click "verify" to verify the signature in the digital certificate using the public key of the authentication module. If the verification is passed, it is proved that the digital certificate is issued by a legal institution, and a prompt of successful verification of the digital certificate shown in FIG. 3F is displayed.
  • the invoicing unit terminal When the invoicing unit terminal issues an invoice, it is necessary to upload the invoicing information to the chain. At this time, fill in the transaction information such as the invoicing unit and invoice identification on the interface of FIG. 3G. After the administrator clicks "Send to Accounting Node", he instructs to send these transaction information to the corresponding accounting node 101.
  • the transaction information In order to protect the legitimacy of the transaction information sender and the integrity of the transaction information transmission, the transaction information needs to be signed.
  • the signature requires the private key of the invoicing unit terminal. Since the private key is selected to be escrowed on the interface of FIG. 3B, the escrowed private key needs to be obtained from the digital certificate issuing center 103 at this time. The administrator selects "Yes" on the interface of FIG. 3H.
  • the prompt interface shown in FIG. 3I is displayed.
  • the accounting node 101 After receiving the signature of the invoicing unit terminal, the accounting node 101 verifies the signature for the public key of the invoicing unit terminal. After the verification is successful, the terminal of the invoicing unit is notified that the verification is successful. The interface shown in FIG. 3J is displayed on the terminal of the invoicing unit.
  • the accounting node 101 chains the transaction information. After the chain is completed, notify the invoicing unit terminal that the chain is completed. The interface shown in FIG. 3K is displayed on the terminal of the invoicing unit.
  • FIGS. 4A-4K illustrate a node display interface diagram applied to an electronic invoice application scenario according to an embodiment of the present application of a method for issuing digital certificates for nodes in a blockchain network. These interface diagrams are shown in FIG. 1B Under the system architecture, the business node 102 in the business node sub-network 104 queries the accounting node 101 in the accounting node sub-network 100 for the general process of querying the block body of the data block on the chain.
  • 4A-4F is the process that the service node 102 completes the acquisition of the public and private keys and corresponding digital certificates before querying the transaction information in the block body, which is similar to FIGS. 3A-3F, so it will not be repeated here.
  • the business node 102 After the transaction information is uploaded to the chain, the business node 102 only receives the block header sent by the accounting node 101. When the business node 102 needs to query the transaction information in the block body, the interface shown in FIG. 4G is displayed. When the administrator clicks "OK", it instructs to send a query request to the agent node 105.
  • the signature of the service node 102 needs to be sent at the same time.
  • the display interface prompts that the query request needs to be signed, and asks whether to obtain the private key for signature.
  • the private key of the service node 102 is obtained from the digital certificate issuing center 103.
  • the query request is signed with the private key of the business node 102 and sent to the agent node 105 together with the query request.
  • the proxy node 105 After receiving the query request and the signature, the proxy node 105 verifies the signature with the public key of the business node 102. If the verification is successful, the business node 102 is notified.
  • the service node 102 displays the interface shown in FIG. 4J.
  • the proxy node 105 After the signature verification is successful, the proxy node 105 sends a query request for the block header transaction information to the corresponding accounting node 101, and decides whether to return the queried transaction information for it according to the authority of the business node 102.
  • FIG. 4K shows an interface for viewing returned transaction information at the business node 102.
  • a method for issuing digital certificates for nodes in a blockchain network is provided.
  • the blockchain network refers to the entire system architecture involved in recording data blocks on the blockchain as shown in FIGS. 1A-1C.
  • the digital certificate refers to a certification file set up to ensure that the public and private keys distributed to the nodes are distributed by legal institutions.
  • the nodes in the blockchain network refer to all nodes except the digital certificate issuing center 103 in the blockchain network.
  • FIG. 1A it includes a transaction information producer node 102 and an accounting node 101.
  • FIGS. 1B-1C it includes a business node 102, a proxy node 105, and an accounting node 101.
  • the method is performed by the digital certificate issuing center 103.
  • the digital certificate issuing center is a centralized infrastructure that provides security services for blockchain node communication based on encryption algorithms, and can issue digital certificates for nodes to confirm the legitimacy of public and private keys.
  • the digital certificate issuing center 103 includes at least a public and private key generation module TPKI_sdk and an authentication module TPKI_ca.
  • the public and private key generation module TPKI_sdk is a module that generates public and private keys for nodes.
  • the authentication module TPKI_ca is to authenticate a node, thereby verifying the legitimacy of the node, and then form an authenticated pairing module between the legitimate node and the public and private keys generated for the node.
  • the digital certificate issuing center 103 may further include an authentication strategy module TPKI_aus, and the authentication strategy module TPKI_aus is a module that stores a strategy adopted when authenticating the registration information of the node.
  • the public and private key generation module TPKI_sdk, the authentication module TPKI_ca, and the authentication policy module TPKI_aus may be physical, for example, distributed in different physical machines, or virtual, for example, different virtual modules distributed in a physical machine.
  • the method includes:
  • Step 510 in response to a request for public and private keys from a node in the blockchain network, through the public and private key generation module TPKI_sdk, generate the public and private keys of the node for the node and send them to the node;
  • Step 530 Receive the public key and registration information of the node through the authentication module TPKI_ca;
  • Step 550 the registration information is authenticated by the authentication module TPKI_ca;
  • Step 560 if the authentication is successful, a digital certificate of the node is generated and sent to the node through the authentication module TPKI_ca, the digital certificate contains plaintext information and a signature formed by using the private key of the authentication module TPKI_ca to form the plaintext information,
  • the plaintext information includes the public key of the node.
  • the public key (PublicKey) and the private key (Private) Key is a key pair (that is, a public key and a private key) obtained by an algorithm, the public key is the public part of the key pair, the private key It is a private part. Only the corresponding private key can decrypt the data encrypted with the public key, and only the corresponding public key can decrypt the data encrypted with the private key.
  • the public key of the node is generated by the public and private key generation module TPKI_sdk of the digital certificate issuing center 103, which is used to encrypt or decrypt the data transmitted between the nodes, and at the same time, when the digital certificate issuing center 103 issues the digital certificate for the node, the digital certificate and The relevance of the node's public key allows the digital certificate to prove that the public and private keys generated for the node are legitimate.
  • the public key of the authentication module TPKI_ca can be stored in the node, so that when the node obtains the digital certificate of the digital certificate issuing center 103, the public key of the authentication module TPKI_ca is used to pair the authentication module TPKI_ca with its own private key to form the digital certificate and the public key of the node To verify the signature and provide the credibility of the digital certificate.
  • the digital certificate issuing center 103 may further include an authentication policy module TPKI_aus, then before step 550, it may further include step 540 (the dotted line in FIG. 5 indicates that this step is optional), that is, through the authentication module TPKI_ca, Obtain the registration information authentication strategy corresponding to the node from the authentication strategy module TPKI_aus, so that when performing registration information authentication, that is, in step 550, the authentication module (TPKI_ca) can be used to authenticate based on the registration information corresponding to the node
  • the policy authenticates the registration information so that the authentication has a unified standard (see FIG. 5).
  • the public and private key generation module TPKI_sdk generates a public and private key pair for the node Bers and sends it to the node; in 6-4, the node Bers sends the registration information and public key to the authentication module TPKI_ca; in 6-5, the authentication The module TPKI_ca sends a registration information authentication strategy acquisition request to the authentication strategy module TPKI_aus; then the authentication strategy module TPKI_aus obtains the registration information authentication strategy corresponding to the node and returns the authentication strategy to the authentication module TPKI_ca in steps 6-6; if the authentication is successful The authentication module TPKI_ca will send a digital certificate to the node Bers in step 6-7; if the authentication fails, the authentication module TPKI_ca will send a reminder message to the node Bers in step 6-7.
  • Steps 510-560 are explained in detail below.
  • Step 510 in response to a request for public and private keys from a node in the blockchain network, through the public and private key generation module TPKI_sdk, generate the public and private keys of the node for the node and send them to the node.
  • the public-private key request is a request for nodes in the blockchain network to obtain a digital certificate from a digital certificate issuing center.
  • the public and private key requests may be network requests based on various network protocols, such as requests under HyperText Transfer Protocol (HTTP)/HTTPS protocol, such as requests generated using methods such as get and post.
  • HTTP HyperText Transfer Protocol
  • HTTPS HyperText Transfer Protocol
  • the public-private key pair generation method can be generated by using the existing command line tool of OpenSSL, a secure socket layer cryptographic library.
  • an asymmetric encryption algorithm library is set in the public and private key generation module TPKI_sdk, and the public and private key generation module TPKI_sdk randomly selects an asymmetric encryption algorithm from the asymmetric encryption algorithm library to generate the node for the node Public and private keys.
  • the public-private key request sent by a node in the blockchain network to the digital certificate issuing center contains the name of the asymmetric encryption algorithm
  • the public-private key generation module TPKI_sdk follows the name of the asymmetric encryption algorithm for the node Generate the public and private keys of the node.
  • the public-private key request sent by a node in the blockchain network to the digital certificate issuing center contains the type of the node.
  • the public-private key generation module TPKI_sdk is preset with the type of the node corresponding to the name of the asymmetric encryption algorithm Relationship table, the public-private key generation module TPKI_sdk searches the corresponding relationship table according to the type of the node in the public-private key request to obtain the corresponding asymmetric encryption algorithm name, and generates the node's Public key and private key.
  • the advantage of this embodiment is that a type of node, the asymmetric encryption algorithm suitable for it is often fixed. According to the type of the node, the appropriate asymmetric encryption algorithm is selected to generate the public and private keys, which improves the quality of the generated public and private keys.
  • an asymmetric encryption algorithm library is set in the public and private key generation module TPKI_sdk.
  • the asymmetric encryption algorithm in the asymmetric encryption algorithm library has a predetermined order, and the public and private key generation module TPKI_sdk is selected from the asymmetric encryption algorithm library in a predetermined order
  • the next asymmetric encryption algorithm of the previously selected asymmetric encryption algorithm generates the node's public and private keys for the node; if the previously selected asymmetric encryption algorithm is the last asymmetric encryption algorithm in the predetermined order ,
  • the first asymmetric encryption algorithm is selected to generate the public and private keys of the node for the node.
  • the method further includes: identifying the public and private keys of the node and the node Correspondingly, backup storage.
  • step 530 through the authentication module TPKI_ca, the public key and registration information of the node are received.
  • the public key of the node has been generated by the public and private key generation module TPKI_sdk and sent to the node.
  • the registration information may be information that the node needs to fill in when registering with the digital certificate issuing center 103, such as the unit name, taxpayer identification number, and the like.
  • the purpose of registering with the digital certificate issuing center 103 is to obtain a digital certificate, thereby proving that the public and private keys assigned to it are the public and private keys issued by the legal institution.
  • a digital certificate can only be issued to a node if the registration information has passed the authentication.
  • the public key and registration information of the node are encrypted with the public key of the authentication module TPKI_ca.
  • the advantage of this is that only the authentication module TPKI_ca can decrypt it if it has the private key of the authentication module TPKI_ca. Once intercepted by a third party during transmission, the third party does not have the private key of the authentication module TPKI_ca and cannot decrypt it, thereby ensuring the security of the transmission of node registration information.
  • step 540 through the authentication module (TPKI_ca), the registration information authentication strategy corresponding to the node is obtained from the authentication strategy module (TPKI_aus).
  • the registration information authentication strategy is a strategy based on reflecting the security requirements that the digital certificate can meet, and may be a strategy of one or more security rules. For example, verify those registration information, according to what standard verification, etc.
  • the registration information authentication strategy may be: the unit address is Shenzhen, and the unit number is greater than 500. That is, the blockchain network may be a blockchain network serving large and medium-sized units in Shenzhen. If it is a non-Shenzhen unit, or a small unit with a small number of people in Shenzhen, taking into account the cost of network maintenance, it may not pass its authentication, issue a digital certificate to it, or provide proof of legality for its public and private keys.
  • the registration information authentication strategy corresponding to the node does not mean that the registration information authentication strategy uniquely corresponds to the node, that is, the registration information authentication strategy can be used for the node or for all Nodes other than those mentioned.
  • the registration information authentication strategy may be a unique registration information authentication strategy common to all nodes, or may be a different registration information authentication strategy for each node.
  • the registration information authentication strategy corresponding to the node includes a registration information authentication strategy specific to the node type; the registration information contains the node type; the step 540 includes: The strategy module (TPKI_aus) obtains the registration information authentication strategy specific to the node type.
  • the registration information authentication strategy specific to the node type is determined according to the node type (eg, financial enterprise terminal, legal service company terminal) contained in the registration information.
  • the registration information authentication strategy for different node types may be different. For example, a financial company may have a relatively large profitability, requiring a registered capital of more than 2 million; a legal service company may have a relatively small profitability, requiring a registered capital of more than 100,000.
  • the advantage of this embodiment is that a certain type of node has similar characteristics. When examining whether a digital certificate can be issued for it, it often follows a similar standard. In this way, the accuracy of authentication is further improved.
  • the registration information of the node contains the specifications of the digital certificate to be applied for, which can indicate the security level of the digital certificate;
  • the authentication policy module TPKI_aus contains a correspondence table between the specifications of the digital certificate and the authentication strategy of the registration information Then, the registration information authentication strategy corresponding to the node is searched from the correspondence table of the digital certificate specifications and the authentication strategy according to the digital certificate specifications in the registration information.
  • the specification indicates the security level of the digital certificate.
  • the specification level 3 represents the highest security level
  • the specification level 2 represents the medium security level
  • the specification level 1 represents the lowest security level.
  • the higher the security level the higher the strictness of the certification, and the corresponding certification strategy may also be more or more demanding.
  • the advantage of this embodiment is that for different digital certificates of different security levels, different authentication strategies are set, and digital certificates of different security levels have different proving powers for the legality of public and private keys. In this way, the flexibility of digital certificate issuance can be enhanced.
  • the registration information authentication strategy is obtained from an intelligent agreement signed between the node stored on the blockchain and the blockchain network operator.
  • the node uses a blockchain network and must sign an intelligent protocol with the blockchain network operator in advance.
  • the intelligent protocol has a registration information authentication strategy at the time of authentication.
  • the smart protocol may be stored on the blockchain corresponding to the identification of the node. In this way, the identification of the node can be found from the block bodies of all the data blocks on the chain, and the smart protocol stored corresponding to the identification of the node can be found, and the registration information authentication strategy can be found from the smart protocol.
  • the advantage of this embodiment is that no additional authentication strategy needs to be set, and the authentication strategy in the smart protocol can be directly used to improve the efficiency of issuing digital certificates.
  • the authentication strategy module TPKI_aus contains a correspondence table between the request issuance period and the authentication strategy.
  • Step 540 includes:
  • the request issuance period is sent to the authentication strategy module TPKI_aus, so that the authentication strategy module TPKI_aus looks up the correspondence table between the request issuance period and the authentication strategy, and obtains the authentication strategy return corresponding to the request issuance period.
  • the authentication strategy for registration information is different every day from 9:00 to 17:00 and from 0:00 to 9:00 or 17:00 to 24:00 after get off work.
  • the time when the public key and registration information are received can be determined as the time when the digital certificate request is issued, whether the time for the request is issued falls at 9:00-17:00, or falls at 0:00-9:00 or 17:00- 24:00 means different authentication strategies.
  • the authentication strategy corresponding to the request issuance time period can be found from the correspondence table between the request issuance time period and the authentication strategy as the acquired registration information authentication strategy.
  • the advantage of this embodiment is that it fully considers the change of authentication strategy with different time periods in some scenarios, so that the digital certificate issuing system is more widely used.
  • step 550 the authentication information is authenticated based on the registration information authentication strategy corresponding to the node through the authentication module (TPKI_ca).
  • the registration information authentication strategy corresponding to the node may include multiple security rules. As mentioned above, the unit address is Shenzhen, and the unit number is greater than 500. For each security rule, authentication should consider whether the authentication information complies with the security rule. If all of them are met, the authentication is successful, otherwise the authentication fails.
  • step 560 if the authentication is successful, a digital certificate of the node is generated and sent to the node through the authentication module TPKI_ca, the digital certificate contains plaintext information and the private key formed by the authentication module TPKI_ca is used to form the plaintext information Sign so that the node verifies the signature using the public key of the authentication module TPKI_ca, and the plain text information includes the public key of the node.
  • generating the digital certificate of the node includes:
  • the plain text information including the public key of the node
  • the digital certificate is generated.
  • the predetermined digest algorithm may be, for example, a hash algorithm. Similar to the general process of generating a signature, in this embodiment, a digest is first generated for plaintext information, and then the digest is encrypted to obtain a signature. Then, put the signature and the plain text information together in the digital certificate. Since the plaintext information has the public key of the node, the correlation between the digital certificate and the issued public and private keys is established, so that the digital certificate can prove that a specific public and private key is legally issued.
  • the function of the signature is to facilitate the node to verify that the digital certificate is issued by a legal institution, namely the authentication module TPKI_ca, and improve the credibility of the digital certificate.
  • verifying the signature with the public key of the authentication module TPKI_ca includes:
  • each node of the blockchain network stores the public key of the authentication module TPKI_ca.
  • the public key of the authentication module TPKI_ca can be obtained from the public key stored by the node.
  • the public key of the authentication module TPKI_ca can be obtained from a data block that records the public key of the authentication module TPKI_ca on the blockchain. That is to say, the public key of the authentication module TPKI_ca is stored on the chain, for example, corresponding to the identification of the authentication module TPKI_ca in one transaction information of one data block.
  • the public key of the authentication module TPKI_ca is stored on the chain, for example, corresponding to the identification of the authentication module TPKI_ca in one transaction information of one data block.
  • the verification is successful. If the verification is not successful, it is likely that the digital certificate is not issued by the legal authentication module TPKI_ca. In this way, the security of the digital certificate itself is improved.
  • the node in addition to the above signature verification, the node also verifies the validity of the issuing authority.
  • the plaintext information further includes the identification information of the issuing authority, so that the node verifies the digital certificate according to the list of legal issuing authority identification information.
  • a list of legal issuer identification information may be stored, and the list of legal issuer identification information lists all legal issuer identification lists. As long as the identification information is in the list of legal issuer identification information, the issuer is legal. By comparing the identification information of the issuing organization in the plain text information with the identification information of each legal issuing organization in the list of legal issuing organization identification information, it can be judged whether the digital certificate is issued by a legal organization.
  • the advantage of the issuing agency’s legality verification is that it further improves the credibility of the digital certificate.
  • 17A and 17B are examples of digital certificate content issued by the digital certificate issuing center for the node when the node is an enterprise or a service provider. As shown in FIGS. 17A-B, both the digital certificate of the enterprise and the service provider includes plain text information and the signature of the plain text information.
  • the plaintext information of an enterprise may include the version number, serial number, signature algorithm, CA public key of the authentication module, enterprise identification, validity time, certificate status information and extended information in addition to the enterprise public key and the issuer identification .
  • the plaintext information of an enterprise may only include one of the version number, serial number, signature algorithm, certification module CA public key, corporate identity, validity time, certificate status information, and extended information or Many items may not be included.
  • the version number is the version identification of the blockchain.
  • the version identifier in the digital certificate issued by the digital certificate issuing center changes.
  • the serial number is the serial number of the issued digital certificate.
  • Each digital certificate has a unique serial number in the order of issuance.
  • the serial number can be generated in ascending order in ascending order.
  • the signature algorithm is a digest algorithm used to generate a digest of plaintext information when the authentication module CA generates a signature. It is sent back to the node so that when the node verifies the signature, the digest algorithm can be used to regenerate the digest of the plaintext information, so as to compare with the result of decrypting the signature.
  • the significance of sending the authentication module CA public key back to the node is that the node needs to use the authentication module CA public key to decrypt the signature when decrypting the signature.
  • the enterprise logo refers to a mark that uniquely distinguishes the enterprise.
  • the taxpayer identification number or the like can be used as the enterprise logo, or a special logo can be assigned to the enterprise.
  • the validity time refers to the deadline for the validity of the digital certificate.
  • the valid time should be verified according to the valid time in order to decide whether to return the queryed private key to the node.
  • the certificate status information refers to information indicating the status of the digital certificate, for example, whether the certificate is revoked, and if it is not revoked, the certificate status information is normal.
  • Extended information refers to information that needs to be added to the digital certificate according to actual needs.
  • FIG. 17B and FIG. 17A The difference between FIG. 17B and FIG. 17A is that it replaces the enterprise logo with the service provider logo and replaces the enterprise public key with the service provider public key.
  • the service provider logo refers to a mark that uniquely distinguishes service providers.
  • the service provider public key refers to the public key assigned to the service provider.
  • the digital certificate may be a structured data file, and the structured data file may be in various formats that can be recognized by the node, such as .cer or .crt format.
  • the digital certificate issuing center further includes a private key management module TPKI_pks.
  • the private key management module is a module that hosts the private key issued by the digital certificate issuing center to the node. As shown in FIG. 7, the method further includes after step 510:
  • Step 520 Receive and save the private key sent by the node through the private key management module TPKI_pks.
  • the advantage of this embodiment is that the node saves the private key by itself. If the machine fails and the memory is destroyed, the private key may be lost, and the private key is stored in the node's memory, which is easily stolen by a third party and managed There are no such problems.
  • the private key management module TPKI_pks can realize two-way interaction with the node Bers through 6-2 and 6-3.
  • the node generates the private key to the private key management module TPKI_pks.
  • the private key management module TPKI_pks confirms to the node that the private key has been hosted.
  • step 520 the receiving the private key sent by the node includes:
  • Step 523 Receive the first random session key encrypted by the node using the public key of the private key management module TPKI_pks;
  • Step 525 Receive the private key of the node encrypted by the node using the first random session key
  • Step 526 Using the first random session key obtained by decryption, decrypt the encrypted private key of the node to obtain the private key of the node.
  • step 523 the first random session key encrypted by the node using the public key of the private key management module TPKI_pks is received.
  • the first random session key is a session key randomly generated by the node when it wants to host the private key.
  • all nodes in the blockchain network store the public key of TPKI_pks.
  • the node can obtain the public key of the private key management module TPKI_pks from the stored public key.
  • the advantage of this embodiment is that it is simple and easy to use, saving time for obtaining the public key of TPKI_pks.
  • the public key of the private key management module TPKI_pks is stored on the blockchain, and the node can obtain the public key of the private key management module TPKI_pks from the data block on the blockchain that records the public key of the private key management module TPKI_pks key. That is to say, the public key of the private key management module TPKI_pks is stored on-chain, which can be stored in a data block corresponding to the identifier of the private key management module TPKI_pks.
  • step 524 the encrypted first random session key is decrypted using the private key of the private key management module TPKI_pks to obtain the first random session key.
  • step 525 the private key of the node encrypted by the node using the first random session key is received.
  • the third party even if the third party intercepts the encrypted first random session key, it cannot crack the first random session key, only the node and the private key management module TPKI_pks have the first random session key. Therefore, the private key of the node is encrypted with the first random session key and then transmitted to the private key management module TPKI_pks. Even if the encrypted private key of the node is intercepted by a third party, it cannot be cracked, which improves the node’s private key. Security of private key transmission.
  • step 526 the first random session key obtained by decryption is used to decrypt the encrypted private key of the node to obtain the private key of the node.
  • the advantage of this embodiment is that the process of transferring the private key of the above node uses two negotiation processes.
  • the first random session key is passed through the first negotiation process.
  • the public key of the private key management module TPKI_pks is used for encryption.
  • the private key management module TPKI_pks is used for decryption.
  • the private key of the node is transferred through the second negotiation process, and encrypted with the first random session key during transmission, and the private key management module TPKI_pks decrypts it with the first random session key after receiving it.
  • the third party intercepted the content passed in one of the negotiation processes and could not crack the private key of the node at all.
  • the private key management module TPKI_pks may be multiple private key management modules TPKI_pks dispersed in multiple locations. When any private key management module TPKI_pks receives the private key sent by the node, it can synchronize with the private key management module TPKI_pks of other locations.
  • the advantage of this embodiment is that the private key management module TPKI_pks is prevented from being set only in one place, so as to prevent the private key management module TPKI_pks from being damaged due to an attack and causing the loss of the private keys it hosts for all nodes.
  • the private key management module TPKI_pks when the private key management module TPKI_pks stores the private key, it can be encrypted with a symmetric encryption algorithm, such as data encryption standard (Data Encryption Standard, DES), advanced encryption standard (Advanced Encryption Standard) , AES), 3DES and other encryption algorithms.
  • the key that encrypts the private key may be hard-coded in the private key management module. In this way, even if the encrypted private key is stolen by a third party, since the key to encrypt the private key is hard-coded in the private key management module TPKI_pks, the third party still cannot decrypt the encrypted private key, which further improves the escrow The security of the private key.
  • step 520 further includes a process of verifying the legitimacy of the private key management module TPKI_pks. As shown in FIG. 10, step 520 also includes the following steps:
  • Step 521 through the authentication module TPKI_ca, receive a digital certificate acquisition request from the node's private key management module TPKI_pk.
  • the private key management module TPKI_pks digital certificate is the proof that the private key management module TPKI_pks has legal custody qualification.
  • the digital certificate may be issued by the authentication module TPKI_ca.
  • Step 522 through the authentication module TPKI_ca, send the digital certificate of the private key management module TPKI_pks to the node according to the digital certificate acquisition request, the digital certificate includes a signature using the private key of the authentication module (TPKI_ca), so that After receiving the digital certificate, the node uses the public key of the authentication module (TPKI_ca) for verification.
  • the private key management module TPKI_pks digital certificate contains plain text information and a signature generated by the private key of the authentication module TPKI_ca to the plain text information.
  • the plaintext information contains basic information of the private key management module TPKI_pks, such as name, registration number, registration time, granted rights, authorization time, etc.
  • the method of generating the signature is the same as above, so it will not be repeated here.
  • the method for verifying with the public key of the authentication module (TPKI_ca) is also the same as above, so it will not be described in detail.
  • the advantage of this embodiment is that the legitimacy of the private key management module TPKI_pks can be verified before hosting the private key of the node, and the security of private key escrow can be improved.
  • the node Bers when the node Bers wants to host its private key, it first sends a digital certificate acquisition request to obtain the private key management module TPKI_pks to the authentication module TPKI_ca. Then, the authentication module TPKI_ca returns the digital certificate of the private key management module TPKI_pks to the Bers node. Next, the node Bers will verify the digital certificate returned by the authentication module TPKI_ca. Then, if the digital certificate is successfully verified, the Bers node will generate the first random session key. Next, the Bers node uses the public key of the private key management module TPKI_pks to encrypt the generated first random session key.
  • the Bers node sends the encrypted first random session key to the private key management module TPKI_pks.
  • the private key management module TPKI_pks can decrypt the private key to obtain the first random session key.
  • the private key management module TPKI_pks can return a reminder message representing that the session key has been successfully obtained to the node Bers.
  • the node Bers can use the first random session key to encrypt various sensitive information including the node Bers private key.
  • the node Bers sends the encrypted private key and other sensitive information to the private key management module TPKI_pks.
  • the private key management module TPKI_pks uses the obtained first random session key to decrypt the encrypted private key to obtain the private key of the node Bers, and returns to the node Bers a reminder message that the private key is successfully managed. In this way, the entire scheme of the node Bers hosting the private key to the private key management module TPKI_pks is completed.
  • the node escrows the private key in the private key management module TPKI_pks.
  • the node can obtain its private key from the private key management module TPKI_pks. The process of obtaining the private key of the node from the private key management module TPKI_pks will be described below.
  • the method further includes steps 580 to 5100. As shown in FIG. 12, the method further includes the following steps:
  • Step 580 Receive the private key query request of the node through the private key management module TPKI_pks.
  • the private key query request is a request sent by the node to obtain the managed private key from the private key management module TPKI_pks, which may be a request created based on various network protocols, such as HTTP/HTTPS and other types of requests .
  • Step 590 Send the digital certificate query request of the node to the authentication module TPKI_ca through the private key management module TPKI_pks.
  • Step 5100 if a response to the successful digital certificate authentication generated by the authentication module (TPKI_ca) according to the digital certificate query request is received, send the private key of the node to the node according to the private key query request through the private key management module TPKI_pks .
  • the private key management module TPKI_pks only returns the managed private key to the sender of the request based on the private key query request, hackers and other criminals can easily use the fake request to steal the private key hosted on the private key management module TPKI_pks Key, causing serious losses. Therefore, only the nodes that have issued digital certificates can return their private keys. Because the digital certificate proves the legitimacy of the public and private keys, and because the digital certificate is requested by the node, it proves that the node has control over the public and private keys. Therefore, before returning the private key, the digital certificate query request of the node must be sent to the authentication module TPKI_ca. Only when the authentication module TPKI_ca finds that the node has a digital certificate, can the private key be returned for it.
  • both the private key query request and the digital certificate query request have the public key of the node.
  • the digital certificate has the public key of the node.
  • the authentication module TPKI_ca queries the digital certificate of the node according to the public key.
  • both the private key query request and the digital certificate query request have the identification of the node.
  • the digital certificate has the identification of the node, as shown in the enterprise identification of FIG. 17A and the service provider identification of FIG. 17B.
  • the authentication module TPKI_ca queries the digital certificate of the node according to the identifier of the node.
  • both the private key query request and the digital certificate query request have the serial number of the digital certificate.
  • the digital certificate has a serial number of the digital certificate.
  • the authentication module TPKI_ca queries the digital certificate of the node according to the serial number.
  • the process of sending the private key of the node to the node according to the private key query request by the private key management module TPKI_pks may include the following steps:
  • Step 5110 Receive a second random session key encrypted by the node using the public key of the private key management module TPKI_pks.
  • the public key of the private key management module TPKI_pks is the same as above, so it will not be described in detail.
  • the second random session key may be generated by the node using the same generation method, or may be generated using a different generation method.
  • Step 5120 decrypt the encrypted second random session key by using the private key of the private key management module TPKI_pks to obtain the second random session key.
  • Step 5130 query the private key of the node according to the private key query request.
  • step 525 includes receiving the private key and public key of the node encrypted by the node using the first random session key.
  • Step 526 includes: decrypting the encrypted private key and public key of the node by using the decrypted first random session key, and storing the obtained private key and public key correspondingly.
  • Step 5130 includes: querying the stored private key corresponding to the public key according to the public key of the node in the private key query request.
  • step 525 includes receiving the private key of the node encrypted by the node using the first random session key and the identification of the node.
  • step 526 includes: decrypting the encrypted private key of the node and the identification of the node using the first random session key obtained by decryption, and storing the obtained private key and the identification of the node correspondingly.
  • Step 5130 includes: querying the stored private key corresponding to the identification according to the identification of the node in the private key query request.
  • Step 5140 the second random session key is used to encrypt the private key of the node and sent to the node, so that the node decrypts the encrypted private key of the node using the second random session key to obtain The private key of the node.
  • the second random session key is generated based on a symmetric encryption algorithm.
  • the process of encrypting the node's private key using the second random session key, and decrypting the encrypted node's private key using the second random session key is the same as previously described using the first random session key to encrypt
  • the private key of the node is similar to the process of decrypting the encrypted private key of the node with the first random session key, so it will not be described in detail.
  • the two negotiations when querying the private key also achieve the effect of improving the security during the private key transmission process.
  • the blockchain includes multiple sub-blockchains.
  • different public and private key pairs may be required to further improve the security of the use of public and private keys on the blockchain. Even if a third party learns the public and private keys used for on-chain and query on a sub-blockchain, it is difficult to know the public and private keys used for on-chain and query in other sub-blockchains.
  • the public-private key request has the identity of the sub-blockchain to be registered.
  • the generating the public and private keys of the node for the node includes generating the public and private keys of the sub-blockchain to be registered for the node for the node. Specifically, according to the identifiers of the sub-blockchains to be registered in the public-private key request, the public and private keys on these sub-blockchains are generated for the node.
  • some of the sub-blockchains may not be used by the node, so it is only necessary to request the public and private keys on the sub-blockchains that it may use in the future.
  • Step 540 includes obtaining the registration information authentication strategy corresponding to the sub-blockchain to be registered from the authentication strategy module TPKI_aus. That is to say, each sub-blockchain has a different authentication strategy, and for each sub-blockchain to be registered by the node (sub-blockchain to be registered), a corresponding authentication strategy can be used for authentication.
  • Step 550 includes: performing authentication on the sub-blockchain to be registered based on the registration information authentication strategy corresponding to the sub-blockchain to be registered.
  • the plaintext information includes the public key on the successful sub-blockchain.
  • the node Since the node authenticates on each sub-blockchain to be registered separately, it may happen that some sub-blockchains to be registered are successfully authenticated, and some sub-blockchains to be registered fail to be authenticated.
  • the certificate is issued only to those sub-blockchains that have been successfully authenticated, that is, the plaintext information of the certificate includes only the public key on the sub-blockchain that has been successfully authenticated. In this way, only from the public key included in the plain text information of the digital certificate, it can be determined that the node has successfully authenticated and has authority on those sub-blockchains.
  • the sub-blockchains to be registered corresponding to the nodes are sub-blockchains 2 and 3, wherein the authentication strategy of sub-blockchain 2 is the address in Shenzhen, and the authentication strategy of sub-blockchain 3 is that the number of units exceeds 500, the enterprise is a Beijing factory with more than 2,000 employees. Therefore, the authentication of sub-blockchain 3 succeeds, and the authentication of sub-blockchain 2 fails. Only the public key of the sub-blockchain 3 is written into the plain text information of the digital certificate.
  • the advantage of this embodiment is that different sub-blockchains can be authenticated differently in the case of multiple sub-blockchains, and the authentication results of different sub-blockchains can be obtained, so that the digital certificate can prove the legitimacy of the public and private keys to the sub-region.
  • Blockchain improves the flexibility of using digital certificates.
  • the private key query request includes the sub-blockchain to which the private key to be queried belongs
  • the digital certificate query request of the node includes the sub-blockchain to which the private key to be queried belongs, so that the authentication
  • the module TPKI_ca determines whether to send a response of successful digital certificate authentication according to whether the sub-blockchain to which the private key to be queried belongs to the sub-blockchain corresponding to the public key of the authentication successful contained in the plain text information of the digital certificate.
  • the authentication module TPKI_ca may only query whether the digital certificate has been issued for the node based on the identification of the node in the digital certificate query request.
  • the private key management module TPKI_pks sends a response to digital certificate authentication success.
  • the sub-blockchain corresponding to these public keys is the sub-blockchain with which the node has authority, and digital certificate authentication can occur for it.
  • the successful response contains the sub-blockchain with successful authentication.
  • the private key management module TPKI_pks only returns the queried private key for the node based on the successfully authenticated sub-blockchain. For example, the node may request the private keys on sub-blockchains 2 and 3, but the authentication module TPKI_ca queries its digital certificate and finds that the digital certificate contains only the public key on sub-blockchain 3. Therefore, only the private key on the sub-blockchain 3 is returned to the node.
  • the advantage of this embodiment is that in the case of a multi-sub-blockchain, the flexibility of querying the escrowed private key is improved.
  • the node can only query those private keys that have been authenticated and have corresponding public keys in the digital certificate.
  • the authentication module TPKI_ca sends a response to the digital key authentication success to the private key management module TPKI_pks. In addition to the above verification, it also needs to verify whether the digital certificate has expired. If it expires, the digital certificate needs to be re-registered. As shown in FIGS. 17A-17B, the plaintext information also includes the validity time. After sending the node's digital certificate query request to the authentication module TPKI_ca through the private key management module TPKI_pks, the authentication module TPKI_ca finds the digital certificate corresponding to the node, and compares the validity time in the digital certificate with the current time. The digital certificate is validated for validity. Only when the valid time is verified successfully, a response of successful digital certificate authentication is sent to the private key management module TPKI_pks.
  • the validity time may be the expiration time of the digital certificate. If the validity time is earlier than the current data, the verification fails. If the valid time is later than the current time, the verification is successful.
  • the advantage of this embodiment is that the validity of the digital certificate is verified, which further improves the credibility of the digital certificate.
  • the authentication module TPKI_ca sends a response to the digital key authentication success to the private key management module TPKI_pks.
  • the plain text information also includes certificate status information.
  • the authentication module TPKI_ca performs status verification on the digital certificate based on the certificate status information. Send a response to digital certificate authentication to the private key management module TPKI_pks.
  • the certificate status information indicates that the digital certificate is normal, the status verification is successful; if it indicates that the digital certificate is revoked, the status verification fails.
  • the advantage of this embodiment is that the status of the digital certificate is verified, which further improves the credibility of the digital certificate.
  • the nodes include unit nodes and service provider nodes.
  • a service provider refers to a unit that neither has its own conditions for chaining or querying transaction information (ie, it is not the accounting node 101 in FIGS. 1A-1C), nor does it have an entrusted accounting node 101 to chain transaction information or
  • the query conditions that is, not the transaction information producer node 102 in FIG. 1A, nor the business node 105 in FIGS. 1B-1C
  • receive the entrustment of these units receive the entrustment of these units, and entrust the accounting node 101 with the transaction information for these units.
  • the entity being queried Of course, there are also some situations where you have the conditions to upload or query transaction information, or to entrust the accounting node 101 to upload or query transaction information, but still entrust a service provider to upload or query.
  • the service provider replaces some units for entrusted transaction information on-chain and query.
  • the private key of the query may not only be its own private key, but the page may be the private key of its trusted unit node. Therefore, the authority information possessed by the service provider node is recorded and saved when the digital certificate is issued for it.
  • the private key query request includes the identification of the service provider node and the identification of the node to which the key to be queried by the service provider node, the authentication module TPKI_ca according to the storage
  • the authority information of the server determines whether the identifier of the node to which the key to be queried by the service provider node belongs is the identity of the unit or service provider node served by the service provider node. If yes, the authentication is successful. Otherwise, authentication fails.
  • the receiving of the public key and registration information of the node includes: receiving the public key of the node, registration information, and authority information of a unit served by the service provider node.
  • the service provider node A replaces the unit nodes A1, A2, and A3 to entrust or query the entrusted transaction information
  • the authority information includes A1, A2, and A3.
  • the digital certificate issuing center further includes an authentication strategy module (TPKI_aus)
  • the method further includes:
  • the authority information storage is sent to the authentication policy module TPKI_aus through the authentication module TPKI_ca.
  • the identifier of the node may be stored in correspondence with the authority information.
  • the private key query request includes the identifier of the service provider node and the identifier of the node to which the key to be queried by the service provider node, the authentication module TPKI_ca according to the In the authority information, if the identifier of the node to which the key to be queried by the service provider node belongs is the identity of the unit or service provider node served by the service provider node, the authentication is successful.
  • the authorization information of the service provider node A stored in the authentication policy module TPKI_aus includes unit nodes A1, A2, and A3. If the key to be queried by the service provider node is the private key of one or more of A1, A2, A3, and A When the key is successfully authenticated, the private key can be returned.
  • the advantage of this embodiment is that it provides support for the implementation of private key management technology for the scenario where the service provider node replaces multiple unit nodes for commissioning or querying.
  • the sub-blockchain is often specific to a certain data block of transaction information, for example, one sub-blockchain records the transaction data block of supply chain finance, and the other block-chain records the transaction data of electronic invoices. Blocks, etc.
  • the transaction type of a type of node is also relatively fixed, so the sub-blockchain that needs to be recorded is also relatively fixed. Therefore, in one embodiment, the permission of the sub-blockchain can be automatically set for the node according to its transaction type. For example, for automobile manufacturing companies, they often need supply chain financial services, but they also implement electronic invoices. Therefore, a sub-blockchain of supply chain finance and a sub-blockchain of electronic invoices are required.
  • the blockchain includes multiple sub-blockchains, and the registration information includes node types.
  • the generating of the public and private keys of the node for the node includes generating the public and private keys of the node on different sub-blockchains for the node. Assuming that there are N sub-blockchains in total, N public-private key pairs corresponding to the N sub-blockchains can be generated for the node.
  • step 550 after authenticating the registration information through the authentication module TPKI_ca, the method further includes:
  • the authentication module TPKI_ca If the authentication is successful, through the authentication module TPKI_ca, generate sub-blockchain authority information specific to the node type based on the node type, and store the sub-blockchain authority information in the authentication policy module TPKI_aus, the sub-blockchain authority
  • the information includes sub-blockchains that allow queries for different business types.
  • the sub-blockchain authority information specific to the node type may be obtained by searching a preset correspondence table between the node type and the sub-blockchain authority information according to the node type.
  • the sub-blockchain authority information corresponding to the automobile manufacturing enterprise is: for the supply chain financial business type, the sub-blockchain allowed to query is sub-blockchain 2; for the electronic invoice business type, the query is allowed The sub-blockchain is sub-blockchain 3. Then, store the sub-blockchain authority information in the authentication policy module TPKI_aus.
  • the private key query request has the node type and service type
  • the digital certificate query request also has the node type and service type.
  • the authentication module TPKI_ca queries the sub-blockchain authority information specific to the node type from the authentication policy module TPKI_aus, and determines the sub-blockchain that is allowed to query based on the sub-blockchain authority information and the business type, which will allow the query
  • the sub-blockchain of is placed in the successful response of digital certificate authentication and sent to the private key management module TPKI_pks.
  • the sending the private key of the node to the node includes sending the private key of the node on the sub-blockchain that allows query to the node.
  • the node type is an automobile manufacturing enterprise node
  • the business type is electronic invoice.
  • the authentication module TPKI_ca first queries the node type in the request, that is, the automobile manufacturing enterprise node, from the authentication strategy module TPKI_aus to query its corresponding sub-blockchain authority information, that is, for the type of supply chain financial business, the query is allowed
  • the blockchain is sub-blockchain 2; for the type of electronic invoice business, the sub-blockchain allowed to query is sub-blockchain 3. Then, according to the type of business in the digital certificate query request, that is, electronic invoice, it is determined that the sub-blockchain that is allowed to query is sub-blockchain 3.
  • the private key management module TPKI_pks only returns the private key of the node on the sub-blockchain 3 to the node, and does not return the private key on the other sub-blockchain to the node.
  • the advantage of this method is that in the case of a multi-sub-blockchain, users can accurately find the private key on the sub-blockchain that is suitable for the node type and business type for users. Fine management of escrow private keys.
  • FIG. 14 is a detailed interaction flowchart of querying the managed private key by the node.
  • Node Bers needs to query the private key management module TPKI_pks for its private key, and first sends a private key query request to the private key management module TPKI_pks for its private key.
  • the private key management module TPKI_pks sends a digital certificate query request to the authentication module TPKI_ca.
  • the authentication module TPKI_ca verifies whether the node has a digital certificate, and whether the digital certificate has expired, whether it has been revoked, etc. If these verifications are passed, a response to the digital certificate authentication success is sent to the private key management module TPKI_pks.
  • the private key management module TPKI_pks will then send a request to the node Bers instructing it to send the session key.
  • Node Bers generates a second random session key and encrypts the second random session key with the public key of the private key management module TPKI_pks.
  • Node Bers sends the encrypted second random session key to the private key management module TPKI_pks.
  • the private key management module TPKI_pks After receiving the encrypted second random session key, the private key management module TPKI_pks first decrypts the encrypted second random session key with the private key of its own private key management module TPKI_pks to obtain the second random session key. Then, it encrypts the private key hosted by the node with the second random session key and sends it to the node Bers.
  • the registration information includes an identification of the node.
  • the digital certificate issuing center includes an authentication database TPKI_cadb, as shown in FIG. 15.
  • the authentication database TPKI_cadb is a database for storing issued digital certificates.
  • Step 570 After generating the digital certificate of the node through the authentication module TPKI_ca, the method further includes: Step 570, through the authentication module TPKI_ca, storing the identifier of the node and the digital certificate of the node in the authentication database TPKI_cadb correspondingly.
  • the private key query request includes the identification of the node
  • the digital certificate query request includes the identification of the node
  • the authentication module TPKI_ca corresponds to the identification in the authentication database TPKI_cadb
  • the stored digital certificate determines whether the authentication is successful. That is to say, when the authentication module TPKI_ca receives the digital certificate query request and queries the digital certificate possessed by the node to determine whether to send the digital certificate authentication response to the private key management module TPKI_pks, it follows the digital certificate query request The identification of the node mentioned in the search for the corresponding digital certificate in the authentication database TPKI_cadb.
  • FIG. 16 shows a detailed module diagram of a digital certificate issuing center according to an embodiment of the present application.
  • the digital certificate issuing center also includes registration Module TPKI_ra.
  • the registration module TPKI_ra is a module that passes the public key and registration information received from the node Bers to the authentication module TPKI_ca, and returns the generated digital certificate to the node Bers. It is an intermediary module between the node Bers and the authentication module TPKI_ca.
  • step 530 includes receiving the public key and registration information of the node forwarded by the registration module TPKI_ra.
  • Sending the digital certificate to the node in step 560 includes sending the digital certificate to the node via the registration module TPKI_ra.
  • a digital certificate issuing center including:
  • the public-private key generation module TPKI_sdk is used to generate a public and private key for the node and send it to the node in response to the public-private key request from the node in the blockchain network;
  • the authentication module TPKI_ca is used to receive the public key and registration information of the node, and authenticate the registration information. If the authentication is successful, a digital certificate of the node is generated and sent to the node.
  • the digital certificate contains plain text information And using the private key of the authentication module TPKI_ca to sign the plaintext information, so that the node uses the public key of the authentication module TPKI_ca to verify the signature, and the plaintext information includes the public key of the node.
  • the digital certificate issuing center further includes an authentication strategy module TPKI_aus, and an authentication strategy module TPKI_aus, which is used to store the registration information authentication strategy corresponding to each node in the blockchain network.
  • the digital certificate issuing center further includes: a private key management module TPKI_pks for receiving and storing the private key sent by the node.
  • TPKI_pks for receiving and storing the private key sent by the node.
  • the authentication module TPKI_ca is used to:
  • the authentication module TPKI_ca is also used for:
  • the private key management module TPKI_pks is also used to:
  • the private key management module TPKI_pks sends the node’s private key to the node according to the private key query request key.
  • the private key management module TPKI_pks is also used to:
  • the registration information includes an identification of the node.
  • the digital certificate issuing center includes an authentication database TPKI_cadb, which is used to store the identifier of the node corresponding to the digital certificate of the node; the private key query request includes the identifier of the node, The digital certificate query request includes the identification of the node, so that the authentication module TPKI_ca determines whether the authentication is successful according to whether there is a digital certificate stored in the authentication database TPKI_cadb corresponding to the identification.
  • the nodes include unit nodes and service provider nodes
  • the authentication module TPKI_ca is also used to: if the authentication is successful, send the authority information storage to the authentication strategy module TPKI_aus;
  • the private key query request includes the identifier of the service provider node and the identifier of the node to which the key to be queried by the service provider node; the authentication module TPKI_ca is also used to: according to the authority stored in the authentication policy module TPKI_aus Information, when it is determined that the identifier of the node to which the key to be queried by the service provider node belongs is the unit served by the service provider node or the identification of the service provider node, the authentication is successful.
  • the registration information authentication strategy corresponding to the node includes a registration information authentication strategy specific to the node type; the registration information contains the node type; the authentication module TPKI_ca is also used to : Obtain the registration information authentication strategy specific to the node type from the authentication strategy module TPKI_aus.
  • the private key query request includes the sub-blockchain to which the private key to be queried belongs
  • the digital certificate query request of the node includes the sub-blockchain to which the private key to be queried belongs, so that the authentication
  • the module TPKI_ca determines whether to send a response of successful digital certificate authentication according to whether the sub-blockchain to which the private key to be queried belongs to the sub-blockchain corresponding to the public key of the authentication successful contained in the plain text information of the digital certificate.
  • the blockchain includes multiple sub-blockchains; the registration information includes the node type; and the public-private key generation module TPKI_sdk is used to: generate the node in different sub-blockchains for the node The public key and private key on the Internet; if the digital certificate issuing center also includes an authentication policy module TPKI_aus, the authentication module TPKI_ca is also used to: after the authentication of the registration information, if the authentication is successful, based on the type of the node The sub-blockchain authority information of the node type, and store the sub-blockchain authority information in the authentication policy module TPKI_aus, the sub-blockchain authority information includes sub-blockchains that are allowed to be queried for different business types; The private key query request has the node type and service type; the digital certificate query request has the node type and service type; the authentication module TPKI_ca queries the sub-blockchain specific to the node type from the authentication policy module TPKI_aus Permission information, based on the sub-blockchain permission information and
  • the private key stored in the private key management module TPKI_pks is stored in an encrypted manner, and the password used for encryption is hard-coded in the private key management module TPKI_pks.
  • the method for issuing digital certificates for nodes in the blockchain network may be implemented by the digital certificate issuing center 103 in FIG. 18.
  • the digital certificate issuing center 103 according to an embodiment of the present application will be described below with reference to FIG. 18.
  • the digital certificate issuing center 103 shown in FIG. 18 is only an example, and should not bring any limitation to the functions and usage scope of the embodiments of the present application.
  • the digital certificate issuing center 103 is expressed in the form of a general-purpose computing device.
  • the components of the digital certificate issuing center 103 may include, but are not limited to: the at least one processing unit 710, the at least one storage unit 720, and a bus 730 connecting different system components (including the storage unit 720 and the processing unit 710).
  • the storage unit stores a program code
  • the program code can be executed by the processing unit 710, so that the processing unit 710 executes various exemplary according to the present invention described in the description section of the above exemplary method of this specification Implementation steps.
  • the processing unit 710 may perform various steps as shown in FIG. 5.
  • the storage unit 720 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) 7201 and/or a cache storage unit 7202, and may further include a read-only storage unit (ROM) 7203.
  • RAM random access storage unit
  • ROM read-only storage unit
  • the bus 730 may represent one or more of several types of bus structures, including a storage unit bus or a storage unit controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local area using any of a variety of bus structures bus.
  • the digital certificate issuing center 103 can also communicate with one or more external devices 900 (such as keyboards, pointing devices, Bluetooth devices, etc.), and can also communicate with one or more devices that enable users to interact with the accounting node 21, and /Or communicate with any device (such as a router, modem, etc.) that enables the digital certificate issuing center 103 to communicate with one or more other computing devices. Such communication may be performed through an input/output (I/O) interface 750. Moreover, the digital certificate issuing center 103 can also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN) and/or a public network, such as the Internet) through a network adapter 760.
  • LAN local area network
  • WAN wide area network
  • public network such as the Internet
  • the network adapter 760 communicates with other modules of the digital certificate issuing center 103 through the bus 730. It should be understood that although not shown in the figure, other hardware and/or software modules may be used in conjunction with the digital certificate issuing center 103, including but not limited to: microcode, device driver, redundant processing unit, external disk drive array, RAID system, Tape drives and data backup storage systems, etc.
  • the example embodiments described here can be implemented by software, or can be implemented by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, U disk, mobile hard disk, etc.) or on the network , Including several instructions to enable a computing device (which may be a personal computer, server, terminal device, or network device, etc.) to perform the method according to the embodiments of the present application.
  • a computing device which may be a personal computer, server, terminal device, or network device, etc.
  • a computer program medium on which computer readable instructions are stored, and when the computer readable instructions are executed by a processor of a computer, the computer is caused to perform the above method embodiments Partially described method.
  • a program product for implementing the method in the above method embodiment which may use a portable compact disk read-only memory (CD-ROM) and include a program code, and may be used in a terminal Devices, such as personal computers.
  • CD-ROM portable compact disk read-only memory
  • the program product of the present invention is not limited to this.
  • the readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, apparatus, or device.
  • the program product 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 be, for example but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of readable storage media (non-exhaustive list) include: electrical connections with one or more wires, portable disks, hard disks, 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), optical storage device, magnetic storage device, or any suitable combination of the foregoing.
  • the computer-readable signal medium may include a data signal that is transmitted in baseband or as part of a carrier wave, in which readable program code is carried. This propagated data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.
  • the readable signal medium may also be any readable medium other than a readable storage medium, and the readable medium may send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device.
  • the program code for performing the operations of the present invention can be written in any combination of one or more programming languages including object-oriented programming languages such as Java, C++, etc., as well as conventional procedural Programming language-such as "C" language or similar programming language.
  • the program code may be executed entirely on the user computing device, partly on the user device, as an independent software package, partly on the user computing device and partly on the remote computing device, or entirely on the remote computing device or server To execute.
  • the remote computing device may be connected to the user computing device through any kind of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (eg, using Internet service provision Business to connect via the Internet).
  • LAN local area network
  • WAN wide area network
  • Internet service provision Business to connect via the Internet
  • the example embodiments described here can be implemented by software, or can be implemented by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, U disk, mobile hard disk, etc.) or on the network , Including several instructions to enable a computing device (which may be a personal computer, server, mobile terminal, or network device, etc.) to perform the method according to the embodiments of the present application.
  • a computing device which may be a personal computer, server, mobile terminal, or network device, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了一种发放数字证书的方法、数字证书颁发中心和介质。所述方法由数字证书颁发中心执行，所述数字证书颁发中心包括公私钥生成模块和认证模块。所述方法包括：响应于来自区块链网络中的节点的公私钥请求，通过公私钥生成模块，为节点生成节点的公钥和私钥并发送到所述节点；通过认证模块，接收所述节点的公钥和注册信息，并对注册信息进行认证；如果认证成功，通过认证模块，生成所述节点的数字证书并发送给所述节点。本申请实施例能够提高颁发的数字证书的证明力，提高区块链网络中数据交换的安全性。

Description

发放数字证书的方法、数字证书颁发中心和介质
本申请要求于2019年1月9日提交中国专利局、申请号201910020435.5、申请名称为“发放数字证书的方法、数字证书颁发中心和介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及区块链领域，具体涉及一种为区块链网络中的节点发放数字证书的技术。
背景技术
在传统的区块链网络体系下，公有链、联盟链以及私有链都是技术发展的产物，公有链可以实现高度去中心化，可信度和安全性最高，但交易速度最慢；私有链所能实现的去中心化的程度很低，但交易速度快，最适用于监管；而联盟链可以实现部分去中心化，去中心化的程度介于公有链和私有链之间，交易速度较快，可监管性也很高。三种类型的区块链特点不同，适用的场景不同。
无论是哪种区块链网络体系，在数据区块上链和查询的过程经常需要在区块链网络体系中传递一些数据，如上链信息、查询请求等。为了增加安全性，往往要求发送方传送数据时对数据利用发送方的密钥进行签名，在接收方接收到签名和数据时用发送方的密钥进行签名验证，这就涉及发送方密钥的获取。为了保障密钥的安全性和权威性，需要为发送方颁发数字证书，证明发放的密钥是安全且权威的。然而，现有技术中为节点颁发数字证书的过程是孤立的，节点具有被分配的密钥且被颁发数字证书，但现有技术的颁发数字证书过程并不能证明该颁发的数字证书一定对应于该密钥，数字证书证明力较差，权威性也差。
发明内容
本申请的一个目的在于提出一种为区块链网络中的节点发放数字证书的方法、数字证书颁发中心和介质，能够提高颁发的数字证书的证明力，提高区块链网络中数据交换的安全性。
根据本申请实施例的一方面，公开了一种为区块链网络中的节点发放数字证书的方法，所述方法由数字证书颁发中心执行，所述数字证书颁发中心包括公私钥生成模块和认证模块，所述方法包括：响应于来自区块链网络中的节点的公私钥请求，通过公私钥生成模块，为所述节点生成所述节点的公钥和私钥并发送到所述节点；通过认证模块，接收所述节点的公钥和注册信息；通过认证模块对所述注册信息进行认证；如果认证成功，通过认证模块，生成所述节点的数字证书并发送给所述节点，所述数字证书包含明文信息和利用认证模块的私钥对所述明文信息形成的签名，以便所述节点利用认证模块的公钥对所述签名进行验证，所述明文信息包括所述节点的公钥。
根据本申请实施例的一方面，公开了一种数字证书颁发中心，所述数字证书颁发中心包括：公私钥生成模块，用于响应于来自区块链网络中的节点的公私钥请求，为所述节点生成所述节点的公钥和私钥并发送到所述节点；认证模块，用于接收所述节点的公钥和注册信息，对所述注册信息进行认证，如果认证成功，生成所述节点的数字证书并发送给所述节点，所述数字证书包含明文信息和利用认证模块的私钥对所述明文信息形成的签名，以便所述节点利用认证模块的公钥对所述签名进行验证，所述明文信息包括所述节点的公钥。
根据本申请实施例的一方面，公开了一种数字证书颁发中心，包括：存储器，存储有计算机可读指令；处理器，读取存储器存储的计算机可读指令，以执行如上所述的方法。
根据本申请实施例的一方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的方法。
根据本申请实施例的一方面，公开了一种计算机程序产品，包括指令，当其在计算机上运行时，使得计算机执行如上所述的方法。
现有技术对数字证书的发放是孤立的，因此，对于节点的公私钥的合法性证明力较差。本申请实施例中，数字证书颁发中心包括公私钥生成模块和认证模块。公私钥生成模块为节点生成公私钥后，节点要将公钥和注册信息一起发送给认证模块进行认证。认证成功后向节点返回的数字证书中含有公钥。这样，就使得数字证书对颁发的公私钥的证明力较强。且在数字证书中含有用认证模块的私钥进行的签名，返回给所述节点后，所述节点可以对该签名利用认证模块的公钥进行签名验证。由于该签名是可验证的，提高了该数字证书的证明力和公信力。从而，用该数字证书作为保障的公私钥来在区块链网络中交换数据，提高了区块链网络中数据交换的安全性。
本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。
附图说明
通过参照附图详细描述其示例实施例，本申请的上述和其它目标、特征及优点将变得更加显而易见。
图1A-1C示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法的三种体系构架图；
图2示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法应用电子***应用场景下的场景构架图；
图3A-3K示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法应用在电子***应用场景下的节点显示界面图；
图4A-4K示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法应用在电子***应用场景下的节点显示界面图；
图5示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法的流程图；
图6示出了根据本申请一个实施例的数字证书颁发中心中的各模块之间以及和所述节点之间的交互示意图；
图7示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法的流程图；
图8示出了根据本申请一个实施例的数字证书颁发中心中的各模块之间以及和所述节点之间的交互示意图；
图9示出了根据本申请一个实施例的接收由节点发送的私钥的方法流程图；
图10示出了根据本申请一个实施例的接收由节点发送的私钥的方法流程图；
图11示出了根据本申请一个实施例的节点向私钥管理模块托管私钥时的交互流程图；
图12示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法的流程图；
图13示出了根据本申请一个实施例的私钥管理模块TPKI_pks向节点发送节点的私钥的方法流程图；
图14示出了根据本申请一个实施例的节点向私钥管理模块获取已托管私钥时的交互流程图；
图15示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法的流程图；
图16示出了根据本申请一个实施例的数字证书颁发中心的详细模块图；
图17A-17B示出了根据本申请一个实施例的数字证书颁发中心颁发的数字证书的示意图；
图18示出了根据本申请一个实施例的数字证书颁发中心的硬件结构图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本申请的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本申请的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。
此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本申请的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本申请的各方面变得模糊。
附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
本申请实施例提供的方法应用到区块链中，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。
区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。
平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。
下面先参照图1A-1C描述一下本申请实施例所应用的体系构架和整体流程。
图1A示出了本申请实施例所应用的一种区块链网络的体系构架。该体系构架包括记账节点网络100、交易信息产生方节点102和数字证书颁发中心103，其中记账节点子网络100包括多个记账节点101。交易信息产生方节点102和记账节点101在整个区块链体系构架下的权限不同，记账节点101具有记账权(产生数据区块并将数据区块上链的权利)，而交易信息产生方节点102没有记账权只有产生交易信息并申请记账的权利，且不能检验记 账节点101的记账是否正确，只能被动地相信记账节点101的记账。每个交易信息产生方节点102有其对应的记账节点101。当交易信息产生方节点102产生交易信息后，可以将交易信息发送给对应记账节点101申请记账，从而完成上链。
记账节点子网络100中包括的记账节点101彼此之间以及记账节点101和交易信息产生方节点102之间在上述数据区块上链过程中需要交换各种信息。为了保障交换的信息安全性，发送方需要对信息利用该发送方的私钥进行签名，并与信息一起传输。接收到签名和信息的节点可以对该签名利用该发送方的公钥进行验证。由于公私钥的存在，数字证书颁发中心103的作用就体现了出来，数字证书颁发中心103能够对公私钥的合法性进行确认。
图1B示出了本申请实施例所应用的另一种区块链网络的体系构架。该体系构架包括记账节点子网络100、业务节点子网络104和数字证书颁发中心103。该体系构架与图1A的体系构架不同之处在于，包括由业务节点102构成的业务节点子网络104。业务节点103与图1A中的交易信息产生方节点102的区别在于，业务节点102虽然不能记账，但能够对记账节点101的记账进行验证。记账节点子网络100和业务节点子网络104之间通过代理节点105连接。代理节点105是属于业务节点子网络104的一个特殊节点。代理节点105的数据传递方式是双向的，它能将记账节点101要向业务节点102传递的信息传递给业务节点102，也可以将业务节点102产生的交易信息发送给记账节点101以完成上链。业务节点102产生各种需上链的交易信息，通过代理节点105传递给一个记账节点101。记账节点101通过所有记账节点101中选举出的领导记账节点将多个接收到的交易信息打包上链。领导记账节点对打包的多个交易信息生成摘要，并用领导记账节点的私钥生成签名，将摘要和签名放到区块头中发回业务节点102。业务节点102可以利用领导记账节点的公钥对该签名进行签名验证。在这里，涉及到领导记账节点的公私钥，因此，需要数字证书颁发中心103颁发的数字证书来保证领导记账节点的公私钥的合法性。
业务节点102仅接收到从记账节点101发过来的区块头，如果想要查询区块体中的具体交易信息，其需要向代理节点105发送对交易信息的查询请求。为了验证查询请求是合法的业务节点102发出的，业务节点102需要用该业务节点102的私钥对查询请求签名，代理节点105对查询请求用该业务节点102的公钥进行签名验证，以证明查询请求是业务节点102发出的，且传输无丢失。在这里，涉及到业务节点的公私钥，因此，需要数字证书颁发中心103颁发的数字证书来保证业务节点的公私钥的合法性。
图1C示出了本申请实施例所应用的另一种区块链网络的体系构架。该体系构架与图1B的体系构架不同之处在于，其记账节点子网络100分成了多个分支记账节点子网络。每个分支记账节点子网络可以负责某一种类型的交易信息的记录。例如，分支记账节点子网络A中的记账节点负责区块链金融交易信息的记录，分支记账节点子网络B中的记账节点负责电子***交易信息的记录。图1C中也需要领导记账节点的公私钥或业务节点102的公私钥进行签名和签名验证，其过程与图1B类似。
图2示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法应用在电子***的应用场景下的场景构架图。
在传统方式下，都是通过中心化的数据库完成电子***的开具等业务流程；随着区块链技术的出现，***上链已经取得一定的应用方面的成果。在这种电子***的区块链应用场景下，传统中心化的电子***业务流程中的交易行为，如地税局向开票企业发放***、开票企业向领票人开出***、领票人向领票人所在的报销单位报销***等交易行为都需要上链，即记录到区块链上。
在地税局向开票单位发放***、开票单位向领票人开出***等事件中，地税局终端、开票单位等业务节点102将发放***、开票等交易信息发送到记账节点子网络100上链。领导记账节点上链后，如结合图1B所述，在领导记账节点向业务节点102发送区块头的过程中、以及业务节点102查询区块体中的交易信息的过程中，分别需要用领导记账节点的私钥对区块体签名，以及用业务节点102的私钥对查询请求签名。在业务节点102和代理节点105分别用领导记账节点的公钥和业务节点102的公钥验证签名时，分别使用领导记账节点的公钥和业务节点102的公钥。因此，需要发放数字证书保证这些公私钥的合法性，从而产生了本申请实施例的为区块链网络中的节点发放数字证书的方法。
图3A-3K示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法应用在电子***应用场景下的开票终端节点显示界面图，这些界面图表示了电子***应用场景下图1A所示的体系构架下记账节点网络100外的交易信息产生方节点102申请数字证书和将交易信息上链的大体过程。
如图3A所示，开票单位终端在发生开票行为之前，由于将交易信息传递给记账节点101记账的过程中需要将交易信息签名，必须首先具有公私钥。因此，在图3A的界面中，显示“请求发放公私钥”的提示，当点击“确定”时，开票单位终端向数字证书颁发中心103请求发放公私钥。
如图3B所示，数字证书颁发中心103会根据开票单位终端的请求，生成一对公私钥对，并向开票单位终端返回公私钥对。开票单位终端可以选择将私钥自己保存，也可以将私钥托管到数字证书颁发中心，以防终端故障时导致保存在自己终端的私钥丢失。
因此，在返回公私钥对时，如图3B的界面所示，可以显示“是否托管私钥”的提示，当选择托管时，管理员可以点击图3B所示的“是”，私钥被数字证书颁发中心103托管。如图3C所示，显示“私钥托管成功”的提示。
为了证明该公私钥是合法机构颁发的统一的公私钥，需要申请数字证书证明该公私钥的合法性。如图3D所示，在开票单位终端填写单位名称、纳税人识别号等注册信息。管理员点击“确定”后，将发放的公钥和注册信息提交到数字证书颁发中心103。
数字证书颁发中心103接收到注册信息后，对注册信息进行认证，如果通过，向开票单位终端发放数字证书。数字证书含有图3E所示的版本号、签名算法、认证模块公钥、开 票单位公钥等明文信息、和用认证模块的私钥对明文信息进行的签名。由于该数字证书中含有开票单位公钥，与公私钥形成绑定关系，证明了该发放的公私钥是合法的。
开票单位终端接收到数字证书后，管理员可以点击“验证”，从而利用认证模块的公钥对数字证书中的签名进行验证。如果验证通过，证明该数字证书是由合法机构颁发的，显示图3F所示的数字证书验证成功的提示。
当开票单位终端开出***时，需要将开票信息上链，这时在图3G的界面上填写开票单位、***标识等交易信息。管理员点击“发送到记账节点”后，指示将这些交易信息发送到对应的记账节点101。
为了保障交易信息发送方的合法性和交易信息传输的完整性，需要对交易信息签名。签名需要使用开票单位终端的私钥。由于该私钥在图3B的界面上被选择托管，这时需要从数字证书颁发中心103获取托管的私钥。管理员在图3H的界面上选择“是”。
当从数字证书颁发中心103获取到托管的私钥后，显示图3I所示的提示界面。管理员在该界面上点击“签名并发送”，用开票单位终端的私钥对交易信息签名，并发送给记账节点101。
记账节点101接收到开票单位终端的签名后，对该签名用开票单位终端的公钥进行验证。验证成功后，通知开票单位终端验证成功。开票单位终端上显示如图3J所示的界面。
记账节点101对交易信息进行上链。上链完成后，通知开票单位终端上链完成。开票单位终端上显示如图3K所示的界面。
图4A-4K示出了根据本申请一个实施例的为区块链网络中的节点发放数字证书的方法应用在电子***应用场景下的节点显示界面图，这些界面图表示了在图1B所示的体系构架下业务节点子网络104中的业务节点102向记账节点子网络100中的记账节点101查询上链的数据区块的区块体的大体过程。
图4A-4F是业务节点102在查询区块体中的交易信息前完成公私钥和相应数字证书的获取的过程，其与图3A-3F类似，故不赘述。
交易信息上链后，业务节点102仅接收到由记账节点101发送过来的区块头。当业务节点102需要查询区块体中的交易信息时，显示如图4G所示的界面。当管理员点击“确定”后，指示向代理节点105发送查询请求。
为了证明查询请求是由一个合格的业务节点102发出的，需要同时发送业务节点102的签名。如图4H所示，显示界面提示查询请求需要签名，并询问是否获取签名用的私钥。
当管理员点击图4H界面中的“是”时，从数字证书颁发中心103获取业务节点102的私钥。如图4I所示，当管理员点击“签名并发送”时，用业务节点102的私钥对查询请求签名，并连同查询请求一起发送给代理节点105。
代理节点105接收到查询请求和签名后，用业务节点102的公钥验证签名，如果验证成功，并通知业务节点102。业务节点102显示如图4J所示的界面。
当签名验证成功后，代理节点105向相应记账节点101发送区块头交易信息的查询请求，根据业务节点102的权限，决定是否为其返回查询的交易信息。图4K示出了在业务节点102查看返回的交易信息的界面。
如图5所示，根据本申请的一个实施例中，提供了一种为区块链网络中的节点发放数字证书的方法。
区块链网络是指如图1A-1C所示的向区块链上记录数据区块所涉及的整个体系构架。数字证书是指为了保证向节点分配的公私钥是由合法机构分配的而设置的证明文件。区块链网络中的节点是指区块链网络中除数字证书颁发中心103以外的所有节点。在图1A中，它包括交易信息产生方节点102和记账节点101。在图1B-1C中，它包括业务节点102、代理节点105、记账节点101。
所述方法由数字证书颁发中心103执行。数字证书颁发中心是基于加密算法，为区块链节点通信提供安全服务的中心化基础设施，能够为节点颁发数字证书以对公私钥的合法性进行确认。如图6所示，所述数字证书颁发中心103至少包括公私钥生成模块TPKI_sdk和认证模块TPKI_ca。公私钥生成模块TPKI_sdk是为节点生成公私钥的模块。认证模块TPKI_ca是对节点进行认证，从而验证该节点的合法性，进而在合法节点和为节点生成的公私钥之间形成经认证的配对的模块。
在一些情况下，数字证书颁发中心103还可以包括认证策略模块TPKI_aus，认证策略模块TPKI_aus是存储对节点的注册信息进行认证时采用的策略的模块。
公私钥生成模块TPKI_sdk、认证模块TPKI_ca和认证策略模块TPKI_aus可以是物理上的，例如分布在不同的实体机中，也可以是虚拟的，例如是分布在一台实体机中的不同虚拟模块。
如图5所示，所述方法包括：
步骤510，响应于来自区块链网络中的节点的公私钥请求，通过公私钥生成模块TPKI_sdk，为所述节点生成所述节点的公钥和私钥并发送到所述节点；
步骤530，通过认证模块TPKI_ca，接收所述节点的公钥和注册信息；
步骤550，通过认证模块TPKI_ca对所述注册信息进行认证；
步骤560，如果认证成功，通过认证模块TPKI_ca，生成所述节点的数字证书并发送给所述节点，所述数字证书包含明文信息和利用认证模块TPKI_ca的私钥对所述明文信息 形成的签名，以便所述节点利用认证模块TPKI_ca的公钥对所述签名进行验证，所述明文信息包括所述节点的公钥。
其中，公钥(Public Key)与私钥(Private Key)是通过一种算法得到的一个密钥对(即一个公钥和一个私钥)，公钥是密钥对中公开的部分，私钥则是非公开的部分。用公钥加密的数据只有对应的私钥可以解密，用私钥加密的数据只有对应的公钥可以解密。
节点的公钥是数字证书颁发中心103的公私钥生成模块TPKI_sdk生成的，用于对节点之间传送的数据进行加密或解密，同时在数字证书颁发中心103为节点颁发数字证书时建立数字证书与节点的公钥的关联性，使得数字证书可以证明为节点生成的公私钥时合法的。节点中可以存储认证模块TPKI_ca的公钥，以便在节点获取到数字证书颁发中心103的数字证书时，通过认证模块TPKI_ca的公钥对认证模块TPKI_ca利用自身私钥对数字证书和节点的公钥形成的签名进行验证，提供数字证书的公信力。
可以理解的是，若数字证书颁发中心103还可以包括认证策略模块TPKI_aus，则在步骤550之前，还可以包括步骤540(图5中虚线表示该步骤是可选的)，即通过认证模块TPKI_ca，从认证策略模块TPKI_aus获取与所述节点对应的注册信息认证策略，使得在进行注册信息认证时，即在步骤550中可以通过所述认证模块(TPKI_ca)，基于与所述节点对应的注册信息认证策略对所述注册信息进行认证，使得认证具有统一的标准(参见图5所示)。
下面结合图6示出的数字证书颁发中心中的各模块之间以及和所述节点之间的交互示意图对图5示出的技术方案进行解释。在6-1中，公私钥生成模块TPKI_sdk为节点Bers生成公私钥对并发送给该节点；在6-4中，节点Bers向认证模块TPKI_ca发送注册信息和公钥；在6-5中，认证模块TPKI_ca向认证策略模块TPKI_aus发送注册信息认证策略获取请求；然后认证策略模块TPKI_aus获取与所述节点对应的注册信息认证策略，并在步骤6-6中向认证模块TPKI_ca返回认证策略；如果认证成功，认证模块TPKI_ca会在步骤6-7中向节点Bers发送数字证书；而如果认证失败，认证模块TPKI_ca会在步骤6-7中向节点Bers发送认证失败的提醒信息。
下面对步骤510-560进行进行详细阐述。
步骤510，响应于来自区块链网络中的节点的公私钥请求，通过公私钥生成模块TPKI_sdk，为所述节点生成所述节点的公钥和私钥并发送到所述节点。
公私钥请求是区块链网络中的节点用于向数字证书颁发中心获取数字证书的请求。公私钥请求可以是基于各种网络协议的网络请求，比如超文本传输协议(HyperText Transfer Protocol，HTTP)/HTTPS协议下的请求，例如使用get、post等方法生成的请求。
在一个实施例中，在公私钥对的生成方式，可以通过现有的OpenSSL这个安全套接字层密码库的命令行工具来生成。
由于非对称加密算法不同，产生公私钥对的方法不同。因此，在一个实施例中，在公私钥生成模块TPKI_sdk设置非对称加密算法库，公私钥生成模块TPKI_sdk从该非对称加密算法库随机选取一种非对称加密算法，为所述节点生成所述节点的公钥和私钥。
在一个实施例中，区块链网络中的节点向数字证书颁发中心发送的公私钥请求中包含非对称加密算法的名称，公私钥生成模块TPKI_sdk按照该名称的非对称加密算法，为所述节点生成所述节点的公钥和私钥。该实施例的好处是，增强了节点选择公私钥的灵活性，使得节点可以根据偏好选择其偏爱加密算法的公私钥。
在一个实施例中，区块链网络中的节点向数字证书颁发中心发送的公私钥请求中包含该节点的类型，公私钥生成模块TPKI_sdk中预先设置有节点的类型与非对称加密算法名称的对应关系表，公私钥生成模块TPKI_sdk按照公私钥请求中的节点的类型，查找对应关系表，得到对应的非对称加密算法名称，按照该名称的非对称加密算法，为所述节点生成所述节点的公钥和私钥。该实施例的好处是，一种类型的节点，适合于它的非对称加密算法往往是固定的。根据节点的类型，选取其适合的非对称加密算法来生成公私钥，提高了生成的公私钥的质量。
在一个实施例中，在公私钥生成模块TPKI_sdk设置非对称加密算法库，非对称加密算法库中的非对称加密算法具有预定顺序，公私钥生成模块TPKI_sdk从该非对称加密算法库按照预定顺序选取前一次选取的非对称加密算法的下一个非对称加密算法，为所述节点生成所述节点的公钥和私钥；如果前一次选取的非对称加密算法是预定顺序中最后一个非对称加密算法，则选取第一个非对称加密算法，为所述节点生成所述节点的公钥和私钥。该实施例的优点是，由于每次选取的非对称加密算法不同，增强了公私钥在传输过程中被第三方破解的难度，提高了发放的公私钥的传输安全性。
在一个实施例中，通过公私钥生成模块TPKI_sdk为所述节点生成所述节点的公钥和私钥并发送到所述节点之后，所述方法还包括：将所述节点的公私钥与节点标识对应地进行备份存储。这样做的好处是，如果节点没有保存好自己的私钥，同时也没有委托私钥管理模块TPKI_pks，可以通过公私钥生成模块TPKI_sdk找到发放给自己的私钥。
在步骤530中，通过认证模块TPKI_ca，接收所述节点的公钥和注册信息。
如前所述，所述节点的公钥已经由公私钥生成模块TPKI_sdk生成，并发送给了所述节点。
注册信息可以是节点向数字证书颁发中心103注册时需要填写的信息，例如单位名称、纳税人识别号等。向数字证书颁发中心103注册的意义是为了获取数字证书，从而证明为其分配的公私钥是合法机构为其颁发的公私钥。只有注册信息认证通过，才能为节点颁发数字证书。
在一个实施例中，所述节点的公钥和注册信息是用认证模块TPKI_ca的公钥加密的。这样做的好处是，只有认证模块TPKI_ca具有认证模块TPKI_ca的私钥，才能将其解密。 一旦传输过程中被第三方拦截，第三方不具有认证模块TPKI_ca的私钥，不能解密，从而保证了节点注册信息传输的安全性。
在步骤540中，通过认证模块(TPKI_ca)，从认证策略模块(TPKI_aus)获取与所述节点对应的注册信息认证策略。
注册信息认证策略是体现数字证书所能满足的安全要求所基于的策略，可以是一个或多个安全规则的策略。比如，验证那些注册信息、根据什么标准验证等等。例如，注册信息认证策略可能是：单位地址是深圳市，单位人数大于500人。即，该区块链网络可能是一个服务于深圳市大中型单位的一个区块链网络。如果是非深圳市的单位，或者深圳市的人数较少的小单位，考虑到网络维护成本问题，可能就不为其认证通过，不向其发放数字证书，不为其公私钥提供合法性证明。
值得一提的是，与所述节点对应的注册信息认证策略并不意味着该注册信息认证策略与所述节点唯一对应，即该注册信息认证策略可以用于所述节点，也可以用于所述节点之外的其他节点。注册信息认证策略可以是所有节点通用的唯一注册信息认证策略，也可以是每个节点不同的注册信息认证策略。
在一个实施例中，所述与所述节点对应的注册信息认证策略包括特定于所述节点类型的注册信息认证策略；所述注册信息中含有所述节点类型；所述步骤540包括：从认证策略模块(TPKI_aus)获取特定于所述节点类型的注册信息认证策略。
也就是说，根据注册信息中含有的节点类型(如金融型企业终端、法律服务业公司终端)，来确定特定于所述节点类型的注册信息认证策略。不同节点类型的注册信息认证策略可能不同。例如，金融型企业，其盈利程度可能比较大，要求注册资金是200万以上；法律服务业公司，其盈利程度可能比较小，要求注册资金是10万以上。
该实施例的好处是，某一类型的节点具有相似的特点，在考查是否可以为其发放数字证书时，往往会遵循类似的标准。通过这种方式，进一步提高了认证的准确性。
在一个实施例中，所述节点的注册信息中包含要申请的数字证书的规格，该规格可以表示数字证书的安全等级；认证策略模块TPKI_aus包含一个数字证书规格与注册信息认证策略的对应关系表，则与所述节点对应的注册信息认证策略是按照所述注册信息中的数字证书规格，从数字证书规格与认证策略的对应关系表中查找出的。
规格表示数字证书的安全等级，例如，规格3级代表安全等级最高，规格2级代表安全等级中等，规格1级代表安全等级最低。安全等级越高，认证的严格程度就要越高，对应的认证策略可能也越多，或越苛刻。该实施例的好处是，为不同安全等级的数字证书，设定不同的认证策略，不同安全等级的数字证明，对公私钥合法性的证明力不同。通过这种方式，能够增强数字证书发放的灵活性。
在一个实施例中，所述注册信息认证策略是区块链上存储的所述节点与区块链网络运营方签署的智能协议中获取的。所述节点使用区块链网络，要事先与区块链网络运营方签 署智能协议，该智能协议具有认证时的注册信息认证策略。该智能协议可以与所述节点的标识对应地存储在区块链上。这样，可以从所有上链的数据区块的区块体中查找所述节点的标识，并查找到与该节点的标识对应存储的智能协议，从所述智能协议中查找到注册信息认证策略。该实施例的好处是，不需要额外设置认证策略，可以直接利用智能协议中的认证策略，提高发放数字证书的效率。
在一个实施例中，认证策略模块TPKI_aus包含一个请求发放时间段与认证策略的对应关系表。步骤540包括：
确定接收到公钥和注册信息的时间所在的请求发放时间段；
将所述请求发放时间段发送给认证策略模块TPKI_aus，以便认证策略模块TPKI_aus查找请求发放时间段与认证策略的对应关系表，获得与该请求发放时间段对应的认证策略返回。
例如，每天上班时间9:00-17:00、和下班时间0:00-9:00或17:00-24:00的注册信息认证策略是不一样的。可以将接收到公钥和注册信息的时间确定为数字证书请求发放的时间，该请求发放的时间落在9:00-17:00，还是落在0:00-9:00或17:00-24:00，意味着认证策略不同。可以从请求发放时间段与认证策略的对应关系表找到与该请求发放时间段对应的认证策略，作为获取到的注册信息认证策略。
该实施例的好处是，充分考虑到在一些场景中认证策略随不同时间段的变化，使得该数字证书发放体系得到更广泛的应用。
若注册信息认证策略是从认证策略模块TPKI_aus获取的，在步骤550中，通过认证模块(TPKI_ca)，基于与所述节点对应的注册信息认证策略，对所述注册信息进行认证。
与所述节点对应的注册信息认证策略可能包括多个安全规则，如前面所述的单位地址是深圳市，单位人数大于500人等。认证要针对每项安全规则分别考虑认证信息是否符合该安全规则，如果都符合则认证成功，否则认证失败。
在步骤560中，如果认证成功，通过认证模块TPKI_ca，生成所述节点的数字证书并发送给所述节点，所述数字证书包含明文信息和利用认证模块TPKI_ca的私钥对所述明文信息形成的签名，以便所述节点利用认证模块TPKI_ca的公钥对所述签名进行验证，所述明文信息包括所述节点的公钥。
在一个实施例中，生成所述节点的数字证书包括：
生成明文信息，所述明文信息包括所述节点的公钥；
根据预定摘要算法对所述明文信息生成摘要；
用认证模块TPKI_ca的私钥对所述摘要加密，得到签名；
基于签名和明文信息，生成所述数字证书。
预定摘要算法例如可以是哈希算法。与一般生成签名的过程类似，该实施例也是先对明文信息生成摘要，再对摘要加密，得到签名。然后，将签名和明文信息一起放到数字证书中。由于明文信息具有所述节点的公钥，因此建立了数字证书与发放的公私钥的关联性，使得数字证书能够证明某个特定的公私钥是合法发放的。签名的作用是便于所述节点验证该数字证书是由合法的机构，即认证模块TPKI_ca发放的，提高数字证书的公信力。
对应地，在一个实施例中，用认证模块TPKI_ca的公钥对所述签名进行验证，包括：
将数字证书中的签名用认证模块TPKI_ca的公钥解密；
将数字证书中的明文信息用所述预定摘要算法生成摘要；
将解密结果与所述生成的摘要比较，如一致，则验证成功，如不一致，则验证失败。
在一个实施例中，在区块链网络的每个节点存储所述认证模块TPKI_ca的公钥。所述认证模块TPKI_ca的公钥可以从所述节点存储的公钥中获取。该实施例的优点是，简便易行，减少了获取所述认证模块TPKI_ca的公钥的时间。
在一个实施例中，所述认证模块TPKI_ca的公钥可以从区块链上记录该认证模块TPKI_ca的公钥的数据区块获取。也就是说，将认证模块TPKI_ca的公钥上链保存，例如与认证模块TPKI_ca的标识对应保存在一个数据区块的一个交易信息中。在查询时，在区块链上所有数据区块的交易信息中查找认证模块TPKI_ca的标识，并查找到该交易信息中与该标识对应的公钥。该实施例的优点是，减少了每个节点中存储空间的占用。
如果该数字证书是由合法的认证模块TPKI_ca发放的，解密结果与所述生成的摘要应当一致，则验证成功。如果验证不成功，很可能数字证书不是合法的认证模块TPKI_ca发放的。这样，提高了数字证书本身的安全性。
在一个实施例中，节点除了进行上述签名验证之外，还进行签发机构合法性验证。
如图17A和17B所示，所述明文信息还包含签发机构标识信息，以便所述节点根据合法签发机构标识信息列表对该数字证书进行验证。
在每个节点处，可以存储合法签发机构标识信息列表，该合法签发机构标识信息列表列出了所有合法的签发机构的标识列表。只要标识信息在该合法签发机构标识信息列表中，该签发机构就是合法的。通过将明文信息中的签发机构标识信息与合法签发机构标识信息列表中的每个合法签发机构标识信息逐一对比，可以判断该数字证书是否是一个合法的机构所颁发。该签发机构合法性验证的好处是，进一步提高了数字证书的公信力。
图17A和图17B分别是所述节点为企业或者服务商时，数字证书颁发中心为所述节点颁发的数字证书内容的示例。如图17A-B所示，无论是企业还是服务商的数字证书，都包括明文信息和对明文信息的签名。
如图17A所示，企业的明文信息除了企业公钥、签发机构标识外，还可能包括版本号、序列号、签名算法、认证模块CA公钥、企业标识、有效时间、证书状态信息和扩展信息。本领域技术人员应当理解，在实际中，企业的明文信息可能只包括版本号、序列号、签名算法、认证模块CA公钥、企业标识、有效时间、证书状态信息和扩展信息中的一项或多项，也可能一项也不包括。
版本号是区块链的版本标识。当区块链的版本升级时，数字证书颁发中心颁发的数字证书中的版本标识变化。
序列号是颁发的数字证书的序号。每个数字证书按发放的顺序，具有唯一的序列号。该序列号可以按发放的顺序从小到大递增生成。
签名算法是认证模块CA生成签名时对明文信息生成摘要用的摘要算法。将它发送回所述节点，是为了所述节点验证签名时可以用该摘要算法重新对明文信息生成摘要，从而与对签名解密的结果进行对比。
认证模块CA公钥发送回所述节点的意义在于，所述节点对签名解密时需要用认证模块CA的公钥解密。
企业标识是指唯一区分企业的标记，可以用纳税人识别号等作为企业标识，也可以为企业分配专门的标识。
有效时间是指该数字证书有效的截止时间。在后文中查询私钥时会提到，要根据该有效时间进行有效时间验证，以便决定是否给所述节点返回查询的私钥。
证书状态信息是指表示数字证书的状态的信息，例如证书是否被吊销，如果未被吊销，该证书状态信息为正常。
扩展信息是指根据实际需要其它需要被加入数字证书的信息。
图17B与图17A的区别在于，它用服务商标识代替了企业标识，用服务商公钥代替了企业公钥。服务商标识是指唯一区分服务商的标记。服务商公钥是指分配给服务商的公钥。
数字证书可以是结构化的数据文件，该结构化的数据文件可以是节点能够识别的各种格式，比如可以是.cer或者.crt格式。
在一个实施例中，所述数字证书颁发中心还包括私钥管理模块TPKI_pks。私钥管理模块是对数字证书颁发中心为节点颁发的私钥进行托管的模块。如图7所示，所述方法在步骤510的后面还包括：
步骤520，通过私钥管理模块TPKI_pks，接收由所述节点发送的私钥并保存。
该实施例的好处是，所述节点自己保存私钥，如果机器发生故障导致存储器被破坏，可能丢失私钥，而且私钥存储在所述节点的存储器中，容易被第三方盗取，而托管则不存在这些问题。
参考图8所示，私钥管理模块TPKI_pks可以通过6-2和6-3实现与节点Bers的双向交互。在6-2中，所述节点将私钥发生给私钥管理模块TPKI_pks。在6-3中，所述私钥管理模块TPKI_pks向所述节点确认已经托管了私钥。
在一个实施例中，如图9所示，步骤520中，所述接收由所述节点发送的私钥，包括：
步骤523，接收所述节点利用私钥管理模块TPKI_pks的公钥加密的第一随机会话密钥；
步骤524，利用私钥管理模块TPKI_pks的私钥解密加密的第一随机会话密钥，得到所述第一随机会话密钥；
步骤525，接收所述节点利用所述第一随机会话密钥加密的所述节点的私钥；
步骤526，利用解密得到的第一随机会话密钥，解密加密的所述节点的私钥，得到所述节点的私钥。
下面对图9所示出的上述几个步骤给出具体解释。
在步骤523中，接收所述节点利用私钥管理模块TPKI_pks的公钥加密的第一随机会话密钥。
第一随机会话密钥是所述节点在要托管私钥时随机生成的一个会话密钥。
在一个实施例中，区块链网络中的所有节点都存储有TPKI_pks的公钥。在这种情况下，节点可以从存储的公钥中获取私钥管理模块TPKI_pks的公钥。该实施例的优点是简便易行，节省获取TPKI_pks的公钥的时间。
在一个实施例中，私钥管理模块TPKI_pks的公钥存储在区块链上，节点可以从区块链上记录该私钥管理模块TPKI_pks的公钥的数据区块获取私钥管理模块TPKI_pks的公钥。也就是说，私钥管理模块TPKI_pks的公钥上链保存，其可以与私钥管理模块TPKI_pks的标识对应保存在一个数据区块中。在从区块链上获取私钥管理模块TPKI_pks的公钥时，可以查找出所有带有该私钥管理模块TPKI_pks的标识的数据区块，并查找出与该标识对应存储在一个交易信息中的公钥。该实施例的优点是，节省了各个节点的存储空间。
在步骤524中，利用私钥管理模块TPKI_pks的私钥解密加密的第一随机会话密钥，得到所述第一随机会话密钥。
由于只有私钥管理模块TPKI_pks具有私钥管理模块TPKI_pks的私钥，只有私钥管理模块TPKI_pks才能解密加密的第一随机会话密钥。因此，即使第三方拦截了加密的第一随机会话密钥，其也无法破解第一随机会话密钥，保证了第一随机会话密钥传输的安全性。
在步骤525中，接收所述节点利用所述第一随机会话密钥加密的所述节点的私钥。
如前所述，即使第三方拦截了加密的第一随机会话密钥，其也无法破解第一随机会话密钥，只有所述节点和私钥管理模块TPKI_pks具有第一随机会话密钥。因此，用第一随机 会话密钥加密所述节点的私钥后传输给私钥管理模块TPKI_pks，即使中途第三方截获了加密的所述节点的私钥，也无法破解，提高了所述节点的私钥传输的安全性。
在步骤526中，利用解密得到的第一随机会话密钥，解密加密的所述节点的私钥，得到所述节点的私钥。
该实施例的好处是，上述节点的私钥的传递过程运用两次协商过程。通过第一次协商过程传递第一随机会话密钥，传输过程中利用私钥管理模块TPKI_pks的公钥加密，私钥管理模块TPKI_pks接收后利用私钥管理模块TPKI_pks的私钥解密。通过第二次协商过程传递所述节点的私钥，传输过程中用第一随机会话密钥加密，私钥管理模块TPKI_pks接收后利用第一随机会话密钥解密。第三方截获了其中一次协商过程中传递的内容，根本无法破解所述节点的私钥。即使第三方截获了两次协商过程中传递的内容，由于私钥管理模块TPKI_pks的私钥只有私钥管理模块TPKI_pks自己才有，也无法破解所述节点的私钥。这就为提高私钥管理模块TPKI_pks的私钥传递的安全性提供了双重保障。
在一个实施例中，私钥管理模块TPKI_pks可以是分散在多个地点的多个私钥管理模块TPKI_pks。当任一个私钥管理模块TPKI_pks接收到节点发送的私钥后，可以向其它地点的私钥管理模块TPKI_pks进行同步。
该实施例的优点是，防止私钥管理模块TPKI_pks仅设置在一处，从而避免一旦该私钥管理模块TPKI_pks遭受到攻击被破坏，造成其为所有节点托管的私钥都丢失。该实施例通过设置多个地点的多个私钥管理模块TPKI_pks，当任一个私钥管理模块TPKI_pks接收到节点发送的私钥后，都向其它地点的私钥管理模块TPKI_pks进行同步，即使一个地点的私钥管理模块TPKI_pks遭到了破坏，在其它地点的私钥管理模块TPKI_pks仍然能找到该托管的私钥，增加了私钥托管的安全性。
在一个实施例中，私钥管理模块TPKI_pks对私钥进行了托管存储时，可以用对称式加密算法进行加密，比如可以使用数据加密标准(Data Encryption Standard，DES)、高级加密标准(Advanced Encryption Standard，AES)、3DES等加密算法。加密所述私钥的密钥可以被硬编码在私钥管理模块之中。这样，即使该加密的私钥被第三方窃取，由于加密所述私钥的密钥被硬编码在私钥管理模块TPKI_pks之中，第三方仍然无法解密该加密的私钥，进一步提高了托管的私钥的安全性。
在一个实施例中，在步骤523之前，步骤520还包括对私钥管理模块TPKI_pks的合法性进行验证的过程，如图10所示，步骤520还包括以下步骤：
步骤521，通过认证模块TPKI_ca，接收来自所述节点的私钥管理模块TPKI_pk的数字证书获取请求。
私钥管理模块TPKI_pks数字证书是私钥管理模块TPKI_pks拥有合法托管资质的证明文件。在一个实施例中，该数字证书可以是认证模块TPKI_ca为其颁发的。
步骤522，通过认证模块TPKI_ca，根据数字证书获取请求向所述节点发送所述私钥管理模块TPKI_pks的数字证书，所述数字证书包括利用认证模块(TPKI_ca)的私钥进行的签名，以便所述节点接收到所述数字证书后，利用认证模块(TPKI_ca)的公钥进行验证。
该私钥管理模块TPKI_pks数字证书包含有明文信息和用认证模块TPKI_ca的私钥对该明文信息生成的签名。明文信息中包含私钥管理模块TPKI_pks的基本信息，如名称、注册号、注册时间、被授予的权利、授权时间等等。签名的生成方法同前，故不赘述。所述节点接收到所述数字证书后，用认证模块(TPKI_ca)的公钥进行验证的方法也同前，故不赘述。
该实施例的优点是，可以在托管所述节点的私钥前验证私钥管理模块TPKI_pks的合法性，提高私钥托管安全性。
如图11所示，当节点Bers想要托管其私钥时，首先向认证模块TPKI_ca发送获取私钥管理模块TPKI_pks的数字证书获取请求。然后，认证模块TPKI_ca会向Bers节点返回私钥管理模块TPKI_pks的数字证书。接下来，节点Bers会验证认证模块TPKI_ca返回的数字证书。然后，若数字证书验证成功，Bers节点会生成第一随机会话密钥。接下来，Bers节点会使用私钥管理模块TPKI_pks的公钥加密生成的第一随机会话密钥。接着，Bers节点向私钥管理模块TPKI_pks发送加密的第一随机会话密钥。私钥管理模块TPKI_pks可以使用其私钥解密得到第一随机会话密钥。接着，私钥管理模块TPKI_pks可以向节点Bers返回代表已成功获得会话密钥的提醒信息。然后，节点Bers就可以使用第一随机会话密钥加密包括节点Bers的私钥在内的各种敏感信息。接下来，节点Bers向私钥管理模块TPKI_pks发送加密后私钥等敏感信息。私钥管理模块TPKI_pks使用得到的第一随机会话密钥对加密后的私钥进行解密，得到节点Bers的私钥，向节点Bers返回私钥托管成功的提醒信息。这样，就完成了节点Bers向私钥管理模块TPKI_pks托管私钥的整个方案。
节点将私钥托管在私钥管理模块TPKI_pks，当节点需要该私钥时，节点可以从私钥管理模块TPKI_pks获取其私钥。下面将对节点从私钥管理模块TPKI_pks获取其私钥的过程进行介绍。
在一个实施例中，在步骤560之后，所述方法还包括步骤580-步骤5100。如图12所示，所述方法还包括以下步骤：
步骤580，通过所述私钥管理模块TPKI_pks，接收所述节点的私钥查询请求。
私钥查询请求是所述节点发来的用于从私钥管理模块TPKI_pks中获取托管的私钥的请求，其可以是基于各种网络协议创建的请求，例如可以是HTTP/HTTPS等类型的请求。
步骤590，通过所述私钥管理模块TPKI_pks，向认证模块TPKI_ca发送所述节点的数字证书查询请求。
步骤5100，如果接收到认证模块(TPKI_ca)根据数字证书查询请求生成的数字证书认证成功的应答，通过所述私钥管理模块TPKI_pks，根据私钥查询请求向所述节点发送所述节点的私钥。
如果私钥管理模块TPKI_pks只根据接到私钥查询请求，就向该请求的发送方返回托管的私钥，则黑客等不法分子很容易使用假冒的请求来窃取私钥管理模块TPKI_pks上托管的私钥，造成严重损失。所以只有针对已经进行过数字证书颁发的节点，才能为其返回私钥。因为数字证书证明了公私钥的合法性，同时由于该数字证书是所述节点请求的，证明了所述节点对该公私钥具有支配权。因此，在返回私钥之前，要向认证模块TPKI_ca发送所述节点的数字证书查询请求，只有认证模块TPKI_ca查询到该节点具有数字证书时，才能为其返回私钥。
在一个实施例中，所述私钥查询请求和数字证书查询请求都具有所述节点的公钥。如图17A-17B所示，所述数字证书中具有所述节点的公钥。认证模块TPKI_ca根据所述公钥查询到所述节点的数字证书。
在一个实施例中，所述私钥查询请求和数字证书查询请求都具有所述节点的标识。如图17A-17B所示，所述数字证书中具有所述节点的标识，如图17A的企业标识和图17B的服务商标识。认证模块TPKI_ca根据所述节点的标识查询到所述节点的数字证书。
在一个实施例中，所述私钥查询请求和数字证书查询请求都具有所述数字证书的序列号。如图17A-17B所示，所述数字证书中具有所述数字证书的序列号。认证模块TPKI_ca根据所述序列号查询到所述节点的数字证书。
在一个实施例中，如图13所示，私钥管理模块TPKI_pks根据私钥查询请求向所述节点发送所述节点的私钥的过程可以包括以下步骤：
步骤5110，接收所述节点利用私钥管理模块TPKI_pks的公钥加密的第二随机会话密钥。
所述私钥管理模块TPKI_pks的公钥同前，故不赘述。
第二随机会话密钥与第一随机会话密钥相比，可以是所述节点采用相同的生成方式生成的，也可以是采用不同的生成方式生成的。
步骤5120，利用私钥管理模块TPKI_pks的私钥解密加密的第二随机会话密钥，得到所述第二随机会话密钥。
与前面解密加密的第一随机会话密钥的过程类似，故不赘述。
步骤5130，根据私钥查询请求查询所述节点的私钥。
在一个实施例中，步骤525包括：接收所述节点利用所述第一随机会话密钥加密的所述节点的私钥和公钥。步骤526包括：利用解密得到的第一随机会话密钥，解密加密的所 述节点的私钥和公钥，将得到的私钥和公钥对应存储。步骤5130包括：根据私钥查询请求中的所述节点的公钥，查询存储的对所述公钥对应的私钥。
在一个实施例中，步骤525包括：接收所述节点利用所述第一随机会话密钥加密的所述节点的私钥和所述节点的标识。步骤526包括：利用解密得到的第一随机会话密钥，解密加密的所述节点的私钥和所述节点的标识，将得到的私钥和所述节点的标识对应存储。步骤5130包括：根据私钥查询请求中的所述节点的标识，查询存储的对所述标识对应的私钥。
步骤5140，利用所述第二随机会话密钥加密所述节点的私钥并发送到所述节点，以便所述节点利用所述第二随机会话密钥解密加密的所述节点的私钥，得到所述节点的私钥。
在一个实施例中，第二随机会话密钥是基于对称式加密算法生成的。利用所述第二随机会话密钥加密所述节点的私钥、和利用所述第二随机会话密钥解密加密的所述节点的私钥的过程与前述用所述第一随机会话密钥加密所述节点的私钥、和用所述第一随机会话密钥解密加密的所述节点的私钥的过程类似，故不赘述。与托管私钥时的两次协商一样，查询私钥时的两次协商，也达到了提高私钥传输过程中的安全性的效果。
在一个实施例中，参考图1C所示，所述区块链包括多个子区块链。对于在不同子区块链上上链和查询数据区块，可能需要不同的公私钥对，以进一步提高区块链上公私钥使用的安全性。即使第三方获知了在一个子区块链上上链和查询用的公私钥，也很难知悉其它子区块链上上链和查询用的公私钥。
在该实施例中，所述公私钥请求中具有待注册子区块链的标识。所述为所述节点生成所述节点的公钥和私钥包括：为所述节点生成所述节点待注册子区块链上的公钥和私钥。具体地说，根据公私钥请求中的待注册子区块链的标识，为节点生成这些子区块链上的公钥和私钥。虽然有多个子区块链，但所述节点可能不会用到其中一些子区块链，因而只需要请求到其可能以后会用到的子区块链上的公私钥即可。
节点请求到哪些子区块链上的公私钥，就只需要针对这些子区块链通过认证。因此，在该实施例中，所述注册信息包括待注册子区块链，这些子区块链与请求发放公私钥的子区块链是一致的。步骤540包括：从认证策略模块TPKI_aus获取与待注册子区块链对应的注册信息认证策略。也就是说，每个子区块链有不同的认证策略，可以针对每个所述节点要注册的子区块链(待注册子区块链)，用相应的认证策略去认证。
步骤550包括：基于待注册子区块链对应的注册信息认证策略，对所述注册信息进行在待注册子区块链上的认证。所述明文信息包括认证成功的子区块链上的公钥。
由于所述节点在每个待注册子区块链上分别认证，有可能出现一些待注册子区块链认证成功，另一些待注册子区块链认证失败的情况。这时，仅对认证成功的那些子区块链发放证书，即在证书的明文信息中仅包括认证成功的子区块链上的公钥。这样，仅从数字证书的明文信息中包括的公钥，就能够确定所述节点在那些子区块链上认证成功，具有权限。
例如，所述节点对应的待注册子区块链为子区块链2、3，其中，子区块链2的认证策略是地址在深圳市，子区块链3的认证策略是单位人数超过500，该企业是一个人数两千多人的北京的工厂，因此，子区块链3的认证成功，子区块链2的认证失败。仅将子区块链3的公钥写入数字证书的明文信息中。
该实施例的优点是可以在多子区块链的情形下针对不同子区块链进行不同认证，获得不同子区块链的认证结果，使得数字证书对公私钥合法性的证明精确到子区块链，提高了数字证书使用的灵活性。
在一个实施例中，所述私钥查询请求包括要查询的私钥所属的子区块链，所述节点的数字证书查询请求包括要查询的私钥所属的子区块链，使得所述认证模块TPKI_ca根据要查询的私钥所属的子区块链是否是所述数字证书的明文信息中含有的认证成功的公钥对应的子区块链，确定是否发送数字证书认证成功的应答。
也就是说，在前述实施例中，在步骤5100中，认证模块TPKI_ca可能仅根据数字证书查询请求中的所述节点的标识，查询是否为所述节点发放过数字证书，如果是，则可以向私钥管理模块TPKI_pks发送数字证书认证成功的应答。但在本实施例中，由于有不同子区块链，还需要具体验证在所述节点想要获取私钥的子区块链上，所述节点是否具有权限。这时，就需要在其数字证书的明文信息中查找明文信息中包含的公钥，这些公钥对应的子区块链就是所述节点有权限的子区块链，可以为其发生数字证书认证成功的应答，在应答中包含着认证成功的子区块链。私钥管理模块TPKI_pks仅根据认证成功的子区块链为所述节点返回查询的私钥。例如，所述节点可能请求子区块链2和3上的私钥，但认证模块TPKI_ca查询其数字证书，发现数字证书中仅含有子区块链3上的公钥。因此，仅向所述节点返回子区块链3上的私钥。
该实施例的优点是，在多子区块链的情况下，提高查询托管的私钥的灵活性。所述节点只能查询到那些通过认证的、在数字证书中具有对应的公钥的那些私钥。
在一个实施例中，认证模块TPKI_ca向私钥管理模块TPKI_pks发送数字证书认证成功的应答，除了进行上述验证之外，还需要验证数字证书是否过期，如过期，需要重新注册数字证书。如图17A-17B所示，所述明文信息还包含有效时间。通过所述私钥管理模块TPKI_pks，向认证模块TPKI_ca发送所述节点的数字证书查询请求后，认证模块TPKI_ca找到所述节点对应的数字证书，根据数字证书中的有效时间与当前时间的比较，对该数字证书进行有效时间验证。在有效时间验证成功的情况下，才向所述私钥管理模块TPKI_pks发送数字证书认证成功的应答。
具体地说，有效时间可以是该数字证书有效的截止时间。如果该有效时间早于当前数据，则验证失败。如果该有效时间晚于当前时间，则验证成功。该实施例的好处是，对数字证书的时效性进行验证，进一步提高了数字证书的公信力。
由于数字证书即使不过期，也可能由于单位违法等原因吊销数字证书。在一个实施例中，认证模块TPKI_ca向私钥管理模块TPKI_pks发送数字证书认证成功的应答，除了进行上述验证之外，还需要验证数字证书的状态，即是否被吊销，如吊销，则不能为其发放私钥。如图17A-17B所示，所述明文信息还包含证书状态信息。所述私钥管理模块TPKI_pks，向认证模块TPKI_ca发送所述节点的数字证书查询请求后，认证模块TPKI_ca根据所述证书状态信息，对该数字证书进行状态验证，在状态验证成功的情况下，才向所述私钥管理模块TPKI_pks发送数字证书认证成功的应答。
具体地说，如果证书状态信息表明该数字证书正常，则状态验证成功；如果表明该数字证书被吊销，则状态验证失败。该实施例的好处是，对数字证书的状态进行验证，进一步提高了数字证书的公信力。
在一个实施例中，所述节点包括单位节点和服务商节点。服务商是指在某些单位既不具有自己将交易信息上链或查询的条件(即不是图1A-1C中的记账节点101)，也不具有委托记账节点101将交易信息上链或查询的条件(即不是图1A中的交易信息产生方节点102，也不是图1B-1C中的业务节点105)，接收这些单位的委托，为这些单位进行交易信息委托记账节点101上链或查询的实体。当然，也存在一些自己具有将交易信息上链或查询的条件，或具有委托记账节点101将交易信息上链或查询的条件，但仍然委托某一服务商来上链或查询的情形。
服务商代替一些单位进行委托交易信息上链和查询，其查询的私钥可能不仅仅是自己的私钥，页有可能是其受托单位节点的私钥。因此，在为其颁发数字证书时就将服务商节点拥有的权限信息记录并保存。当服务商节点代替单位节点查询私钥时，所述私钥查询请求包括所述服务商节点的标识、和所述服务商节点要查询的密钥所属节点的标识，所述认证模块TPKI_ca根据存储的所述权限信息，确定所述服务商节点要查询的密钥所属节点的标识是否是所述服务商节点所服务的单位或服务商节点的标识。如果是，则认证成功。反之，则认证失败。
具体地，当所述节点是服务商节点时，所述接收所述节点的公钥和注册信息包括：接收所述节点的公钥、注册信息、以及服务商节点所服务单位的权限信息。例如，服务商节点A代替单位节点A1、A2、A3进行委托交易信息上链或查询，则权限信息包括A1、A2、A3。
该实施例中，若数字证书颁发中心还包括认证策略模块(TPKI_aus)，在通过认证模块TPKI_ca，对所述注册信息进行认证后，所述方法还包括：
如果认证成功，通过认证模块TPKI_ca，向认证策略模块TPKI_aus发送所述权限信息存储。具体地说，可以将所述节点的标识与所述权限信息对应存储。
在该实施例中，所述私钥查询请求包括所述服务商节点的标识、和所述服务商节点要查询的密钥所属节点的标识，所述认证模块TPKI_ca根据认证策略模块TPKI_aus存储的所 述权限信息，若所述服务商节点要查询的密钥所属节点的标识是所述服务商节点所服务的单位或服务商节点的标识时，认证成功。例如，认证策略模块TPKI_aus存储的服务商节点A的权限信息包括单位节点A1、A2、A3，如果服务商节点要查询的密钥是A1、A2、A3、A中的一个或多个节点的私钥时，认证成功，可以为其返回私钥。
该实施例的好处在于，为服务商节点代替多个单位节点进行委托上链或查询的场景提供了私钥管理技术实现方面的支撑。
由于子区块链经常是特定于某种交易信息的数据区块的，例如一个子区块链记录供应链金融的交易信息的数据区块，另一个区块链记录电子***的交易信息的数据区块，等等。一种类型的节点的交易类型也比较固定，因此需要记录的子区块链也比较固定。因此，在一个实施例中，可以根据节点的交易类型，自动为其设置子区块链的权限。例如，对于汽车制造企业，其经常需要供应链金融业务，但也实行了电子***，因此，需要供应链金融的子区块链和电子***的子区块链。
在该实施例中，所述区块链包括多个子区块链，所述注册信息包括节点类型。所述为所述节点生成所述节点的公钥和私钥，包括：为所述节点生成所述节点在不同子区块链上的公钥和私钥。假设共有N条子区块链，可以为所述节点生成N个子区块链对应的N个公私钥对。
若数字证书颁发中心还包括认证策略模块(TPKI_aus)，在步骤550中，通过认证模块TPKI_ca对所述注册信息进行认证之后，所述方法还包括：
如果认证成功，通过认证模块TPKI_ca，基于所述节点类型生成特定于所述节点类型的子区块链权限信息，并将子区块链权限信息存储在认证策略模块TPKI_aus，该子区块链权限信息包括针对不同业务类型允许查询的子区块链。
该特定于所述节点类型的子区块链权限信息可以是按照节点类型查找一个预先设置的节点类型与子区块链权限信息对应关系表得到的。例如，该对应关系表中，汽车制造企业对应的子区块链权限信息是：针对供应链金融业务类型，允许查询的子区块链是子区块链2；针对电子***业务类型，允许查询的子区块链是子区块链3。然后，将该子区块链权限信息存储在认证策略模块TPKI_aus。
该实施例中，所述私钥查询请求具有所述节点类型和业务类型，所述数字证书查询请求也具有所述节点类型和业务类型。所述认证模块TPKI_ca从认证策略模块TPKI_aus查询特定于所述节点类型的子区块链权限信息，根据该子区块链权限信息以及该业务类型，确定允许查询的子区块链，将允许查询的子区块链放入数字证书认证成功的应答中，发送给所述私钥管理模块TPKI_pks。所述向所述节点发送所述节点的私钥，包括：向所述节点发送所述节点的在允许查询的子区块链上的私钥。
例如，所述节点类型是汽车制造企业节点，业务类型是电子***。认证模块TPKI_ca首先根据数字证书查询请求中的节点类型，即汽车制造企业节点，从认证策略模块TPKI_aus 查询到其对应的子区块链权限信息，即，针对供应链金融业务类型，允许查询的子区块链是子区块链2；针对电子***业务类型，允许查询的子区块链是子区块链3。然后，根据数字证书查询请求中的业务类型，即电子***，确定允许查询的子区块链是子区块链3。将子区块链3放入数字证书认证成功的应答中，发送给所述私钥管理模块TPKI_pks。这时，私钥管理模块TPKI_pks就只向节点返回子区块链3上所述节点的私钥，不向所述节点返回其它子区块链上的私钥。
这种方式的优点是，在多子区块链的情况下，可以准确地为用户找到适应于所述节点类型和业务类型的子区块链上的私钥，实现多子区块链情况下托管私钥的精细管理。
图14是对所述节点查询托管的私钥的一个详细交互流程图。节点Bers要查询私钥管理模块TPKI_pks为其托管的私钥，首先向为其托管私钥的私钥管理模块TPKI_pks发送私钥查询请求。私钥管理模块TPKI_pks向认证模块TPKI_ca发送一个数字证书查询请求。然后根据该请求，认证模块TPKI_ca验证该节点是否具有数字证书，以及该数字证书是否过期，是否被吊销等，如果这些验证都通过，则向私钥管理模块TPKI_pks发送数字证书认证成功的应答。私钥管理模块TPKI_pks然后会向节点Bers发送指示其发送会话密钥的请求。节点Bers生成第二随机会话密钥，并用私钥管理模块TPKI_pks的公钥加密该第二随机会话密钥。节点Bers向私钥管理模块TPKI_pks发送加密的第二随机会话密钥。私钥管理模块TPKI_pks在接收到加密的第二随机会话密钥后，首先用其所拥有的私钥管理模块TPKI_pks的私钥解密加密的第二随机会话密钥，得到第二随机会话密钥。然后，其会用第二随机会话密钥加密所述节点所托管的私钥并向节点Bers发送。节点Bers在接收到加密信息后，由于该节点拥有第二随机会话密钥，所以可以用该第二随机会话密钥解密通过该第二随机会话密钥加密的私钥，得到其向私钥管理模块(TPKI_pks)托管私钥。最后阶段节点Bers可以向私钥管理模块TPKI_pks返回成功接收到托管的私钥的确认消息。
在一个实施例中，所述注册信息包括所述节点的标识。所述数字证书颁发中心包括认证数据库TPKI_cadb，如图15所示。认证数据库TPKI_cadb是用于存储颁发的数字证书的数据库。
在通过认证模块TPKI_ca，生成所述节点的数字证书之后，所述方法还包括：步骤570，通过认证模块TPKI_ca，将所述节点的标识和节点的数字证书相对应地存储在认证数据库TPKI_cadb中。
在该实施例中，所述私钥查询请求包括所述节点的标识，所述数字证书查询请求包括所述节点的标识，以便所述认证模块TPKI_ca根据认证数据库TPKI_cadb中是否有与所述标识对应存储的数字证书，确定是否认证成功。也就是说，在认证模块TPKI_ca接收到数字证书查询请求，查询所述节点具有的数字证书，以确定是否向所述私钥管理模块TPKI_pks发送数字证书认证成功的应答时，是按照数字证书查询请求中所述节点的标识，在认证数据库TPKI_cadb中查找对应的数字证书的。
图16示出了根据本申请一个实施例的数字证书颁发中心的详细模块图。如图16所示，除了前面介绍过的公私钥生成模块TPKI_sdk、认证模块TPKI_ca、认证策略模块TPKI_aus、私钥管理模块TPKI_pks、认证数据库TPKI_cadb之外，该实施例中，数字证书颁发中心还包括注册模块TPKI_ra。注册模块TPKI_ra是向认证模块TPKI_ca传递从所述节点Bers接到的公钥和注册信息，并向节点Bers返回生成的数字证书的模块，是节点Bers和认证模块TPKI_ca的中介模块。即，步骤530包括：接收由注册模块TPKI_ra转发的所述节点的公钥和注册信息。步骤560中将数字证书发送给所述节点包括：将数字证书经由注册模块TPKI_ra发送给所述节点。
根据本申请的一个实施例，如图6所示，还提供了一种数字证书颁发中心，包括：
公私钥生成模块TPKI_sdk，用于响应于来自区块链网络中的节点的公私钥请求，为所述节点生成所述节点的公钥和私钥并发送到所述节点；
认证模块TPKI_ca，用于接收所述节点的公钥和注册信息，对所述注册信息进行认证，如果认证成功，生成所述节点的数字证书并发送给所述节点，所述数字证书包含明文信息和利用认证模块TPKI_ca的私钥对所述明文信息形成的签名，以便所述节点利用认证模块TPKI_ca的公钥对所述签名进行验证，所述明文信息包括所述节点的公钥。
在一个实施例中，参见图6所示，所述数字证书颁发中心还包括认证策略模块TPKI_aus，认证策略模块TPKI_aus，用于存储与区块链网络中的各节点对应的注册信息认证策略。
在一个实施例中，如图8所示，所述数字证书颁发中心还包括：私钥管理模块TPKI_pks,用于接收由所述节点发送的私钥并保存。
在一个实施例中，所述认证模块TPKI_ca，用于：
接收所述节点利用私钥管理模块TPKI_pks的公钥加密的第一随机会话密钥；
利用私钥管理模块TPKI_pks的私钥解密加密的第一随机会话密钥，得到所述第一随机会话密钥；
接收所述节点利用所述第一随机会话密钥加密的所述节点的私钥；
利用解密得到的第一随机会话密钥，解密加密的所述节点的私钥，得到所述节点的私钥。
在一个实施例中，所述认证模块TPKI_ca还用于：
接收所述节点发送的所述私钥管理模块TPKI_pks的数字证书获取请求；
根据所述数字证书获取请求向所述节点发送所述私钥管理模块TPKI_pks的数字证书，所述数字证书包括利用认证模块TPKI_ca的私钥进行的签名，以便所述节点接收到所述私钥管理模块TPKI_pks的数字证书后，用认证模块TPKI_ca的公钥进行验证。
在一个实施例中，所述私钥管理模块TPKI_pks还用于：
接收所述节点的私钥查询请求；
向认证模块TPKI_ca发送所述节点的数字证书查询请求；
如果接收到所述认证模块TPKI_ca根据所述数字证书查询请求生成的数字证书认证成功的应答，通过所述私钥管理模块TPKI_pks，根据所述私钥查询请求向所述节点发送所述节点的私钥。
在一个实施例中，所述私钥管理模块TPKI_pks还用于：
接收所述节点利用私钥管理模块TPKI_pks的公钥加密的第二随机会话密钥；
利用私钥管理模块TPKI_pks的私钥解密加密的第二随机会话密钥，得到所述第二随机会话密钥；
根据所述私钥查询请求查询所述节点的私钥；
利用所述第二随机会话密钥加密所述节点的私钥并发送到所述节点，以便所述节点利用所述第二随机会话密钥解密加密的所述节点的私钥，得到所述节点的私钥。
在一个实施例中，所述注册信息包括所述节点的标识。如图16所示，所述数字证书颁发中心包括认证数据库TPKI_cadb，用于将所述节点的标识和所述节点的数字证书相对应地存储；所述私钥查询请求包括所述节点的标识，所述数字证书查询请求包括所述节点的标识，以便所述认证模块TPKI_ca根据认证数据库TPKI_cadb中是否存在与所述标识对应存储的数字证书，确定是否认证成功。
在一个实施例中，所述节点包括单位节点和服务商节点；
当所述节点是服务商节点时，所述接收所述节点的公钥和注册信息包括：接收所述节点的公钥、注册信息、以及服务商节点所服务单位的权限信息；
若所述数字证书颁发中心还包括认证策略模块TPKI_aus，所述认证模块TPKI_ca还用于：如果认证成功，向认证策略模块TPKI_aus发送所述权限信息存储；
所述私钥查询请求包括所述服务商节点的标识、和所述服务商节点要查询的密钥所属节点的标识；所述认证模块TPKI_ca还用于：根据认证策略模块TPKI_aus存储的所述权限信息，确定所述服务商节点要查询的密钥所属节点的标识是所述服务商节点所服务单位或所述服务商节点的标识时，认证成功。
在一个实施例中，所述与所述节点对应的注册信息认证策略包括特定于所述节点类型的注册信息认证策略；所述注册信息中含有所述节点类型；所述认证模块TPKI_ca还用于：从认证策略模块TPKI_aus获取特定于所述节点类型的注册信息认证策略。
在一个实施例中，所述区块链包括多个子区块链；所述为所述节点生成所述节点的公钥和私钥包括为所述节点生成所述节点的待注册子区块链上的公钥和私钥；所述注册信息包括待注册子区块链；所述认证模块TPKI_ca还用于：从认证策略模块TPKI_aus获取与待注册子区块链对应的注册信息认证策略；基于述待注册子区块链对应的注册信息认证策略，对所述注册信息进行在待注册子区块链上的认证；所述明文信息包括认证成功的子区块链上的公钥。
在一个实施例中，所述私钥查询请求包括要查询的私钥所属的子区块链，所述节点的数字证书查询请求包括要查询的私钥所属的子区块链，使得所述认证模块TPKI_ca根据要查询的私钥所属的子区块链是否是所述数字证书的明文信息中含有的认证成功的公钥对应的子区块链，确定是否发送数字证书认证成功的应答。
在一个实施例中，所述区块链包括多个子区块链；所述注册信息包括节点类型；所述公私钥生成模块TPKI_sdk用于：为所述节点生成所述节点在不同子区块链上的公钥和私钥；若数字证书颁发中心还包括认证策略模块TPKI_aus，认证模块TPKI_ca还用于：在对所述注册信息进行认证之后，如果认证成功，基于所述节点的类型生成特定于所述节点类型的子区块链权限信息，并将该子区块链权限信息存储在认证策略模块TPKI_aus，该子区块链权限信息包括针对不同业务类型允许查询的子区块链；所述私钥查询请求具有所述节点类型和业务类型；所述数字证书查询请求具有所述节点类型和业务类型；所述认证模块TPKI_ca从认证策略模块TPKI_aus查询特定于所述节点类型的子区块链权限信息，根据该子区块链权限信息以及该业务类型，确定允许查询的子区块链，将允许查询的子区块链放入数字证书认证成功的应答中，发送给所述私钥管理模块TPKI_pks。所述向所述节点发送所述节点的私钥，包括：向所述节点发送所述节点的在允许查询的子区块链上的私钥。
在一个实施例中，私钥管理模块TPKI_pks中保存的私钥采用加密方式保存，加密所用的密码硬编码在私钥管理模块TPKI_pks中。
根据本申请实施例的为区块链网络中的节点发放数字证书的方法可以由图18的数字证书颁发中心103实现。下面参照图18来描述根据本申请实施例的数字证书颁发中心103。图18显示的数字证书颁发中心103仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图18所示，数字证书颁发中心103以通用计算设备的形式表现。数字证书颁发中心103的组件可以包括但不限于：上述至少一个处理单元710、上述至少一个存储单元720、连接不同***组件(包括存储单元720和处理单元710)的总线730。
其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元710执行，使得所述处理单元710执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元710可以执行如图5中所示的各个步骤。
存储单元720可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)7201和/或高速缓存存储单元7202，还可以进一步包括只读存储单元(ROM)7203。
存储单元720还可以包括具有一组(至少一个)程序模块7205的程序/实用工具7204，这样的程序模块7205包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
总线730可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、***总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
数字证书颁发中心103也可以与一个或多个外部设备900(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该记账节点21交互的设备通信，和/或与使得该数字证书颁发中心103能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口750进行。并且，数字证书颁发中心103还可以通过网络适配器760与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器760通过总线730与数字证书颁发中心103的其它模块通信。应当明白，尽管图中未示出，可以结合数字证书颁发中心103使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本申请实施方式的方法。
在本申请的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。
根据本申请的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可 以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。
所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。
可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
此外，尽管在附图中以特定顺序描述了本申请中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性 存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本申请实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由所附的权利要求指出。

Claims (17)

  1. 一种为区块链网络中的节点发放数字证书的方法，所述方法由数字证书颁发中心执行，所述数字证书颁发中心包括公私钥生成模块(TPKI_sdk)和认证模块(TPKI_ca)，所述方法包括：
    响应于来自区块链网络中的节点的公私钥请求，通过所述公私钥生成模块(TPKI_sdk)，为所述节点生成所述节点的公钥和私钥并发送到所述节点；
    通过所述认证模块(TPKI_ca)，接收所述节点的公钥和注册信息；
    通过所述认证模块(TPKI_ca)，对所述注册信息进行认证；
    如果认证成功，通过所述认证模块(TPKI_ca)，生成所述节点的数字证书并发送给所述节点，所述数字证书包含明文信息和利用所述认证模块(TPKI_ca)的私钥对所述明文信息形成的签名，以便所述节点利用所述认证模块(TPKI_ca)的公钥对所述签名进行验证，所述明文信息包括所述节点的公钥。
  2. 根据权利要求1所述的方法，所述数字证书颁发中心还包括认证策略模块(TPKI_aus)，所述通过所述认证模块(TPKI_ca)，对所述注册信息进行认证之前，所述方法还包括：
    通过所述认证模块(TPKI_ca)，从所述认证策略模块(TPKI_aus)获取与所述节点对应的注册信息认证策略；
    所述通过所述认证模块(TPKI_ca)，对所述注册信息进行认证，包括：
    通过所述认证模块(TPKI_ca)，基于与所述节点对应的注册信息认证策略对所述注册信息进行认证。
  3. 根据权利要求1或2所述的方法，所述数字证书颁发中心还包括私钥管理模块(TPKI_pks)，在响应于来自区块链网络中的节点的公私钥请求，通过所述公私钥生成模块(TPKI_sdk)，为所述节点生成所述节点的公钥和私钥并发送到所述节点之后，所述方法还包括：
    通过所述私钥管理模块(TPKI_pks)，接收由所述节点发送的私钥并保存。
  4. 根据权利要求3所述的方法，所述接收由所述节点发送的私钥，包括：
    接收所述节点利用所述私钥管理模块(TPKI_pks)的公钥加密的第一随机会话密钥；
    利用所述私钥管理模块(TPKI_pks)的私钥解密所述加密的第一随机会话密钥，得到所述第一随机会话密钥；
    接收所述节点利用所述第一随机会话密钥加密的所述节点的私钥；
    利用解密得到的第一随机会话密钥，解密加密的所述节点的私钥，得到所述节点的私钥。
  5. 根据权利要求4所述的方法，在接收所述节点利用所述私钥管理模块(TPKI_pks)的公钥加密的第一随机会话密钥之前，所述方法还包括：
    通过认证模块(TPKI_ca)，接收所述节点发送的所述私钥管理模块(TPKI_pks)的数字证书获取请求；
    通过认证模块(TPKI_ca)，根据所述数字证书获取请求向所述节点发送所述私钥管理模块(TPKI_pks)的数字证书，所述数字证书包括利用所述认证模块(TPKI_ca)的私钥进行的签名，以便所述节点接收到所述私钥管理模块(TPKI_pks)的数字证书后，利用所述认证模块(TPKI_ca)的公钥进行验证。
  6. 根据权利要求3所述的方法，在通过所述私钥管理模块(TPKI_pks)，接收由所述节点发送的私钥并保存之后，所述方法还包括：
    通过所述私钥管理模块(TPKI_pks)，接收所述节点的私钥查询请求；
    通过所述私钥管理模块(TPKI_pks)，向认证模块(TPKI_ca)发送所述节点的数字证书查询请求；
    如果接收到所述认证模块(TPKI_ca)根据所述数字证书查询请求生成的数字证书认证成功的应答，通过所述私钥管理模块(TPKI_pks)，根据所述私钥查询请求向所述节点发送所述节点的私钥。
  7. 根据权利要求6所述的方法，所述根据所述私钥查询请求向所述节点发送所述节点的私钥，包括：
    接收所述节点利用所述私钥管理模块(TPKI_pks)的公钥加密的第二随机会话密钥；
    利用所述私钥管理模块(TPKI_pks)的私钥解密所述加密的第二随机会话密钥，得到所述第二随机会话密钥；
    根据所述私钥查询请求查询所述节点的私钥；
    利用所述第二随机会话密钥加密所述节点的私钥并发送到所述节点，以便所述节点利用所述第二随机会话密钥解密加密的所述节点的私钥，得到所述节点的私钥。
  8. 根据权利要求6所述的方法，所述注册信息包括所述节点的标识，所述数字证书颁发中心包括认证数据库(TPKI_cadb)；
    在通过所述认证模块(TPKI_ca)，生成所述节点的数字证书之后，所述方法还包括：
    通过所述认证模块(TPKI_ca)，将所述节点的标识和所述节点的数字证书相对应地存储在认证数据库(TPKI_cadb)中；
    所述私钥查询请求包括所述节点的标识，所述数字证书查询请求包括所述节点的标识，以便所述认证模块(TPKI_ca)根据所述认证数据库(TPKI_cadb)中是否存在与所述标识对应存储的数字证书，确定是否认证成功。
  9. 根据权利要求6所述的方法，所述节点包括单位节点和服务商节点；当所述节点是服务商节点时，所述接收所述节点的公钥和注册信息，包括：
    接收所述服务商节点的公钥、注册信息、以及所述服务商节点所服务单位的权限信息；
    若所述数字证书颁发中心还包括认证策略模块(TPKI_aus)，在通过所述认证模块(TPKI_ca)对所述注册信息进行认证后，所述方法还包括：
    如果认证成功，通过所述认证模块(TPKI_ca)，向所述认证策略模块(TPKI_aus)发送所述权限信息存储；
    所述私钥查询请求包括所述服务商节点的标识和所述服务商节点要查询的密钥所属节点的标识，所述认证模块(TPKI_ca)根据认证策略模块(TPKI_aus)存储的所述权限信息，确定所述服务商节点要查询的密钥所属节点的标识是所述服务商节点所服务的单位或所述服务商节点的标识时，认证成功。
  10. 根据权利要求2所述的方法，所述与所述节点对应的注册信息认证策略包括特定于所述节点类型的注册信息认证策略；
    所述注册信息中含有所述节点类型；
    所述从所述认证策略模块(TPKI_aus)获取与所述节点对应的注册信息认证策略，包括：从所述认证策略模块(TPKI_aus)获取特定于所述节点类型的注册信息认证策略。
  11. 根据权利要求2所述的方法，所述区块链包括多个子区块链；所述为所述节点生成所述节点的公钥和私钥，包括：
    为所述节点生成所述节点的待注册子区块链上的公钥和私钥；
    所述注册信息包括所述待注册子区块链；
    所述从所述认证策略模块(TPKI_aus)获取与所述节点对应的注册信息认证策略，包括：
    从所述认证策略模块(TPKI_aus)获取与所述待注册子区块链对应的注册信息认证策略；
    所述基于与所述节点对应的注册信息认证策略对所述注册信息进行认证，包括：
    基于所述待注册子区块链对应的注册信息认证策略，对所述注册信息进行在所述待注册子区块链上的认证；
    所述明文信息包括认证成功的子区块链上的公钥。
  12. 根据权利要求6所述的方法，所述区块链包括多个子区块链，所述注册信息包括节点类型，所述为所述节点生成所述节点的公钥和私钥，包括：
    为所述节点生成所述节点在不同子区块链上的公钥和私钥，
    若所述数字证书颁发中心还包括认证策略模块(TPKI_aus)，在通过认证模块(TPKI_ca)对所述注册信息进行认证之后，所述方法还包括：
    如果认证成功，通过所述认证模块(TPKI_ca)，基于所述节点的类型生成特定于所述节点类型的子区块链权限信息，并将所述子区块链权限信息存储在所述认证策略模块(TPKI_aus)，所述子区块链权限信息包括针对不同业务类型允许查询的子区块链，
    所述私钥查询请求具有所述节点类型和业务类型，所述数字证书查询请求具有所述节点类型和业务类型，所述认证模块(TPKI_ca)从所述认证策略模块(TPKI_aus)查询特定于所述节点类型的子区块链权限信息，根据所述子区块链权限信息以及该业务类型，确定允许查询的子区块链，将允许查询的子区块链放入数字证书认证成功的应答中，发送给所述私钥管理模块(TPKI_pks)；
    所述向所述节点发送所述节点的私钥，包括：
    向所述节点发送所述节点的在允许查询的子区块链上的私钥。
  13. 根据权利要求3所述的方法，所述私钥管理模块(TPKI_pks)中保存的私钥采用加密方式保存，加密所用的密码硬编码在所述私钥管理模块(TPKI_pks)中。
  14. 一种数字证书颁发中心，所述数字证书颁发中心包括：
    公私钥生成模块(TPKI_sdk)，用于响应于来自区块链网络中的节点的公私钥请求，为所述节点生成所述节点的公钥和私钥并发送到所述节点；
    认证模块(TPKI_ca)，用于接收所述节点的公钥和注册信息，对所述注册信息进行认证，如果认证成功，生成所述节点的数字证书并发送给所述节点，所述数字证书包含明文信息和利用所述认证模块(TPKI_ca)的私钥对所述明文信息形成的签名，以便所述节点利用所述认证模块(TPKI_ca)的公钥对所述签名进行验证，所述明文信息包括所述节点的公钥。
  15. 一种数字证书颁发中心，包括：
    存储器，存储有计算机可读指令；
    处理器，读取存储器存储的计算机可读指令，以执行权利要求1-13中的任一个所述的方法。
  16. 一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1-13中的任一个所述的方法。
  17. 一种计算机程序产品，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1-13中的任一个所述的方法。
PCT/CN2019/128755 2019-01-09 2019-12-26 发放数字证书的方法、数字证书颁发中心和介质 WO2020143470A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021518941A JP7273148B2 (ja) 2019-01-09 2019-12-26 デジタル証明書の発行方法、デジタル証明書発行センター、記憶媒体およびコンピュータプログラム
US17/171,937 US11924358B2 (en) 2019-01-09 2021-02-09 Method for issuing digital certificate, digital certificate issuing center, and medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910020435.5A CN109617698B (zh) 2019-01-09 2019-01-09 发放数字证书的方法、数字证书颁发中心和介质
CN201910020435.5 2019-01-09

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/171,937 Continuation US11924358B2 (en) 2019-01-09 2021-02-09 Method for issuing digital certificate, digital certificate issuing center, and medium

Publications (1)

Publication Number Publication Date
WO2020143470A1 true WO2020143470A1 (zh) 2020-07-16

Family

ID=66016529

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/128755 WO2020143470A1 (zh) 2019-01-09 2019-12-26 发放数字证书的方法、数字证书颁发中心和介质

Country Status (4)

Country Link
US (1) US11924358B2 (zh)
JP (1) JP7273148B2 (zh)
CN (1) CN109617698B (zh)
WO (1) WO2020143470A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112419021A (zh) * 2020-10-21 2021-02-26 西安电子科技大学 电子***验证方法、***、存储介质、计算机设备、终端
CN112907247A (zh) * 2021-03-18 2021-06-04 上海能链众合科技有限公司 一种区块链授权计算控制方法
CN113179165A (zh) * 2021-03-25 2021-07-27 广东工业大学 基于区块链的移动网络密钥管理及通信方法、移动网络、计算机装置和存储介质
CN113242133A (zh) * 2021-04-29 2021-08-10 中国人民银行数字货币研究所 一种数字证书管理方法和装置
CN113626793A (zh) * 2021-07-15 2021-11-09 中国信息通信研究院 健康认证方法、***、装置、设备及可读存储介质

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101849918B1 (ko) * 2016-10-26 2018-04-19 주식회사 코인플러그 Utxo 기반 프로토콜을 사용하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
CN109617698B (zh) 2019-01-09 2021-08-03 腾讯科技（深圳）有限公司 发放数字证书的方法、数字证书颁发中心和介质
GB2583767A (en) * 2019-05-10 2020-11-11 Nchain Holdings Ltd Methods and devices for public key management using a blockchain
CN110378691A (zh) * 2019-06-18 2019-10-25 重庆金融资产交易所有限责任公司 基于部署中心的区块链部署方法、装置和计算机设备
CN110458558A (zh) * 2019-07-04 2019-11-15 重庆金融资产交易所有限责任公司 基于区块链的数据保密方法、装置和计算机设备
US20220321357A1 (en) * 2019-08-20 2022-10-06 Nippon Telegraph And Telephone Corporation User credential control system and user credential control method
CN112465575A (zh) * 2019-09-09 2021-03-09 辽宁政税科技有限公司 一种基于区块链技术的***管理***及方法
CN112533195B (zh) * 2019-09-19 2023-03-10 华为技术有限公司 一种设备认证方法及装置
WO2021087073A1 (en) 2019-10-30 2021-05-06 Via Science, Inc. Secure outsourcing of a multiplication
CN111062716B (zh) * 2019-11-29 2021-06-22 支付宝(杭州)信息技术有限公司 生成区块链签名数据的方法及装置、区块链交易发起***
CN112887254A (zh) * 2019-11-29 2021-06-01 中国电信股份有限公司 个人信息确认方法、装置、***及存储介质
CN111092724B (zh) * 2019-12-25 2022-11-15 杭州溪塔科技有限公司 一种区块链***数字证书签发方法、设备、***及介质
CN111262834B (zh) * 2020-01-09 2022-03-29 中国信息通信研究院 物理实体的认证、可信解析方法、装置及***
CN111327612B (zh) * 2020-02-19 2022-05-24 奥比中光科技集团股份有限公司 一种用于认证深度测量装置的***及方法
CN111539813B (zh) * 2020-07-10 2020-12-11 支付宝(杭州)信息技术有限公司 业务行为的回溯处理方法、装置、设备及***
CN111917734B (zh) * 2020-07-12 2023-03-10 中信银行股份有限公司 公钥的管理方法、装置、电子设备及计算机可读存储介质
CN111865988B (zh) * 2020-07-22 2022-10-18 山东华普信息科技有限公司 一种基于区块链的无证书密钥管理方法、***及终端
CN112131478B (zh) * 2020-09-28 2024-05-17 京东科技信息技术有限公司 交易检测方法及装置
CN112839041B (zh) * 2021-01-05 2022-09-23 国网浙江省电力有限公司嘉兴供电公司 基于区块链的电网身份认证方法、装置、介质和设备
CN112861106B (zh) * 2021-02-26 2023-01-10 卓尔智联(武汉)研究院有限公司 数字证书处理方法及***、电子设备及存储介质
CN112862487A (zh) * 2021-03-03 2021-05-28 青岛海链数字科技有限公司 一种数字证书认证方法、设备及存储介质
EP4145762B1 (en) * 2021-09-06 2023-10-25 Axis AB Method and system for enabling secure processing of data using a processing application
CN114157432A (zh) * 2021-11-25 2022-03-08 上海派拉软件股份有限公司 数字证书获取方法、装置、电子设备、***和存储介质
CN114221759B (zh) * 2021-11-29 2024-04-12 成都卫士通信息产业股份有限公司 一种远程监控部署方法、装置、电子设备及存储介质
CN113869901B (zh) * 2021-12-02 2022-05-10 腾讯科技（深圳）有限公司 密钥生成方法、装置、计算机可读存储介质及计算机设备
CN114244527B (zh) * 2021-12-14 2023-10-31 中国电力科学研究院有限公司 基于区块链的电力物联网设备身份认证方法及***
CN114884702A (zh) * 2022-04-19 2022-08-09 海南大学 身份注册方法、身份认证方法及身份管理***
CN114760070A (zh) * 2022-04-22 2022-07-15 深圳市永达电子信息股份有限公司 数字证书颁发方法、数字证书颁发中心和可读存储介质
CN114697048B (zh) * 2022-06-01 2022-08-26 天津市普迅电力信息技术有限公司 基于区块链的碳排放数据共享方法和***
CN115296838B (zh) * 2022-06-24 2023-09-26 北京中科金财科技股份有限公司 基于区块链的数据共享方法、***及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108390872A (zh) * 2018-02-09 2018-08-10 北京京东尚科信息技术有限公司 证书管理方法、装置、介质及电子设备
CN108712429A (zh) * 2018-05-24 2018-10-26 西安电子科技大学 基于区块链云外包计算数据的隐私保护方法
US20180322491A1 (en) * 2017-03-31 2018-11-08 Vijay K. Madisetti Method and System for Blockchain-Based Combined Identity, Ownership, Integrity and Custody Management
CN109003083A (zh) * 2018-07-27 2018-12-14 山东渔翁信息技术股份有限公司 一种基于区块链的ca认证方法、装置及电子设备
CN109150539A (zh) * 2018-07-24 2019-01-04 深圳前海益链网络科技有限公司 一种基于区块链的分布式ca认证***、方法及装置
CN109617698A (zh) * 2019-01-09 2019-04-12 腾讯科技（深圳）有限公司 发放数字证书的方法、数字证书颁发中心和介质

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6615350B1 (en) * 1998-03-23 2003-09-02 Novell, Inc. Module authentication and binding library extensions
CN103825733A (zh) * 2014-02-28 2014-05-28 华为技术有限公司 基于组合公钥密码体制的通信方法、装置及***
US9692748B2 (en) * 2014-09-24 2017-06-27 Oracle International Corporation Unified provisioning of applications on devices in an enterprise system
WO2016193962A1 (en) * 2015-06-02 2016-12-08 K2View Ltd Encryption directed database management system and method
KR101637854B1 (ko) * 2015-10-16 2016-07-08 주식회사 코인플러그 블록체인을 기반으로 하는 공인인증서 발급시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 발급방법 및 블록체인을 기반으로 하는 공인인증서 인증시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 인증방법
US10771451B2 (en) * 2016-09-13 2020-09-08 Queralt, Inc. Mobile authentication and registration for digital certificates
GB2557577A (en) * 2016-10-21 2018-06-27 Cygnetise Ltd Methods and apparatus for recording a change of authorisation state of one or more authorisation agents
US10872155B2 (en) * 2016-11-16 2020-12-22 Samsung Electronics Co., Ltd. Computing system for managing firmware and firmware managing method thereof
WO2018162789A1 (en) * 2017-03-06 2018-09-13 Nokia Technologies Oy Secure de-centralized domain name system
JP6635970B2 (ja) * 2017-03-31 2020-01-29 セコム株式会社 通信装置
CN108900507B (zh) * 2018-06-29 2020-12-22 全链通有限公司 区块链实名认证方法和***
CN112215608A (zh) * 2019-01-18 2021-01-12 创新先进技术有限公司 数据处理方法和装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180322491A1 (en) * 2017-03-31 2018-11-08 Vijay K. Madisetti Method and System for Blockchain-Based Combined Identity, Ownership, Integrity and Custody Management
CN108390872A (zh) * 2018-02-09 2018-08-10 北京京东尚科信息技术有限公司 证书管理方法、装置、介质及电子设备
CN108712429A (zh) * 2018-05-24 2018-10-26 西安电子科技大学 基于区块链云外包计算数据的隐私保护方法
CN109150539A (zh) * 2018-07-24 2019-01-04 深圳前海益链网络科技有限公司 一种基于区块链的分布式ca认证***、方法及装置
CN109003083A (zh) * 2018-07-27 2018-12-14 山东渔翁信息技术股份有限公司 一种基于区块链的ca认证方法、装置及电子设备
CN109617698A (zh) * 2019-01-09 2019-04-12 腾讯科技（深圳）有限公司 发放数字证书的方法、数字证书颁发中心和介质

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112419021A (zh) * 2020-10-21 2021-02-26 西安电子科技大学 电子***验证方法、***、存储介质、计算机设备、终端
CN112419021B (zh) * 2020-10-21 2023-11-03 西安电子科技大学 电子***验证方法、***、存储介质、计算机设备、终端
CN112907247A (zh) * 2021-03-18 2021-06-04 上海能链众合科技有限公司 一种区块链授权计算控制方法
CN112907247B (zh) * 2021-03-18 2024-01-26 上海零数众合信息科技有限公司 一种区块链授权计算控制方法
CN113179165A (zh) * 2021-03-25 2021-07-27 广东工业大学 基于区块链的移动网络密钥管理及通信方法、移动网络、计算机装置和存储介质
CN113179165B (zh) * 2021-03-25 2022-08-05 广东工业大学 基于区块链的移动网络密钥管理及通信方法、装置和介质
CN113242133A (zh) * 2021-04-29 2021-08-10 中国人民银行数字货币研究所 一种数字证书管理方法和装置
CN113626793A (zh) * 2021-07-15 2021-11-09 中国信息通信研究院 健康认证方法、***、装置、设备及可读存储介质

Also Published As

Publication number Publication date
CN109617698B (zh) 2021-08-03
US11924358B2 (en) 2024-03-05
JP2022504420A (ja) 2022-01-13
US20210167972A1 (en) 2021-06-03
CN109617698A (zh) 2019-04-12
JP7273148B2 (ja) 2023-05-12

Similar Documents

Publication Publication Date Title
WO2020143470A1 (zh) 发放数字证书的方法、数字证书颁发中心和介质
US20210367795A1 (en) Identity-Linked Authentication Through A User Certificate System
US8898457B2 (en) Automatically generating a certificate operation request
US9225525B2 (en) Identity management certificate operations
US8627409B2 (en) Framework for automated dissemination of security metadata for distributed trust establishment
US8788811B2 (en) Server-side key generation for non-token clients
US9137017B2 (en) Key recovery mechanism
US9172541B2 (en) System and method for pool-based identity generation and use for service access
AU2017225928A1 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
CN108768933B (zh) 一种区块链平台上自主可监管数字身份认证***
US20110296171A1 (en) Key recovery mechanism
US8984283B2 (en) Private certificate validation method and apparatus
US20100154040A1 (en) Method, apparatus and system for distributed delegation and verification
JP2010531516A (ja) 安全でないネットワークを介する装置のプロビジョニング及びドメイン加入エミュレーション
EP2957064B1 (en) Method of privacy-preserving proof of reliability between three communicating parties
JP5992535B2 (ja) 無線ｉｄプロビジョニングを実行するための装置及び方法
JP2020120173A (ja) 電子署名システム、証明書発行システム、証明書発行方法及びプログラム
KR101491553B1 (ko) 인증서 기반의 dms를 이용한 안전한 스마트그리드 통신 시스템 및 방법
JP6199506B2 (ja) 複数のサービスシステムを制御するサーバシステム及び方法
WO2021073383A1 (zh) 一种用户注册方法、用户登录方法及对应装置
KR101209812B1 (ko) 홈 네트워크 시스템에서의 클라이언트 접근 제어 방법 및 이를 위한 장치
CN113742700B (zh) 一种基于门户的跨域软件***集成方法
IES20070726A2 (en) Automated authenticated certificate renewal system
Marian et al. A Technical Investigation towards a Cloud-Based Signature Solution
WO2020017643A1 (ja) 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19909061

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021518941

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19909061

Country of ref document: EP

Kind code of ref document: A1