WO2018184446A1 - 实现ca互信的方法、装置、系统和电子设备 - Google Patents

实现ca互信的方法、装置、系统和电子设备 Download PDF

Info

Publication number
WO2018184446A1
WO2018184446A1 PCT/CN2018/078848 CN2018078848W WO2018184446A1 WO 2018184446 A1 WO2018184446 A1 WO 2018184446A1 CN 2018078848 W CN2018078848 W CN 2018078848W WO 2018184446 A1 WO2018184446 A1 WO 2018184446A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
entity
blockchain
issued
mutual trust
Prior art date
Application number
PCT/CN2018/078848
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 中国移动通信有限公司研究院
Publication of WO2018184446A1 publication Critical patent/WO2018184446A1/zh

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/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
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • 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
    • 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
    • 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]

Definitions

  • the present disclosure relates to the field of communications technologies, and in particular, to a method, an apparatus, a system, and an electronic device for implementing CA mutual trust.
  • PKI Public Key Infrastructure
  • HTTPS Hyper Text Transfer Protocol over Secure Socket Layer
  • the relying party of the PKI needs to construct a corresponding certificate authentication path when verifying the other party's certificate, and there must be a trust starting point in the path, that is, the trust anchor.
  • the trust anchor is usually a self-signed certificate of a CA (Certificate Authority) trusted by the relying party.
  • CA Certificate Authority
  • the number of trust anchors of a relying party is usually limited.
  • the CA self-signed certificate corresponding to the other certificate is not within the trust anchor of the relying party, the relying party cannot construct a trusted certificate authentication path, and thus cannot perform certificate-based secure communication or signature authentication. This leads to the issue of CA mutual trust.
  • list scheme common authoritative list is the list of "electronic certification service license" issued by the Ministry of Industry and Information Technology of the People's Republic of China, and the list maintained by Microsoft Root Certificate Program (that is, pre- List of CAs placed in the Windows operating system and Internet Explorer, and lists of WebTrust certifications in North America
  • CA cross-certification scheme mesh structure: A CA trusts its own relying party by issuing certificates for other CAs. Can achieve mutual trust with other CA certificate holders; and, Bridge CA scheme (star structure): Introduce bridge CA as an intermediary for other CA mutual trusts, after two CAs cross-certify with bridge CA respectively, the two CAs They also reached mutual trust.
  • the CA cross-certification scheme is similar to the trust relationship of the group's equal cooperation in real life.
  • the CA mutual trust problem can be solved well.
  • a large number of CAs perform cross-certification, a complex network structure is formed, which makes the certificate authentication path become longer and even forms a loop, and the certificate policy (CP) ) After multiple mappings, the use of certificates is greatly limited.
  • the bridge CA scheme is similar to the trust relationship of the industry associations in real life. When the number of CAs is large, the disadvantages of the two-way cross-certification can be avoided. However, the choice of the bridge CA operator is a problem, and its credibility directly determines the reliability of the mutual trust relationship. .
  • the present disclosure provides a method, apparatus, system, and electronic device for implementing CA mutual trust to improve flexibility in implementing CA mutual trust.
  • the present disclosure provides a method for implementing CA mutual trust, which is applied to a CA entity in a CA mutual trust system.
  • the CA mutual trust system includes at least three CA entities, each of which forms a point-to-point P2P network and forms a blockchain system.
  • Each CA entity stores a blockchain record, and the blockchain record is used to record the entity certificate. Operational record.
  • the method includes: allocating a certificate to be issued to a certificate requester; and requesting, by the other CA entity in the system, a consensus on the certificate to be issued; if the other CA entity is determined to be the certificate to be issued If the consensus is passed, the certificate requesting party is issued with the to-be-issued entity certificate, and the block-chain authentication mark is included in the to-be-issued entity certificate, where the blockchain authentication mark is the identifier of the blockchain system. ; and update the stored blockchain record.
  • Each of the CA entities is respectively provided with a mutual trust agent, and each CA entity forms a P2P network through a correspondingly configured mutual trust agent and forms a blockchain system; the blockchain record is stored in the mutual trust agent.
  • the allocating the certificate to be issued to the certificate requester includes: receiving a certificate request request of the certificate requester; performing identity authentication on the certificate requester according to the certificate application request, and obtaining the certificate requester The identity authentication information; and the identity of the certificate requester is assigned to the certificate requester after the identity authentication of the certificate requester is passed.
  • the requesting, by the other CA entity in the system, the consensus of the to-be-signed entity certificate includes: requesting, by the corresponding mutual trust agent, a mutual trust agent module corresponding to another CA entity in the system
  • the entity certificate to be issued is used for the consensus; if the other CA entity determines that the other entity has passed the consensus of the entity to be issued, the certificate is to be issued to the certificate requester, including: if the other CA is determined
  • the mutual trust agent module corresponding to the entity passes the consensus of the to-be-issued entity certificate, and then issues the to-be-issued entity certificate to the certificate requesting party; and the updated stored blockchain record includes: in the block In the chain record, the new record corresponding to the entity certificate to be issued is added.
  • the mutual trust agent module corresponding to another CA entity in the system requests the consensus of the to-be-issued entity certificate by using a corresponding mutual trust agent, including: by using a corresponding mutual trust agent, to other systems in the system
  • the mutual trust agent module corresponding to the CA entity sends the identity of the entity to be issued and the identity authentication information of the certificate requester to request a consensus on the certificate to be issued.
  • the CA mutual trust system further includes: an intermediate CA entity corresponding to each CA entity; and the signing the certificate to be issued to the certificate requesting party, including: issuing, by the intermediate CA entity, the certificate requesting party The entity certificate to be issued.
  • the method further includes: if it is determined that the consensus of the other CA entity to the certificate to be issued is not passed, deleting the certificate to be issued, and issuing a final entity certificate to the certificate requesting party, where The blockchain authentication tag is not included in the final entity certificate.
  • the method further includes: receiving a certificate update request of the certificate requester; and assigning, to the certificate requester, a certificate to be issued, including: according to the step of allocating the certificate to be issued
  • the certificate update request the certificate requester is allocated a new certificate to be issued; the other CA entity in the system requests a consensus on the certificate to be issued, including: a corresponding mutual trust agent And requesting, by the mutual trust agent corresponding to another CA entity in the system, a consensus on the new certificate to be issued; if the other CA entity determines that the consensus of the certificate to be issued is passed,
  • the certificate requesting party issues the to-be-issued entity certificate, including: if the mutual trust agent corresponding to the other CA entity determines that the new identity of the to-be-issued entity certificate passes, the certificate requesting party issues the a new entity certificate to be issued; and the updated stored blockchain record includes: adding the certificate in the blockchain record Original supplicant entity certificate corresponding update records.
  • the method further includes: notifying the other CA entity to revoke the original entity certificate of the certificate requester.
  • the informing the other CA entity to revoke the original entity certificate of the certificate requester includes: sending, by the corresponding mutual trust agent, a certificate revocation request to the mutual trust agent corresponding to the other CA entity, requesting to revoke the certificate
  • the original entity certificate of the requesting party includes: adding, in the blockchain record, a revocation record corresponding to the original entity certificate.
  • the method further includes: receiving a certificate verification request of the certificate verification requester, including the entity certificate to be verified in the certificate verification request; determining a root CA entity according to the to-be-verified entity certificate, and the root CA entity Completing the verification of the to-be-verified entity certificate, obtaining a first verification result, determining whether the block chain authentication mark is included in the to-be-verified entity certificate, and using the corresponding setting mutual trust if the blockchain authentication flag is included And the blockchain authentication tag searches for the stored blockchain record, and determines, according to the search, whether the second verification result is obtained by verifying the certificate to be verified, and according to the first verification result and the The second verification result sends the final verification result to the certificate verification requester.
  • the sending, by the certificate verification requester, the final verification result according to the first verification result and the second verification result including: if the first verification result and the second verification result are both expressed Sending, by the verification of the to-be-verified entity certificate, the first verification result and/or the second verification result to the certificate verification requester; and if the first verification result and the second verification If the results are inconsistent, the information is selected according to the set verification result, the verification result with higher priority is selected as the final verification result, and the final verification result is sent to the certificate verification requester.
  • some embodiments of the present disclosure provide a method for implementing CA mutual trust, the method being applied to a CA entity in a CA mutual trust system, the CA mutual trust system including at least three CA entities, and each CA entity constituent point To the P2P network and form a blockchain system, each CA entity stores a blockchain record, and the blockchain record is used to record an operation record of the entity certificate.
  • the method includes: receiving a certificate consensus request of the first CA entity; performing a consensus on the to-be-issued entity certificate of the first CA entity according to the certificate consensus request of the first CA entity, where the to-be-issued entity certificate includes a blockchain authentication tag, wherein the blockchain authentication tag is an identity of the blockchain system; and if a consensus pass to the certificate to be issued is determined, the stored blockchain record is updated.
  • the updating the stored blockchain record includes: adding, in the blockchain record, a new record corresponding to the to-be-issued entity certificate.
  • the updating the stored blockchain record further includes: when there is an entity certificate update, adding, in the blockchain record, an update record corresponding to the updated entity certificate.
  • the method further includes: receiving a certificate revocation request of the first CA entity, determining, according to the certificate revocation request, whether to pass the certificate revocation request; and updating the stored blockchain record, including: when passing When the certificate revocation request is made, in the blockchain record, the revocation record corresponding to the revoked entity certificate is added.
  • some embodiments of the present disclosure provide an apparatus for implementing CA mutual trust, where the apparatus is applied to a CA entity in a CA mutual trust system, where the CA mutual trust system includes at least three CA entities, and each CA entity constitutes a point to A P2P network is formed and a blockchain system is formed; a blockchain record is stored in each CA entity, and the blockchain record is used to record an operation record of the entity certificate.
  • the device includes: an allocating module, configured to allocate a certificate to be issued to the certificate requesting party; and a requesting module, configured to request, by the other CA entity in the system, a consensus on the certificate to be issued; the issuing module is configured to: If it is determined that the other CA entity has passed the consensus of the to-be-signed entity certificate, the certificate requesting party issues the to-be-issued entity certificate, and the block-to-issuance entity certificate includes a blockchain authentication mark, where The blockchain authentication is marked as an identifier of the blockchain system; and an update module is used to update the stored blockchain record.
  • the device further includes: a mutual trust agent module, configured to form the P2P network and the other CA entity into a P2P network, and form a blockchain system; the blockchain record is stored in the mutual trust agent module. .
  • the distribution module includes: a receiving submodule, configured to receive a certificate request request of the certificate requesting party; and an identity authentication submodule, configured to perform identity authentication on the certificate requesting party according to the certificate request request, and obtain an identifier The identity authentication information of the certificate requesting party; and an allocation submodule, configured to allocate the to-be-signed entity certificate to the certificate requesting party after the identity authentication of the certificate requesting party is passed.
  • the requesting module is specifically configured to request, by using a corresponding mutual trust agent module, a mutual trust agent module corresponding to another CA entity in the system to perform a consensus on the to-be-issued entity certificate; the issuing module is specifically configured to: If it is determined that the mutual trust agent module corresponding to the other CA entity passes the consensus of the to-be-issued entity certificate, the certificate requesting party issues the to-be-issued entity certificate; and the update module is specifically used to In the blockchain record, the new record corresponding to the entity certificate to be issued is added.
  • the requesting module is specifically configured to send, by using a corresponding mutual trust agent module, the identity of the entity to be issued and the identity authentication information of the certificate requesting party to a mutual trust agent module corresponding to another CA entity in the system, Requesting a consensus on the entity certificate to be issued.
  • the CA mutual trust system further includes: an intermediate CA entity corresponding to each CA entity; and the signing module is specifically configured to issue, by the intermediate CA entity, the certificate to be issued to the certificate requesting party.
  • the device further includes: a deleting module, configured to delete the to-be-issued entity certificate and issue the final certificate to the certificate requesting party if it is determined that the other CA entity does not pass the consensus of the to-be-issued entity certificate An entity certificate, wherein the blockchain authentication token is not included in the final entity certificate.
  • a deleting module configured to delete the to-be-issued entity certificate and issue the final certificate to the certificate requesting party if it is determined that the other CA entity does not pass the consensus of the to-be-issued entity certificate An entity certificate, wherein the blockchain authentication token is not included in the final entity certificate.
  • the device further includes: a first receiving module, configured to receive a certificate update request of the certificate requester; the allocating module is specifically configured to allocate a new one to the certificate requester according to the certificate update request An entity certificate is to be issued; the requesting module is configured to request, by a corresponding mutual trust agent module, a mutual trust agent module corresponding to another CA entity in the system to perform a consensus on the new certificate to be issued; The issuing module is specifically configured to: if it is determined that the mutual trust agent module corresponding to the other CA entity passes the consensus of the new certificate to be issued, issue the new certificate to be issued to the certificate requesting party; The update module is specifically configured to: in the blockchain record, add an update record corresponding to the original entity certificate of the certificate requester.
  • the device further includes: a notification module, configured to notify the other CA entity to revoke the original entity certificate of the certificate requester.
  • the notification module is specifically configured to send, by the mutual trust agent module, a certificate revocation request to the mutual trust agent module corresponding to the other CA entity, requesting to revoke the original entity certificate of the certificate requester; and the update module Specifically, in the blockchain record, the revocation record corresponding to the original entity certificate is added.
  • the device further includes: a second receiving module, configured to receive a certificate verification request of the certificate verification requester, where the certificate verification request includes an entity certificate to be verified; and the first verification module is configured to be verified according to the to-be-verified
  • the entity certificate determines the root CA entity, and interacts with the root CA entity to complete the verification of the to-be-verified entity certificate, and obtains a first verification result.
  • the first determining module is configured to determine whether the to-be-verified entity certificate includes a zone.
  • a block chain authentication mark configured to: if the blockchain authentication mark is included, use a corresponding mutual trust agent module and the blockchain authentication mark to search for the stored blockchain record, and determine whether the blockchain record is used according to the search Obtaining a second verification result by verifying the certificate to be verified, and a result sending module, configured to send a final verification to the certificate verification requester according to the first verification result and the second verification result result.
  • the result sending module is specifically configured to: if the first verification result and the second verification result both indicate that the verification of the to-be-verified entity certificate is performed, send the first to the certificate verification requester a verification result and/or the second verification result; and if the first verification result and the second verification result are inconsistent, selecting information according to the set verification result, and selecting a verification result with a higher priority as a final Verify the result and send the final verification result to the certificate verification requester.
  • some embodiments of the present disclosure provide an apparatus for implementing CA mutual trust, where the apparatus is applied to a CA entity in a CA mutual trust system, where the CA mutual trust system includes at least three CA entities, and each CA entity constitutes a point to A P2P network is formed and a blockchain system is formed.
  • Each CA entity stores a blockchain record, and the blockchain record is used to record an operation record of the entity certificate.
  • the device includes: a receiving module, configured to receive a certificate consensus request of the first CA entity; and a consensus module, configured to perform, according to the certificate consensus request of the first CA entity, the entity certificate to be issued of the first CA entity a consensus that the entity certificate to be issued includes a blockchain authentication mark, wherein the blockchain authentication mark is an identifier of the blockchain system; and an update module, configured to determine a certificate for the entity to be issued When the consensus is passed, the stored blockchain record is updated.
  • the update module is specifically configured to: in the blockchain record, add a new record corresponding to the to-be-issued entity certificate.
  • the update module is specifically configured to: when there is an entity certificate update, add an update record corresponding to the updated entity certificate in the blockchain record.
  • the receiving module is further configured to: receive a certificate revocation request of the first CA entity, determine, according to the certificate revocation request, whether to pass the certificate revocation request; and the updating module is specifically configured to: when When the certificate revocation request is made, in the blockchain record, the revocation record corresponding to the revoked entity certificate is added.
  • some embodiments of the present disclosure provide a system for implementing CA mutual trust, including: at least three CA entities, each of which forms a point-to-point P2P network and forms a blockchain system; each CA entity stores a blockchain record for recording an operation record of the entity certificate; wherein, the first one of the at least three CA entities assigns a certificate to be issued to the certificate requester, and sends a second certificate to the system
  • the CA entity requests a consensus on the to-be-issued entity certificate; if it is determined that the second CA entity has passed the consensus of the to-be-issued entity certificate, the certificate requesting party issues the to-be-issued entity certificate, Included in the entity certificate to be issued is a blockchain authentication mark, wherein the blockchain authentication mark is an identifier of the blockchain system, and the stored blockchain record is updated; and the at least three of the at least three CA entities Receiving, by the second CA entity, a certificate consensus request of the first CA entity, and performing a consensus on the entity certificate to be issued of the first
  • Each of the CA entities is respectively provided with a mutual trust agent, and each CA entity forms a P2P network through a correspondingly configured mutual trust agent and forms a blockchain system; the blockchain record is stored in the mutual trust agent.
  • some embodiments of the present disclosure provide an electronic device, including: a processor, a memory, configured to store a computer program; wherein, when the processor invokes and executes a computer program stored on the memory, The processor implements a method of implementing certificate authority CA mutual trust as described in the foregoing first aspect.
  • some embodiments of the present disclosure provide a computer readable storage medium comprising a computer program stored on the computer readable storage medium, wherein when the computer program is executed by a processor, The processor performs the method of implementing certificate authority CA mutual trust as described in the foregoing first aspect.
  • some embodiments of the present disclosure provide an electronic device including a processor, a memory, for storing a computer program, wherein the processor is invoking and executing a computer program stored on the memory
  • the processor implements the method of implementing certificate authority CA mutual trust as described in the foregoing second aspect.
  • some embodiments of the present disclosure provide a computer readable storage medium comprising a computer program stored on the computer readable storage medium, wherein when the computer program is executed by a processor, The processor performs the method of implementing certificate authority CA mutual trust as described in the foregoing second aspect.
  • the correlation processing of the certificate based on the blockchain authentication mark can be implemented, without complicated mesh cross-certification, and the bridging relationship is not required to be established by an authoritative intermediary with higher credibility. Fine-grained mutual trust control for each user certificate granularity is achieved. Thus, utilizing the approach of some embodiments of the present disclosure, the flexibility to achieve CA mutual trust is increased.
  • FIG. 1 is a flow chart of a method of implementing CA mutual trust according to some embodiments of the present disclosure
  • FIG. 2 is a flow chart of a method of implementing CA mutual trust according to some embodiments of the present disclosure
  • FIG. 3 is a schematic diagram of a system for implementing CA mutual trust according to some embodiments of the present disclosure
  • FIG. 5 is a schematic structural diagram of a blockchain according to some embodiments of the present disclosure.
  • FIG. 6 is a flow chart of a certificate update process of some embodiments of the present disclosure.
  • FIG. 7 is a flow chart of a certificate revocation flow of some embodiments of the present disclosure.
  • FIG. 9 is a schematic diagram of an apparatus for implementing CA mutual trust according to some embodiments of the present disclosure.
  • FIG. 10 is a structural diagram of an apparatus for implementing CA mutual trust according to some embodiments of the present disclosure.
  • FIG. 11 is a schematic diagram of an apparatus for implementing CA mutual trust according to some embodiments of the present disclosure.
  • FIG. 12 is a schematic diagram of an electronic device of some embodiments of the present disclosure.
  • a method for implementing CA mutual trust is applied to a CA entity in a CA (Certificate Authority) mutual trust system.
  • the CA mutual trust system includes: at least three CA entities, each of which forms a point-to-point P2P network and forms a blockchain system; each CA entity stores a blockchain record for recording an operation record of the entity certificate.
  • the method includes steps 101-104.
  • Step 101 Assign a certificate to be issued to the certificate requester.
  • Step 102 Request, by using another CA entity in the system, a consensus on the to-be-issued entity certificate.
  • Step 103 If it is determined that the other CA entity has passed the consensus of the to-be-signed entity certificate, the certificate requesting party issues the to-be-issued entity certificate, and includes a blockchain authentication mark in the to-be-issued entity certificate. Where the blockchain authentication is marked as an identification of the blockchain system.
  • Step 104 Update the stored blockchain record.
  • each of the CA entities is respectively provided with a mutual trust agent, and each CA entity forms a P2P network through a correspondingly configured mutual trust agent and forms a blockchain system; the blockchain record is stored in the mutual trust agent.
  • the communication between the CA entities is completed by the mutual trust agent set by each CA entity.
  • the correlation processing of the certificate based on the blockchain authentication mark can be implemented, without complicated mesh cross-certification, and the bridging relationship is not required to be established by an authoritative intermediary with higher credibility. Fine-grained mutual trust control for each user's certificate granularity is achieved. Thus, utilizing the approach of some embodiments of the present disclosure, the flexibility to achieve CA mutual trust is increased.
  • a method for implementing CA mutual trust is applied to a CA entity in a CA mutual trust system;
  • the CA mutual trust system includes: at least three CA entities, each CA entity forming a point-to-point P2P
  • the network forms a blockchain system; each CA entity stores a blockchain record for recording an operation record of the entity certificate.
  • the method includes steps 201-203.
  • Step 201 Receive a certificate consensus request of the first CA entity.
  • Step 202 Build a consensus on the to-be-issued entity certificate of the first CA entity according to the certificate consensus request of the first CA entity, and include a blockchain authentication mark in the to-be-issued entity certificate, where the block The chain certification is marked as the identity of the blockchain system.
  • Step 203 If it is determined that the consensus of the entity to be issued is passed, the stored blockchain record is updated.
  • the first CA entity is any other CA entity in the CA mutual trust system.
  • the correlation processing of the certificate based on the blockchain authentication mark can be implemented, without complicated mesh cross-certification, and the bridging relationship is not required to be established by an authoritative intermediary with higher credibility. Fine-grained mutual trust control for each user's certificate granularity is achieved. Thus, utilizing the approach of some embodiments of the present disclosure, the flexibility to achieve CA mutual trust is increased.
  • the system for implementing CA mutual trust includes: at least three CA entities 301, each of which forms a point-to-point P2P network and forms a blockchain system; each CA entity stores a zone.
  • a blockchain record that records the operational record of an entity certificate.
  • the first CA entity of the at least three CA entities the certificate requester is allocated a certificate to be issued, and the second CA entity in the system is requested to obtain a consensus on the certificate to be issued; And the second CA entity passes the consensus of the to-be-issued entity certificate, and sends the to-be-issued entity certificate to the certificate requesting party, where the to-be-issued entity certificate includes a blockchain authentication mark, where the The blockchain authentication is marked as an identifier of the blockchain system, and the stored blockchain record is updated;
  • each of the CA entities is respectively provided with a mutual trust agent 302, and each CA entity forms a P2P network through a correspondingly configured mutual trust agent and forms a blockchain system; the blockchain record is stored in the mutual trust agent.
  • Each CA entity is a certificate authority in a traditional PKI system.
  • Each CA has a number of relying parties that use the CA's self-signed certificate as its own trust anchor. The number of CAs in this system should be more than three.
  • Each CA can have multiple secondary CAs. Each CA can issue several secondary CA certificates. Each secondary CA can issue several final entity certificates to form a certificate based on the CA self-signed certificate. chain. The length of a common certificate chain is generally 3, but it can be less than or more than 3.
  • the certificate entity (which can act as a certificate requester, certificate verification requester, etc.) is the owner of the final entity certificate whose identity authenticity is guaranteed by the CA for which the final entity certificate is issued.
  • the certificate relying party is the certifier of the final entity certificate.
  • Each certificate relying party can select one or more trusted CAs and use their self-signed certificate as their own trust anchor. Only the final entity certificate that can be linked to a trust anchor can be directly verified by the relying party. The final entity certificate that cannot be linked to the trust anchor can only be verified by the relying party through the CA mutual trust mechanism.
  • the certificate registration process of some embodiments of the present disclosure includes steps 401-407.
  • Step 401 The certificate entity 1 submits a certificate request request to the selected CA1.
  • the certificate entity 1 acts as a certificate requester, generates a public-private key pair locally, and writes the public key, identity information, and some auxiliary information into a CSR (Certificate Signing Request) request, and performs a CSR request with the private key. Signature, and finally send the signed CSR request to the registration authority (RA) specified by the CA.
  • CSR Chip Signing Request
  • Step 402 The CA1 authenticates the certificate entity 1 according to the agreement in the certificate policy (CP) and the authentication service statement (CPS), and saves the evidence of the identity authentication (ie, the identity authentication information of the certificate entity 1).
  • CP certificate policy
  • CPS authentication service statement
  • CA can use a variety of methods for identity authentication, such as requiring the applicant (certificate entity) to provide relevant supporting documents, or accepting telephone interviews, or clicking a link in a confirmation email, and so on.
  • the specific form adopted is stipulated by CPS.
  • Step 403 If the identity authentication is correct, the CA1 allocates an entity certificate to be issued to the certificate entity 1, and the entity certificate to be issued includes the blockchain authentication mark, and the entity certificate to be issued is sent by the mutual trust agent 1, And the evidence obtained during the identity authentication process (electronically processed) is sent to the mutual trust agent of other CAs in the blockchain system, requesting consensus on the new certificate.
  • the blockchain authentication mark may be an ID for distinguishing different blockchain systems, such as CA_alliance_cn, which is agreed by the blockchain system itself, and the mutual trust agent of the CA entity knows the ID when joining the blockchain system. .
  • This tag can exist as a certificate extension, so it does not cause incompatibility with traditional certificates. Relying parties that do not support the certificate extension can ignore the failure to process.
  • Step 404 After receiving the consensus request of the CA1, the mutual trust agent of the other CAs in the blockchain system determines whether to accept the identity authentication of the certificate entity 1 by CA1 according to a preset rule (for example, a smart contract written according to its own CP or CPS). Conclusion, and verify that the certificate issued by CA1 for certificate entity 1 is itself incorrect.
  • a preset rule for example, a smart contract written according to its own CP or CPS.
  • the blockchain system consists of a mutual trust agent that represents the root CA.
  • a root CA can have multiple secondary CAs with different CP/CPS and issue different types of certificates.
  • the mutual trust agent is responsible for the review of CP/CPS mapping and identity authentication evidence, which can be done with smart contracts.
  • Step 405 The mutual trust agents of all CAs in the blockchain system reach a collective resolution through some pre-agreed "consensus mechanism". If the consensus is successful, the new certificate is added to the blockchain, and a new "new certificate record" is generated in the blockchain system, which is saved by all CA's mutual trust agents. If the consensus fails, the new certificate is abandoned by the blockchain system. Only those certificates that have passed all CA consensus in the system are included in the blockchain, so it can be said that the solution of some embodiments of the present disclosure is a "per user certificate (per user certificate)" mutual trust scheme.
  • each CA may adopt includes but is not limited to: 1) Byzantine algorithm; 2) proof of workload; 3) proof of equity.
  • Figure 5 shows the structure of the blockchain.
  • the certificates generated within a certain time unit can be placed in the same block, for example, the time unit can be 24 hours.
  • Step 406 If the above-mentioned entity certificate to be issued that includes the blockchain authentication mark has a consensus in the blockchain system, the CA1 will notify the certificate entity 1 to download the certificate, or directly send the certificate to the certificate entity 1.
  • Step 407 If the consensus fails, the CA1 deletes the to-be-issued entity certificate that includes the blockchain authentication mark, and re-issues the entity certificate that does not include the blockchain authentication mark for the certificate entity 1, and notifies the certificate entity 1 to download the certificate. Or send the certificate directly to certificate entity 1.
  • the certificate is usually issued through one or more intermediate CAs.
  • the certificate of the intermediate CA may be included.
  • certificate entity 1 securely stores the received certificate with the corresponding private key for local backup.
  • the certificate update process of some embodiments of the present disclosure includes steps 601-605.
  • Step 601 The certificate entity 1 submits a certificate update request to the CA1.
  • the certificate update request submitted by certificate entity 1 refers to the certificate update request for the final entity certificate containing the blockchain authentication token.
  • Step 602 CA1 allocates a new certificate to be issued entity containing the blockchain authentication mark to the certificate entity 1, and sends the certificate and related auxiliary information to the mutual trust agent of other CAs in the blockchain system through the mutual trust agent 1, requesting A consensus is reached on updating the certificate.
  • Step 603 After receiving the consensus request of the CA1, the mutual trust agent of the other CAs in the blockchain system determines whether to accept the certificate update record according to a preset rule.
  • the mutual trust agents of all CAs in the blockchain system reach a collective resolution through a pre-agreed “consensus mechanism”.
  • Step 604 If the consensus is successful, the certificate update record is added to the blockchain, and a new "certificate update record" is generated, which is saved by all CA's mutual trust agents. The certificate update record is used to record that the original certificate of certificate entity 1 was updated. If the consensus fails, the update record of the certificate is abandoned by the blockchain system.
  • Step 605 If the certificate update record is successfully found in the blockchain system, the CA1 returns the new certificate to be issued to the certificate entity 1. If the consensus fails, CA1 deletes the above new pending certificate, and re-issues the final entity certificate that does not contain the blockchain authentication mark for certificate entity 1, and returns it to certificate entity 1. At the same time, CA1 initiates a certificate revocation process (described in detail below) to notify other CAs in the system to revoke old certificates in the blockchain.
  • a certificate revocation process described in detail below
  • certificate entity 1 securely stores the received certificate along with the corresponding private key for local backup.
  • the above certificate update process may be implemented independently or in combination with a certificate registration process.
  • the certificate revocation process of some embodiments of the present disclosure includes steps 701-704.
  • step 701 the certificate entity 1 submits a certificate revocation request (active revocation) to the CA1, or the CA1 unilaterally decides to revoke the certificate of the certificate entity 1 (passive revocation).
  • Step 702 The CA1 sends a certificate revocation request through the mutual trust agent 1, sends the certificate revocation record to the mutual trust agent of other CAs in the blockchain system, and requests to reach a consensus on the revocation certificate.
  • Step 703 After receiving the consensus request of the CA1, the mutual trust agent of the other CAs in the blockchain system determines whether to accept the certificate revocation record according to a preset rule.
  • certificate revocation requests In order to respond to security incidents such as private key compromises in a timely manner, certificate revocation requests should have the highest priority, so each CA in the system should set appropriate rules to ensure that revocation requests can quickly reach consensus.
  • Step 704 The mutual trust agents of all CAs in the blockchain system reach a collective resolution through a pre-agreed "consensus mechanism".
  • the certificate revocation record is appended to the blockchain after the consensus is successful.
  • the revocation record corresponding to the original entity certificate of the certificate entity 1 is added.
  • CA1 may add the revocation record corresponding to the original entity certificate of certificate entity 1 in its own certificate status record (which may be the same as or different from the blockchain).
  • the certificate query flow of some embodiments of the present disclosure includes steps 801-805.
  • Step 801 The certificate entity 1 establishes a communication relationship with the certificate relying party 1, and the certificate entity 1 presents its own final entity certificate (and possibly the certificate of the corresponding intermediate CA) to the certificate relying party 1, for example, for encrypted communication or digital signature.
  • Step 802 The certificate relying party 1 needs to verify whether the final entity certificate presented by the certificate entity 1 is authentic. Certificate relying party 1 attempts to rebuild the complete certificate chain of the certificate and finds that the root of the certificate chain is CA1, and CA1 is not the trust anchor of certificate relying party 1.
  • Step 803 The certificate relying party 1 sends a certificate verification request to the own trust anchor CA5, where the request carries the final entity certificate presented by the certificate entity 1.
  • Step 804 After receiving the certificate verification request, the CA5 performs verification. Among them, (1) and (2) are in no particular order.
  • CA5 queries all records of the final entity certificate in the blockchain through the mutual trust agent 5, including adding, updating, revoking, and the like.
  • the mutual trust agent 5 judges whether the certificate has been recognized by itself according to the result of the inquiry, and whether it is still valid. This judgment process can be completed only by the queried record, and there is no need to rebuild and verify the entire certificate chain. At the same time, the second verification result is obtained.
  • Step 805 The CA5 sends the verification result to the certificate relying party 1.
  • CA5 returns a response to the certificate relying party 1 that "cannot be verified". If there is only one way to complete the certificate verification, or both methods can complete the verification and the verification result is consistent, then directly return any one or two verification results to the certificate relying party 1. If both methods can be verified but the verification results are inconsistent, the method with higher priority is taken according to the rules pre-determined by CA5, and the verification result is returned to the certificate relying party 1.
  • the certificate relying party 1 receives the verification result from CA5, and decides whether to continue the communication process with the certificate entity 1 according to the verification result (such as establishing an encrypted communication relationship, or verifying the digital signature of the certificate entity 1).
  • CA in the system eliminates the need for complex cross-certification and does not require another, more credible organization to build a bridge CA.
  • the granular mutual trust control of the per-user certificate granularity can be realized, that is, other CAs do not need to trust all the final entity certificates issued by CA1, and they can choose to trust only the certificates that can reach consensus in the blockchain (including the blockchain authentication mark). Certificate). It should be noted that, in practical applications, the above several processes may be used in combination or separately.
  • the correlation processing of the certificate based on the blockchain authentication mark can be implemented, without complicated mesh cross-certification, and the bridging relationship is not required to be established by an authoritative intermediary with higher credibility. Fine-grained mutual trust control for each user's certificate granularity is achieved. Thus, utilizing the approach of some embodiments of the present disclosure, the flexibility to achieve CA mutual trust is increased.
  • an apparatus for implementing CA mutual trust is applied to a CA entity in a CA mutual trust system;
  • the CA mutual trust system includes: at least three CA entities, each CA entity forming a point-to-point P2P Networking and forming a blockchain system; each of the CA entities stores a blockchain record for recording an operation record of the entity certificate;
  • the device includes: an allocating module 901, configured to allocate a certificate to be issued to the certificate requester;
  • the requesting module 902 is configured to request, by the other CA entities in the system, a consensus on the to-be-signed entity certificate, and the issuing module 903 is configured to: if it is determined that the other CA entity has passed the consensus of the to-be-issued entity certificate, And sending, to the certificate requesting party, the to-be-issued entity certificate, where the to-be-issued entity certificate includes a blockchain authentication mark, wherein the blockchain authentication mark is an identifier of the blockchain system; and updating Module 904 is configured to update the stored blockchain
  • the apparatus further includes: a mutual trust agent module 905, configured to form the device for implementing CA mutual trust with other CA entities into a P2P network and form a blockchain system; the blockchain record is stored in the In the mutual trust agent module.
  • a mutual trust agent module 905 configured to form the device for implementing CA mutual trust with other CA entities into a P2P network and form a blockchain system; the blockchain record is stored in the In the mutual trust agent module.
  • the distribution module 901 includes: a receiving submodule, configured to receive a certificate request request of the certificate requester; and an identity authentication submodule, configured to perform identity authentication on the certificate requester according to the certificate request request, and obtain The identity requesting information of the certificate requesting party; the assigning submodule, configured to allocate the to-be-issued entity certificate to the certificate requesting party after the identity authentication of the certificate requesting party is passed.
  • the requesting module 902 is specifically configured to request, by using a corresponding mutual trust agent module, a mutual trust agent module corresponding to another CA entity in the system to perform a consensus on the to-be-issued entity certificate; And, if it is determined that the mutual trust agent module corresponding to the other CA entity passes the consensus of the to-be-issued entity certificate, the certificate requester is issued the certificate to be issued; the update module 904 is specifically used to In the blockchain record, the new record corresponding to the certificate to be issued is added.
  • the requesting module 902 is specifically configured to send, by using a corresponding mutual trust agent module, the to-be-signed entity certificate, the certificate requesting party, to a mutual trust agent module corresponding to another CA entity in the system.
  • the identity authentication information is used to request a consensus on the certificate to be issued.
  • the CA mutual trust system further includes: an intermediate CA entity corresponding to each CA entity; the signing module is specifically configured to issue, by the intermediate CA entity, the certificate to be issued to the certificate requesting party.
  • the device further includes: a deleting module 906, configured to: if it is determined that the other CA entity does not pass the consensus of the to-be-issued entity certificate, delete the to-be-issued entity certificate, and The certificate requesting party issues a final entity certificate, wherein the block entity authentication flag is not included in the final entity certificate; and the first receiving module 907 is configured to receive the certificate requesting party certificate update request.
  • a deleting module 906 configured to: if it is determined that the other CA entity does not pass the consensus of the to-be-issued entity certificate, delete the to-be-issued entity certificate, and The certificate requesting party issues a final entity certificate, wherein the block entity authentication flag is not included in the final entity certificate
  • the first receiving module 907 is configured to receive the certificate requesting party certificate update request.
  • the allocating module 901 is specifically configured to: allocate, according to the certificate update request, a new certificate to be issued to the certificate requesting party; the requesting module 902 is specifically configured to: through the correspondingly configured mutual trust agent module, And requesting the mutual trust agent module corresponding to the other CA entity in the system to perform a consensus on the new certificate to be issued; the signing module 903 is specifically configured to determine, if the other CA entity corresponds to the mutual agent module And the new certificate to be issued is issued by the certificate requester, and the new certificate to be issued is sent to the certificate requester.
  • the update module 904 is specifically configured to add the certificate in the blockchain record. The update record corresponding to the original entity certificate of the requesting party.
  • the apparatus further includes: a notification module 908, configured to notify the other CA entity to revoke the original entity certificate of the certificate requester.
  • the notification module 908 is specifically configured to send, by using the mutual trust agent module, a certificate revocation request to the mutual trust agent module corresponding to the other CA entity, requesting to revoke the original entity certificate of the certificate requesting party;
  • the module 904 is specifically configured to: in the blockchain record, add a revocation record corresponding to the original entity certificate.
  • the device further includes: a second receiving module 909, configured to receive a certificate verification request of the certificate verification requesting party, where the certificate verification request includes an entity certificate to be verified; and the first verification module 910, And determining, by using the to-be-verified entity certificate, the root CA entity, and performing verification on the verification of the to-be-verified entity certificate to obtain a first verification result;
  • the first determining module 911 is configured to determine the Whether the blockchain authentication mark is included in the to-be-verified entity certificate
  • the second verification module 912 is configured to: if the blockchain authentication mark is included, use the corresponding mutual trust agent module and the blockchain authentication mark to search for the stored a blockchain record, determining, by the lookup, whether the verification of the entity certificate to be verified is performed, and obtaining a second verification result;
  • the result sending module 913 configured to: according to the first verification result and the second verification result, The certificate verification requester sends the final verification result.
  • the result sending module 913 is specifically configured to: if the first verification result and the second verification result both indicate that the verification of the to-be-verified entity certificate is performed, send the a first verification result and/or the second verification result; if the first verification result and the second verification result are inconsistent, selecting information according to the set verification result, and selecting a verification result with a higher priority as a final Verify the result and send the final verification result to the certificate verification requester.
  • the related processing of the certificate based on the blockchain authentication mark can be implemented, and the complex network cross-certification is not required, and the bridging relationship of each user certificate can be realized without relying on the authoritative intermediary with higher credibility to establish the bridging relationship. Fine mutual trust control.
  • Fine mutual trust control utilizing the approach of some embodiments of the present disclosure, the flexibility to achieve CA mutual trust is increased.
  • an apparatus for implementing CA mutual trust is applied to a CA entity in a CA mutual trust system;
  • the CA mutual trust system includes: at least three CA entities, each CA entity forming a point-to-point P2P
  • the network forms a blockchain system; each CA entity stores a blockchain record for recording an operation record of the entity certificate;
  • the device includes:
  • the receiving module 1101 is configured to receive a certificate consensus request of the first CA entity
  • the consensus module 1102 is configured to: perform a consensus on the to-be-issued entity certificate of the first CA entity according to the certificate consensus request of the first CA entity, where
  • the block issuing entity certificate includes a blockchain authentication mark, wherein the blockchain authentication mark is an identifier of the blockchain system
  • an update module 1103 is configured to: if it is determined that the authentication of the to-be-issued entity certificate is passed, The stored blockchain record is updated.
  • the update module 1103 is specifically configured to: in the blockchain record, add a new record corresponding to the to-be-issued entity certificate.
  • the update module 1103 is specifically configured to: when there is an entity certificate update, add an update record corresponding to the updated entity certificate in the blockchain record.
  • the receiving module 1101 is further configured to: receive a certificate revocation request of the first CA entity, determine, according to the certificate revocation request, whether to pass the certificate revocation request; the update module 1103 is specifically used to When the certificate revocation request is described, in the blockchain record, the revocation record corresponding to the revoked entity certificate is added.
  • the related processing of the certificate based on the blockchain authentication mark can be implemented, and the complex network cross-certification is not required, and the bridging relationship of each user certificate can be realized without relying on the authoritative intermediary with higher credibility to establish the bridging relationship. Fine mutual trust control.
  • Fine mutual trust control utilizing the approach of some embodiments of the present disclosure, the flexibility to achieve CA mutual trust is increased.
  • An electronic device of some embodiments of the present disclosure includes a processor 1201 and a memory 1202 for storing a computer program. Wherein, when the processor 1201 invokes and executes the computer program stored on the memory 1202, the processor 1201 implements a method of implementing CA mutual trust as in any of the foregoing embodiments.
  • a computer readable storage medium of some embodiments of the present disclosure is for storing a computer program, wherein the computer program is executable by a processor to perform a CA mutual trust method as in any of the foregoing embodiments.
  • the disclosed method and apparatus may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.
  • each functional unit in various embodiments of the present disclosure may be integrated into one processing unit, or each unit may be physically included separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of hardware plus software functional units.
  • the above-described integrated unit implemented in the form of a software functional unit can be stored in a computer readable storage medium.
  • the above software functional unit is stored in a storage medium and includes a plurality of instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform part of the steps of the transceiving method of the various embodiments of the present disclosure.
  • the foregoing storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a volatile or non-volatile random access memory (RAM), a disk or A variety of media such as optical discs that can store program code.

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)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本公开提供一种实现CA互信的方法、装置、系统和电子设备。本公开的实现CA互信的方法包括：为证书请求方分配待签发实体证书；向系统中的其他CA实体请求对待签发实体证书进行共识；若确定其他CA实体对待签发实体证书的认证通过，则向证书请求方签发待签发实体证书，在待签发实体证书中包括区块链认证标记，其中区块链认证标记为区块链系统的标识；更新存储的区块链记录。

Description

实现CA互信的方法、装置、系统和电子设备
相关申请的交叉引用
本申请主张在2017年4月6日在中国提交的中国专利申请号No.201710220298.0的优先权，其全部内容通过引用包含于此。
技术领域
本公开涉及通信技术领域，尤其涉及一种实现CA互信的方法、装置、系统和电子设备。
背景技术
PKI(Public Key Infrastructure，公钥基础设施)在信息安全领域扮演着非常重要的角色。无论是使用HTTPS((Hyper Text Transfer Protocol over Secure Socket Layer，超文本传输协议安全)访问安全的网站，还是在数字商务/政务/办公领域经常用到的电子签名，都必须有PKI的支撑。
PKI的依赖方在验证对方证书时，需要构建相应的证书认证路径，而在路径中必须有一个信任起点，即信任锚。信任锚通常是被依赖方信任的CA(Certificate Authority，证书权威)的自签名证书。依赖方的信任锚数量通常是有限的。当对方证书对应的CA自签名证书不在依赖方的信任锚范围内时，依赖方就无法构建一个可信的证书认证路径，也就无法完成基于证书的保密通信或签名认证等操作。这就引出了CA互信的问题。
在PKI实践中，解决CA互信问题的方法一般有如下三种：列表方案：常见的权威列表有中华人民共和国工信部《电子认证服务许可证》列表、微软公司Root Certificate Program维护的列表(也就是预置在Windows操作系统和IE浏览器中的CA列表)、以及北美WebTrust认证的列表等；CA交叉认证方案(网状结构)：一个CA通过为其他CA签发证书的方式，使得信任自己的依赖方能与其他CA的证书持有者达成互信；以及，桥CA方案(星型结构)：引入桥CA作为其他CA互信的中介，两个CA分别与桥CA双向交叉认证后，这两个CA之间也达成了互信。
但是，在实现本公开的过程中发明人发现列表方案对依赖方有较高要求(有专业的判断能力、能够合理配置自己的信任锚)，且权威列表本身的维护代价较高。CA交叉认证方案类似现实生活中集团平等合作的信任关系。当CA数量较少时可以很好地解决CA互信问题，但大量CA两两进行交叉认证时，就会形成复杂的网状结构，使证书认证路径变长甚至形成环路，而且证书策略(CP)经过多次映射之后会使证书用途大大受限。桥CA方案类似现实生活中行业协会中介的信任关系，CA数量较多时可以避免两两交叉认证的弊端，但桥CA运营方的选择是个难题，它的可信程度直接决定了互信关系的可靠程度。
发明内容
有鉴于此，本公开提供一种实现CA互信的方法、装置、系统和电子设备，以提高实现CA互信的灵活性。
为解决上述技术问题，在第一方面，本公开提供一种实现CA互信的方法，该方法应用于CA互信系统中的CA实体。所述CA互信系统包括至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统，各CA实体中存储有区块链记录，区块链记录用于记录对实体证书的操作记录。所述方法包括：为证书请求方分配待签发实体证书；向所述系统中的其他CA实体请求对所述待签发实体证书进行共识；若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；以及更新存储的区块链记录。
其中，所述各CA实体分别对应设置有互信代理，各CA实体通过对应设置的互信代理组成P2P网络并形成区块链系统；所述区块链记录存储在所述互信代理中。
其中，所述为证书请求方分配待签发实体证书，包括：接收所述证书请求方的证书申请请求；根据所述证书申请请求对所述证书请求方进行身份鉴别，获得所述证书请求方的身份鉴别信息；以及当对所述证书请求方的身份鉴别通过后，为所述证书请求方分配所述待签发实体证书。
其中，所述向所述系统中的其他CA实体请求对所述待签发实体证书进行共识，包括：通过对应设置的互信代理，向所述系统中其他CA实体对应的互信代理模块请求对所述待签发实体证书进行共识；所述若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，包括：若确定所述其他CA实体对应的互信代理模块对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书；并且所述更新存储的区块链记录，包括：在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
其中，所述通过对应设置的互信代理，向所述系统中其他CA实体对应的互信代理模块请求对所述待签发实体证书进行共识，包括：通过对应设置的互信代理，向所述系统中其他CA实体对应的互信代理模块发送所述待签发实体证书、所述证书请求方的身份鉴别信息，以请求对所述待签发实体证书进行共识。
其中，所述CA互信系统还包括：各CA实体对应的中间CA实体；所述向所述证书请求方签发所述待签发实体证书，包括：通过所述中间CA实体向所述证书请求方签发所述待签发实体证书。
其中，所述方法还包括：若确定所述其他CA实体对所述待签发实体证书的共识未通过，则删除所述待签发实体证书，并向所述证书请求方签发最终实体证书，其中所述最终实体证书中不包括所述区块链认证标记。
其中，在所述为证书请求方分配待签发实体证书的步骤之前，所述方法还包括：接收所述证书请求方的证书更新请求；所述为证书请求方分配待签发实体证书，包括：根据所述证书更新请求，为所述证书请求方分配新的待签发实体证书；所述向所述系统中的其他CA实体请求对所述待签发实体证书进行共识，包括：通过对应设置的互信代理，向所述系统中的其他CA实体对应的互信代理请求对所述新的待签发实体证书进行共识；所述若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，包括：所述若确定所述其他CA实体对应的互信代理对所述新的待签发实体证书的共识通过，则向所述证书请求方签发所述新的待签发实体证书；并且所述更新存储的区块链记录，包括：在所述区块链 记录中，增加所述证书请求方的原实体证书对应的更新记录。
其中，所述方法还包括：通知所述其他CA实体吊销所述证书请求方的原实体证书。
其中，所述通知所述其他CA实体吊销所述证书请求方的原实体证书，包括：通过对应设置的互信代理，向所述其他CA实体对应的互信代理发送证书吊销请求，请求吊销所述证书请求方的原实体证书；并且所述更新存储的区块链记录，包括：在所述区块链记录中，增加所述原实体证书对应的吊销记录。
其中，所述方法还包括：接收证书验证请求方的证书验证请求，在所述证书验证请求中包括待验证实体证书；根据所述待验证实体证书确定根CA实体，并与所述根CA实体交互完成对所述待验证实体证书的验证，获得第一验证结果；确定所述待验证实体证书中是否包含区块链认证标记；若包含所述区块链认证标记，则利用对应设置的互信代理和所述区块链认证标记查找存储的区块链记录，根据查找确定是否通过对所述待验证实体证书的验证，获得第二验证结果；以及，根据所述第一验证结果和所述第二验证结果，向所述证书验证请求方发送最终的验证结果。
其中，所述根据所述第一验证结果和所述第二验证结果，向所述证书验证请求方发送最终的验证结果，包括：若所述第一验证结果和所述第二验证结果均表示通过对所述待验证实体证书的验证，则向所述证书验证请求方发送所述第一验证结果和/或所述第二验证结果；以及若所述第一验证结果和所述第二验证结果不一致，则根据设置的验证结果选择信息，选择优先级较高的验证结果作为最终的验证结果，并向所述证书验证请求方发送所述最终的验证结果。
在第二方面，本公开的一些实施例提供了一种实现CA互信的方法，该方法应用于CA互信系统中的CA实体，所述CA互信系统包括至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统，各CA实体中存储有区块链记录，区块链记录用于记录对实体证书的操作记录。所述方法包括：接收第一CA实体的证书共识请求；根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，所述待签发实体证 书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；以及若确定对所述待签发实体证书的共识通过，则更新存储的区块链记录。
其中，所述更新存储的区块链记录，包括：在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
其中，所述更新存储的区块链记录，还包括：当有实体证书更新时，在所述区块链记录中，增加对进行更新的实体证书对应的更新记录。
其中，所述方法还包括：接收所述第一CA实体的证书吊销请求，根据所述证书吊销请求确定是否通过所述证书吊销请求；并且所述更新存储的区块链记录，包括：当通过所述证书吊销请求时，在所述区块链记录中，增加被吊销的实体证书对应的吊销记录。
第三方面，本公开的一些实施例提供了一种实现CA互信的装置，该装置应用于CA互信系统中的CA实体，所述CA互信系统包括至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统；各CA实体中存储有区块链记录，区块链记录用于记录对实体证书的操作记录。所述装置包括：分配模块，用于为证书请求方分配待签发实体证书；请求模块，用于向所述系统中的其他CA实体请求对所述待签发实体证书进行共识；签发模块，用于若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；以及更新模块，用于更新存储的区块链记录。
其中，所述装置还包括：互信代理模块，用于将所述实现CA互信的装置与其他CA实体组成P2P网络并形成区块链系统；所述区块链记录存储在所述互信代理模块中。
其中，所述分配模块包括：接收子模块，用于接收所述证书请求方的证书申请请求；身份鉴别子模块，用于根据所述证书申请请求对所述证书请求方进行身份鉴别，获得所述证书请求方的身份鉴别信息；以及分配子模块，用于当对所述证书请求方的身份鉴别通过后，为所述证书请求方分配所述待签发实体证书。
其中，所述请求模块具体用于，通过对应设置的互信代理模块，向所述系统中其他CA实体对应的互信代理模块请求对所述待签发实体证书进行共识；所述签发模块具体用于，若确定所述其他CA实体对应的互信代理模块对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书；并且所述更新模块具体用于，在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
其中，所述请求模块具体用于，通过对应设置的互信代理模块，向所述系统中其他CA实体对应的互信代理模块发送所述待签发实体证书、所述证书请求方的身份鉴别信息，以请求对所述待签发实体证书进行共识。
其中，所述CA互信系统还包括：各CA实体对应的中间CA实体；并且所述签发模块具体用于，通过所述中间CA实体向所述证书请求方签发所述待签发实体证书。
其中，所述装置还包括：删除模块，用于若确定所述其他CA实体对所述待签发实体证书的共识未通过，则删除所述待签发实体证书，并向所述证书请求方签发最终实体证书，其中所述最终实体证书中不包括所述区块链认证标记。
其中，所述装置还包括：第一接收模块，用于接收所述证书请求方的证书更新请求；所述分配模块具体用于，根据所述证书更新请求，为所述证书请求方分配新的待签发实体证书；所述请求模块具体用于，通过对应设置的互信代理模块，向所述系统中的其他CA实体对应的互信代理模块请求对所述新的待签发实体证书进行共识；所述签发模块具体用于，若确定所述其他CA实体对应的互信代理模块对所述新的待签发实体证书的共识通过，则向所述证书请求方签发所述新的待签发实体证书；并且所述更新模块具体用于，在所述区块链记录中，增加所述证书请求方的原实体证书对应的更新记录。
其中，所述装置还包括：通知模块，用于通知所述其他CA实体吊销所述证书请求方的原实体证书。
其中，所述通知模块具体用于，通过所述互信代理模块，向所述其他CA实体对应的互信代理模块发送证书吊销请求，请求吊销所述证书请求方的原实体证书；并且所述更新模块具体用于，在所述区块链记录中，增加所述原 实体证书对应的吊销记录。
其中，所述装置还包括：第二接收模块，用于接收证书验证请求方的证书验证请求，在所述证书验证请求中包括待验证实体证书；第一验证模块，用于根据所述待验证实体证书确定根CA实体，并与所述根CA实体交互完成对所述待验证实体证书的验证，获得第一验证结果；第一确定模块，用于确定所述待验证实体证书中是否包含区块链认证标记；第二验证模块，用于若包含所述区块链认证标记，则利用对应设置的互信代理模块和所述区块链认证标记查找存储的区块链记录，根据查找确定是否通过对所述待验证实体证书的验证，获得第二验证结果；以及结果发送模块，用于根据所述第一验证结果和所述第二验证结果，向所述证书验证请求方发送最终的验证结果。
其中，所述结果发送模块具体用于，若所述第一验证结果和所述第二验证结果均表示通过对所述待验证实体证书的验证，则向所述证书验证请求方发送所述第一验证结果和/或所述第二验证结果；以及若所述第一验证结果和所述第二验证结果不一致，则根据设置的验证结果选择信息，选择优先级较高的验证结果作为最终的验证结果，并向所述证书验证请求方发送所述最终的验证结果。
第四方面，本公开的一些实施例提供了一种实现CA互信的装置，该装置应用于CA互信系统中的CA实体，所述CA互信系统包括至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统，各CA实体中存储有区块链记录，区块链记录用于记录对实体证书的操作记录。所述装置包括：接收模块，用于接收第一CA实体的证书共识请求；共识模块，用于根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；以及更新模块，用于若确定对所述待签发实体证书的共识通过，则更新存储的区块链记录。
其中，所述更新模块具体用于，在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
其中，所述更新模块具体用于，当有实体证书更新时，在所述区块链记录中，增加对进行更新的实体证书对应的更新记录。
其中，所述接收模块还用于，接收所述第一CA实体的证书吊销请求，根据所述证书吊销请求确定是否通过所述证书吊销请求；并且所述更新模块具体用于，当通过所述证书吊销请求时，在所述区块链记录中，增加被吊销的实体证书对应的吊销记录。
第五方面，本公开的一些实施例提供了一种实现CA互信的系统，包括：至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统；各CA实体中存储有区块链记录，用于记录对实体证书的操作记录；其中，所述至少三个CA实体中的第一CA实体，为证书请求方分配待签发实体证书，并向所述系统中的第二CA实体请求对所述待签发实体证书进行共识；若确定所述第二CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识，并更新存储的区块链记录；并且所述至少三个CA实体中的第二CA实体，接收所述第一CA实体的证书共识请求，并根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，若确定对所述待签发实体证书的共识通过，则更新存储的区块链记录。
其中，所述各CA实体分别对应设置有互信代理，各CA实体通过对应设置的互信代理组成P2P网络并形成区块链系统；所述区块链记录存储在所述互信代理中。
第六方面，本公开的一些实施例提供了一种电子设备，包括：处理器，存储器，用于存储计算机程序；其中，所述处理器在调用并执行所述存储器上存储的计算机程序时，所述处理器实现如前述第一方面所述的实现证书权威CA互信的方法。
第七方面，本公开的一些实施例提供了一种计算机可读存储介质，包括在所述计算机可读存储介质上存储的计算机程序，其中，当所述计算机程序被处理器执行时，所述处理器执行如前述第一方面所述的实现证书权威CA互信的方法。
第八方面，本公开的一些实施例提供了一种电子设备，包括处理器，存储器，用于存储计算机程序；其中，所述处理器在调用并执行所述存储器上 存储的计算机程序时，所述处理器实现如前述第二方面所述的实现证书权威CA互信的方法。
第九方面，本公开的一些实施例提供了一种计算机可读存储介质，包括在所述计算机可读存储介质上存储的计算机程序，其中，当所述计算机程序被处理器执行时，所述处理器执行如前述第二方面所述的实现证书权威CA互信的方法。
本公开的上述技术方案的有益效果如下：
在本公开的一些实施例中，在区块链系统中，可实现基于区块链认证标记进行证书的相关处理，无需复杂的网状交叉认证，无需依靠公信力更高的权威中介建立桥接关系，即可实现每个用户证书粒度的精细互信控制。因此，利用本公开的一些实施例的方案，提高了实现CA互信的灵活性。
附图说明
图1为本公开的一些实施例的实现CA互信的方法的流程图；
图2为本公开的一些实施例的实现CA互信的方法的流程图；
图3为本公开的一些实施例的实现CA互信的系统的示意图；
图4为本公开的一些实施例的证书注册流程的流程图；
图5为本公开的一些实施例的区块链的结构示意图；
图6为本公开的一些实施例的证书更新流程的流程图；
图7为本公开的一些实施例的证书吊销流程的流程图；
图8为本公开的一些实施例的证书查询流程的流程图；
图9为本公开的一些实施例的实现CA互信的装置的示意图；
图10为本公开的一些实施例的实现CA互信的装置的结构图；
图11为本公开的一些实施例的实现CA互信的装置的示意图；以及
图12为本公开的一些实施例的电子设备的示意图。
具体实施方式
下面将结合附图和实施例，对本公开的具体实施方式作进一步详细描述。以下实施例用于说明本公开，但不用来限制本公开的范围。
如图1所示，本公开的一些实施例的实现CA互信的方法，应用于CA(Certificate Authority，证书权威)互信系统中的CA实体。所述CA互信系统包括：至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统；各CA实体中存储有区块链记录，用于记录对实体证书的操作记录。所述方法包括步骤101-104。
步骤101、为证书请求方分配待签发实体证书。
步骤102、向所述系统中的其他CA实体请求对所述待签发实体证书进行共识。
步骤103、若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识。
步骤104、更新存储的区块链记录。
在实际应用中，所述各CA实体分别对应设置有互信代理，各CA实体通过对应设置的互信代理组成P2P网络并形成区块链系统；所述区块链记录存储在所述互信代理中。而各CA实体之间的通信，是通过各CA实体对应设置的互信代理完成的。
在本公开的一些实施例中，在区块链系统中，可实现基于区块链认证标记进行证书的相关处理，无需复杂的网状交叉认证，无需依靠公信力更高的权威中介建立桥接关系，即可实现每用户证书粒度的精细互信控制。因此，利用本公开的一些实施例的方案，提高了实现CA互信的灵活性。
如图2所示，本公开的一些实施例的实现CA互信的方法，应用于CA互信系统中的CA实体；所述CA互信系统包括：至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统；各CA实体中存储有区块链记录，用于记录对实体证书的操作记录。所述方法包括步骤201-203。
步骤201、接收第一CA实体的证书共识请求。
步骤202、根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识。
步骤203、若确定对所述待签发实体证书的共识通过，则更新存储的区 块链记录。
其中，所述第一CA实体为CA互信系统中其他的任意一个CA实体。
在本公开的一些实施例中，在区块链系统中，可实现基于区块链认证标记进行证书的相关处理，无需复杂的网状交叉认证，无需依靠公信力更高的权威中介建立桥接关系，即可实现每用户证书粒度的精细互信控制。因此，利用本公开的一些实施例的方案，提高了实现CA互信的灵活性。
如图3所示，本公开的一些实施例的实现CA互信的系统包括：至少三个CA实体301，各CA实体组成点到点P2P网络并形成区块链系统；各CA实体中存储有区块链记录，用于记录对实体证书的操作记录。
其中，所述至少三个CA实体中的第一CA实体，为证书请求方分配待签发实体证书，并向所述系统中的第二CA实体请求对所述待签发实体证书进行共识；若确定所述第二CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识，并更新存储的区块链记录；
所述至少三个CA实体中的第二CA实体，接收所述第一CA实体的证书共识请求，并根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，若确定对所述待签发实体证书的共识通过，则更新存储的区块链记录。
在实际应用中，所述各CA实体分别对应设置有互信代理302，各CA实体通过对应设置的互信代理组成P2P网络并形成区块链系统；所述区块链记录存储在所述互信代理中。
每个CA实体为传统PKI系统中的证书权威。每个CA拥有一定数量的依赖方，这些依赖方将该CA的自签名证书作为自己的信任锚。该系统中CA的数量应为3个以上。其中，每个CA可有多个二级CA，每个CA可以签发若干个二级CA证书，每个二级CA又可以签发若干个最终实体证书，从而构成以CA自签名证书为根的证书链。常见的证书链长度一般是3级，但也可以少于或多于3级。
在图3中，证书实体(可作为证书请求方、证书验证请求方等角色)为 最终实体证书的拥有者，其身份真实性由为其颁发最终实体证书的CA担保。证书依赖方为最终实体证书的验证者。每个证书依赖方可以选择一个或多个信任的CA，并将其自签名证书作为自己的信任锚。只有能够链接到某个信任锚的最终实体证书，才可以被依赖方直接验证。无法链接到信任锚的最终实体证书，只能通过CA互信机制才可被依赖方验证。
以下，结合不同的过程来描述一下本公开的一些实施例的实现过程，包括：1)证书注册流程；2)证书更新流程；3)证书吊销流程；4)证书使用查询流程。
如图4所示，本公开的一些实施例的证书注册流程包括步骤401-407。
步骤401、证书实体1向选定的CA1提交证书申请请求。
在此，证书实体1作为证书请求方，在本地生成公私钥对，并将公钥、身份信息及一些辅助信息写入CSR(Certificate Signing Request，证书签名请求)请求，并用私钥对CSR请求进行签名，最后将带有签名的CSR请求发送给CA指定的注册权威(RA)。
步骤402、CA1根据证书策略(CP)和认证业务声明(CPS)中的约定，对证书实体1进行身份鉴别，并保存身份鉴别的证据(即证书实体1的身份鉴别信息)。
其中，CA在进行身份鉴别时可以采用很多种方法，如要求申请者(证书实体)提供相关证明文件、或接受电话访谈、或点击一封确认邮件中的某个链接等等。具体采用何种形式，由CPS来约定。
步骤403、若身份鉴别无误，则CA1为证书实体1分配一个待签发的实体证书，该待签发的实体证书中包含了区块链认证标记，并通过互信代理1将上述待签发的实体证书、以及在身份鉴别过程中获取的证据(经过电子化处理)一并发给区块链系统中其它CA的互信代理，请求对该新增证书达成共识。
其中，区块链认证标记可以是用于区分不同区块链系统的一个ID，形如CA_alliance_cn，由区块链系统自己约定，CA实体的互信代理在加入区块链系统的时候会获知这个ID。这个标记可以作为一个证书扩展项存在，因此不会造成与传统证书的不兼容，不支持该证书扩展项的依赖方可以忽略不予处 理。
步骤404、区块链系统中其它CA的互信代理收到CA1的共识请求后，根据预先设定的规则(例如根据自己CP、CPS编写的智能合约)判断是否接受CA1对证书实体1的身份鉴别结论、以及验证CA1为证书实体1签发的证书本身是否有误。
在本公开的一些实施例的系统中，区块链系统由代表根CA的互信代理组成。一个根CA下面可以有CP/CPS互异的多个二级CA，并分别签发不同类型的证书。互信代理负责进行CP/CPS映射和身份鉴别证据的审查，这个过程可以用智能合约来完成。
步骤405、区块链系统中所有CA的互信代理通过某种预先约定的“共识机制”达成集体决议。若共识成功，则该新增证书被追加到区块链中，并在区块链系统中生成一条新的“新增证书记录”，被所有CA的互信代理保存。若共识失败，则该新增证书被区块链系统放弃。只有通过了系统中所有CA共识的那些证书才被区块链包含，所以可以说本公开的一些实施例的方案是一个“per用户证书(每个用户证书)”的互信方案。
其中，各CA可能采用的区块链“共识机制”包括但不限于：1)拜占庭算法；2)工作量证明；3)权益证明等。
如图5所示为区块链的结构示意图。为了方便证书查询，在一定时间单位内生成的证书可放入同一区块，例如可以24小时为时间单位。
步骤406、若上述包含了区块链认证标记的待签发实体证书在区块链系统中共识成功，则CA1将通知证书实体1下载该证书，或者直接将该证书发送给证书实体1。
步骤407、若共识失败，则CA1删除上述包含了区块链认证标记的待签发实体证书，重新为证书实体1签发不包含区块链认证标记的实体证书，并通知证书实体1下载该证书，或者直接将该证书发送给证书实体1。
其中，为保护CA1的自签名证书私钥，通常通过1个或多个中间CA进行证书的签发。最终下载或发送实体证书时，除了CA1签发的证书之外，还可能包括中间CA的证书。
最后，证书实体1将收到的证书与对应的私钥一起安全存储在本地备用。
如图6所示，本公开的一些实施例的证书更新流程包括步骤601-605。
步骤601、证书实体1向CA1提交证书更新请求。
其中，证书实体1需要生成新的公私钥对。证书实体1所提交的证书更新请求，指的是针对包含了区块链认证标记的最终实体证书的证书更新请求。
步骤602、CA1为证书实体1分配新的包含了区块链认证标记的待签发实体证书，并通过互信代理1将上述证书及相关辅助信息发给区块链系统中其它CA的互信代理，请求对更新证书达成共识。
步骤603、区块链系统中其它CA的互信代理收到CA1的共识请求后，根据预先设定的规则判断是否接受这条证书更新记录。
区块链系统中所有CA的互信代理通过预先约定的“共识机制”达成集体决议。
步骤604、若共识成功，则该证书更新记录被追加到区块链中，生成一条新的“证书更新记录”，被所有CA的互信代理保存。该证书更新记录用于记录证书实体1的原有证书被更新。若共识失败，则该证书的更新记录被区块链系统放弃。
步骤605、若上述证书更新记录在区块链系统中共识成功，则CA1将该新的待签发证书返回给证书实体1。若共识失败，则CA1删除上述新的待签发证书，重新为证书实体1签发不包含区块链认证标记的最终实体证书，并将其返回给证书实体1。同时，CA1发起一次证书吊销流程(下文详细描述)，通知系统中其它CA将区块链中的旧证书吊销。
在上述过程中，系统中存在两种不同的最终实体证书，一种包含区块链认证标记，另一种不包含区块链认证标记。这是为了实现“per用户证书”的互信。如果区块链中的其他CA不认同CA1提供的身份鉴别结果(根据鉴别证据和各自的CP/CPS来判断)，这个证书就不能写入区块链。
最后，证书实体1将收到的证书与对应的私钥一起，安全存储在本地备用。
其中，上述证书更新过程可以独立实现，也可结合证书注册过程实现。
如图7所示，本公开的一些实施例的证书吊销流程包括步骤701-704。
步骤701、证书实体1向CA1提交证书吊销申请(主动吊销)，或CA1 单方面决定吊销证书实体1的证书(被动吊销)。
此处仅考虑包含了区块链认证标记的最终实体证书。
步骤702、CA1通过互信代理1发送证书吊销请求，将证书吊销记录发给区块链系统中其它CA的互信代理，请求对吊销证书达成共识。
步骤703、区块链系统中其它CA的互信代理收到CA1的共识请求后，根据预先设定的规则判断是否接受这条证书吊销记录。
为了及时应对私钥泄露等安全事件，证书吊销请求应具有最高优先级，因此系统中的每个CA应设定适当的规则，确保吊销请求能够快速达成共识。
步骤704、区块链系统中所有CA的互信代理通过预先约定的“共识机制”达成集体决议。共识成功后该证书吊销记录被追加到区块链中。
具体的，在所述区块链记录中，增加证书实体1的原实体证书对应的吊销记录。
若共识失败，CA1可在本身的证书状态记录(可与区块链相同，或者不同)中，增加证书实体1的原实体证书对应的吊销记录。
如图8所示，本公开的一些实施例的证书查询流程包括步骤801-805。
步骤801、证书实体1与证书依赖方1建立通信关系，证书实体1向证书依赖方1出示自己的最终实体证书(可能还包含相应中间CA的证书)，例如用于加密通信或数字签名。
步骤802、证书依赖方1需要验证证书实体1出示的最终实体证书是否真实有效。证书依赖方1尝试重建该证书的完整证书链，发现该证书链的根是CA1，而CA1并不是证书依赖方1的信任锚。
步骤803、证书依赖方1向自己的信任锚CA5发送证书验证请求，请求中携带证书实体1出示的最终实体证书。
步骤804、CA5收到证书验证请求后，进行验证。其中，(1)、(2)两种方式不分先后。
(1)尝试重建该证书的完整证书链，发现该证书链的根是CA1。接着检查是否与CA1存在传统的交叉认证、桥认证关系。若存在，则按照传统的方法校验证书链。同时，获得第一验证结果。
(2)检查该最终实体证书中是否包含区块链认证标记。若包含，则执行 如下操作：
CA5通过互信代理5在区块链中查询关于该最终实体证书的所有记录，包括新增、更新、吊销等。互信代理5根据查询结果判断该证书是否被自己共识过，以及是否仍然有效。这个判断过程仅凭查询到的记录即可完成，无需再重建和验证整个证书链。同时，获得第二验证结果。
步骤805、CA5向证书依赖方1发送验证结果。
在具体实现过程中，为了兼容传统的PKI互信体系，允许为传统互信体系和区块链互信体系设置不同的优先级；有些证书不带有区块链认证标识，无法在区块链上查询到，只能依靠传统的互信体系。
若步骤804中的两种方法均无法完成证书验证，则CA5返回给证书依赖方1一个“无法验证”的响应。若只有一种方法可以完成证书验证，或两种方法均可完成验证且验证结果一致，则直接将该任意一个或者两个验证结果返回给证书依赖方1。若两种方法均可完成验证但验证结果不一致，则按照CA5预定的规则，取优先级较高的一种方法，将其验证结果返回给证书依赖方1。
证书依赖方1收到来自CA5的验证结果，根据验证结果决定是否继续执行与证书实体1之间的通信过程(如建立加密通信关系，或验证证书实体1的数字签名)。
上述一些流程合在一起，可实现区块链系统中所有CA信任域的全面融合。系统中的CA无需再进行复杂的交叉认证，也无需另一个公信力更高的机构来建立一个桥CA。同时，可实现per用户证书粒度的精细互信控制，即，其它CA无需信任CA1签发的所有最终实体证书，它们可以选择只信任能够在区块链中达成共识的证书(包含了区块链认证标记的证书)。需要说明的是，在实际应用中，上述几个流程可以结合使用，也可单独使用。
在本公开的一些实施例中，在区块链系统中，可实现基于区块链认证标记进行证书的相关处理，无需复杂的网状交叉认证，无需依靠公信力更高的权威中介建立桥接关系，即可实现每用户证书粒度的精细互信控制。因此，利用本公开的一些实施例的方案，提高了实现CA互信的灵活性。
如图9所示，本公开的一些实施例的实现CA互信的装置，应用于CA 互信系统中的CA实体；所述CA互信系统包括：至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统；各CA实体中存储有区块链记录，用于记录对实体证书的操作记录；所述装置包括：分配模块901，用于为证书请求方分配待签发实体证书；请求模块902，用于向所述系统中的其他CA实体请求对所述待签发实体证书进行共识；签发模块903，用于若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；和更新模块904，用于更新存储的区块链记录。
如图10所示，所述装置还包括：互信代理模块905，用于将所述实现CA互信的装置与其他CA实体组成P2P网络并形成区块链系统；所述区块链记录存储在所述互信代理模块中。
其中，所述分配模块901包括：接收子模块，用于接收所述证书请求方的证书申请请求；身份鉴别子模块，用于根据所述证书申请请求对所述证书请求方进行身份鉴别，获得所述证书请求方的身份鉴别信息；分配子模块，用于当对所述证书请求方的身份鉴别通过后，为所述证书请求方分配所述待签发实体证书。
其中，所述请求模块902具体用于，通过对应设置的互信代理模块，向所述系统中其他CA实体对应的互信代理模块请求对所述待签发实体证书进行共识；所述签发模块903具体用于，若确定所述其他CA实体对应的互信代理模块对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书；所述更新模块904具体用于，在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
在一个实施例中，所述请求模块902具体用于，通过对应设置的互信代理模块，向所述系统中其他CA实体对应的互信代理模块发送所述待签发实体证书、所述证书请求方的身份鉴别信息，以请求对所述待签发实体证书进行共识。
在实际应用中，所述CA互信系统还包括：各CA实体对应的中间CA实体；所述签发模块具体用于，通过所述中间CA实体向所述证书请求方签发 所述待签发实体证书。
再如图10所示，所述装置还包括：删除模块906，用于若确定所述其他CA实体对所述待签发实体证书的共识未通过，则删除所述待签发实体证书，并向所述证书请求方签发最终实体证书，其中所述最终实体证书中不包括所述区块链认证标记；以及第一接收模块907，用于接收所述证书请求方的证书更新请求。此时，所述分配模块901具体用于，根据所述证书更新请求，为所述证书请求方分配新的待签发实体证书；所述请求模块902具体用于，通过对应设置的互信代理模块，向所述系统中的其他CA实体对应的互信代理模块请求对所述新的待签发实体证书进行共识；所述签发模块903具体用于，若确定所述其他CA实体对应的互信代理模块对所述新的待签发实体证书的共识通过，则向所述证书请求方签发所述新的待签发实体证书；所述更新模块904具体用于，在所述区块链记录中，增加所述证书请求方的原实体证书对应的更新记录。
再如图10所示，所述装置还包括：通知模块908，用于通知所述其他CA实体吊销所述证书请求方的原实体证书。
具体的，所述通知模块908具体用于，通过所述互信代理模块，向所述其他CA实体对应的互信代理模块发送证书吊销请求，请求吊销所述证书请求方的原实体证书；所述更新模块904具体用于，在所述区块链记录中，增加所述原实体证书对应的吊销记录。
再如图10所示，所述装置还包括：第二接收模块909，用于接收证书验证请求方的证书验证请求，在所述证书验证请求中包括待验证实体证书；第一验证模块910，用于根据所述待验证实体证书确定根CA实体，并与所述根CA实体交互完成对所述待验证实体证书的验证，获得第一验证结果；第一确定模块911，用于确定所述待验证实体证书中是否包含区块链认证标记；第二验证模块912，用于若包含所述区块链认证标记，则利用对应设置的互信代理模块和所述区块链认证标记查找存储的区块链记录，根据查找确定是否通过对所述待验证实体证书的验证，获得第二验证结果；结果发送模块913，用于根据所述第一验证结果和所述第二验证结果，向所述证书验证请求方发送最终的验证结果。
其中，所述结果发送模块913具体用于，若所述第一验证结果和所述第二验证结果均表示通过对所述待验证实体证书的验证，则向所述证书验证请求方发送所述第一验证结果和/或所述第二验证结果；若所述第一验证结果和所述第二验证结果不一致，则根据设置的验证结果选择信息，选择优先级较高的验证结果作为最终的验证结果，并向所述证书验证请求方发送所述最终的验证结果。
本公开所述装置的工作原理可参照前述方法实施例的描述。
在本公开的一些实施例中，可实现基于区块链认证标记进行证书的相关处理，无需复杂的网状交叉认证，无需依靠公信力更高的权威中介建立桥接关系，即可实现每用户证书粒度的精细互信控制。因此，利用本公开的一些实施例的方案，提高了实现CA互信的灵活性。
如图11所示，本公开的一些实施例的实现CA互信的装置，应用于CA互信系统中的CA实体；所述CA互信系统包括：至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统；各CA实体中存储有区块链记录，用于记录对实体证书的操作记录；所述装置包括：
接收模块1101，用于接收第一CA实体的证书共识请求；共识模块1102，用于根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；更新模块1103，用于若确定对所述待签发实体证书的认证通过，则更新存储的区块链记录。
具体的，所述更新模块1103具体用于，在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
具体的，所述更新模块1103具体用于，当有实体证书更新时，在所述区块链记录中，增加对进行更新的实体证书对应的更新记录。
其中，所述接收模块1101还用于，接收所述第一CA实体的证书吊销请求，根据所述证书吊销请求确定是否通过所述证书吊销请求；所述更新模块1103具体用于，当通过所述证书吊销请求时，在所述区块链记录中，增加被吊销的实体证书对应的吊销记录。
本公开所述装置的工作原理可参照前述方法实施例的描述。
在本公开的一些实施例中，可实现基于区块链认证标记进行证书的相关处理，无需复杂的网状交叉认证，无需依靠公信力更高的权威中介建立桥接关系，即可实现每用户证书粒度的精细互信控制。因此，利用本公开的一些实施例的方案，提高了实现CA互信的灵活性。
本公开的一些实施例的电子设备包括处理器1201和存储器1202，所述存储器1202用于存储计算机程序。其中，当所述处理器1201调用并且执行在所述存储器1202上存储的所述计算机程序时，所述处理器1201实现如前述任一实施例的实现CA互信的方法。
本公开的一些实施例的计算机可读存储介质，用于存储计算机程序，其中，所述计算机程序可被处理器执行如前述任一实施例的实现CA互信的方法。
在本申请所提供的几个实施例中，应该理解到，所揭露方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理包括，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述收发方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、易失性或非易失性随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述是本公开的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本公开所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本公开的保护范围。

Claims (38)

  1. 一种实现证书权威CA互信的方法，该方法应用于CA互信系统中的CA实体，所述CA互信系统包括至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统，各CA实体中存储有区块链记录，区块链记录用于记录对实体证书的操作记录，所述方法包括：
    为证书请求方分配待签发实体证书；
    向所述系统中的其他CA实体请求对所述待签发实体证书进行共识；
    若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；以及
    更新存储的区块链记录。
  2. 根据权利要求1所述的方法，其中，所述各CA实体分别对应设置有互信代理，各CA实体通过对应设置的互信代理组成P2P网络并形成区块链系统，所述区块链记录存储在所述互信代理中。
  3. 根据权利要求1或2所述的方法，其中，所述为证书请求方分配待签发实体证书，包括：
    接收所述证书请求方的证书申请请求；
    根据所述证书申请请求对所述证书请求方进行身份鉴别，获得所述证书请求方的身份鉴别信息；以及
    当对所述证书请求方的身份鉴别通过后，为所述证书请求方分配所述待签发实体证书。
  4. 根据权利要求2所述的方法，其中，所述向所述系统中的其他CA实体请求对所述待签发实体证书进行共识，包括：
    通过对应设置的互信代理，向所述系统中其他CA实体对应的互信代理模块请求对所述待签发实体证书进行共识；
    所述若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，包括：
    若确定所述其他CA实体对应的互信代理模块对所述待签发实体证书的 共识通过，则向所述证书请求方签发所述待签发实体证书；并且
    所述更新存储的区块链记录，包括：
    在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
  5. 根据权利要求4所述的方法，其中，所述通过对应设置的互信代理，向所述系统中其他CA实体对应的互信代理模块请求对所述待签发实体证书进行共识，包括：
    通过对应设置的互信代理，向所述系统中其他CA实体对应的互信代理模块发送所述待签发实体证书、所述证书请求方的身份鉴别信息，以请求对所述待签发实体证书进行共识。
  6. 根据权利要求1或2所述的方法，其中，所述CA互信系统还包括各CA实体对应的中间CA实体，
    所述向所述证书请求方签发所述待签发实体证书，包括：
    通过所述中间CA实体向所述证书请求方签发所述待签发实体证书。
  7. 根据权利要求1或2所述的方法，还包括：
    若确定所述其他CA实体对所述待签发实体证书的共识未通过，则删除所述待签发实体证书，并向所述证书请求方签发最终实体证书，其中所述最终实体证书中不包括所述区块链认证标记。
  8. 根据权利要求2所述的方法，其中，在所述为证书请求方分配待签发实体证书的步骤之前，所述方法还包括：
    接收所述证书请求方的证书更新请求；
    所述为证书请求方分配待签发实体证书，包括：
    根据所述证书更新请求，为所述证书请求方分配新的待签发实体证书；
    所述向所述系统中的其他CA实体请求对所述待签发实体证书进行共识，包括：
    通过对应设置的互信代理，向所述系统中的其他CA实体对应的互信代理请求对所述新的待签发实体证书进行共识；
    所述若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，包括：
    所述若确定所述其他CA实体对应的互信代理对所述新的待签发实体证 书的共识通过，则向所述证书请求方签发所述新的待签发实体证书；并且
    所述更新存储的区块链记录，包括：
    在所述区块链记录中，增加所述证书请求方的原实体证书对应的更新记录。
  9. 根据权利要求2或8所述的方法，还包括：
    通知所述其他CA实体吊销所述证书请求方的原实体证书。
  10. 根据权利要求9所述的方法，其中，所述通知所述其他CA实体吊销所述证书请求方的原实体证书，包括：
    通过对应设置的互信代理，向所述其他CA实体对应的互信代理发送证书吊销请求，请求吊销所述证书请求方的原实体证书；并且
    所述更新存储的区块链记录，包括：
    在所述区块链记录中，增加所述原实体证书对应的吊销记录。
  11. 根据权利要求2所述的方法，还包括：
    接收证书验证请求方的证书验证请求，在所述证书验证请求中包括待验证实体证书；
    根据所述待验证实体证书确定根CA实体，并与所述根CA实体交互完成对所述待验证实体证书的验证，获得第一验证结果；
    确定所述待验证实体证书中是否包含区块链认证标记；
    若包含所述区块链认证标记，则利用对应设置的互信代理和所述区块链认证标记查找存储的区块链记录，根据查找确定是否通过对所述待验证实体证书的验证，获得第二验证结果；以及
    根据所述第一验证结果和所述第二验证结果，向所述证书验证请求方发送最终的验证结果。
  12. 根据权利要求11所述的方法，其中，所述根据所述第一验证结果和所述第二验证结果，向所述证书验证请求方发送最终的验证结果，包括：
    若所述第一验证结果和所述第二验证结果均表示通过对所述待验证实体证书的验证，则向所述证书验证请求方发送所述第一验证结果和/或所述第二验证结果；以及
    若所述第一验证结果和所述第二验证结果不一致，则根据设置的验证结 果选择信息，选择优先级较高的验证结果作为最终的验证结果，并向所述证书验证请求方发送所述最终的验证结果。
  13. 一种实现证书权威CA互信的方法，该方法应用于CA互信系统中的CA实体，所述CA互信系统包括至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统，各CA实体中存储有区块链记录，区块链记录用于记录对实体证书的操作记录，所述方法包括：
    接收第一CA实体的证书共识请求；
    根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；以及
    若确定对所述待签发实体证书的共识通过，则更新存储的区块链记录。
  14. 根据权利要求13所述的方法，其中，所述更新存储的区块链记录，包括：
    在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
  15. 根据权利要求14所述的方法，其中，所述更新存储的区块链记录，还包括：
    当有实体证书更新时，在所述区块链记录中，增加对进行更新的实体证书对应的更新记录。
  16. 根据权利要求15所述的方法，还包括：
    接收所述第一CA实体的证书吊销请求，根据所述证书吊销请求确定是否通过所述证书吊销请求；并且
    所述更新存储的区块链记录，包括：
    当通过所述证书吊销请求时，在所述区块链记录中，增加被吊销的实体证书对应的吊销记录。
  17. 一种实现证书权威CA互信的装置，该装置应用于CA互信系统中的CA实体，所述CA互信系统包括至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统，各CA实体中存储有区块链记录，区块链记录用于记录对实体证书的操作记录；所述装置包括：
    分配模块，用于为证书请求方分配待签发实体证书；
    请求模块，用于向所述系统中的其他CA实体请求对所述待签发实体证书进行共识；
    签发模块，用于若确定所述其他CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；以及
    更新模块，用于更新存储的区块链记录。
  18. 根据权利要求17所述的装置，还包括：
    互信代理模块，用于将所述实现CA互信的装置与其他CA实体组成P2P网络并形成区块链系统；所述区块链记录存储在所述互信代理模块中。
  19. 根据权利要求17或18所述的装置，其中，所述分配模块包括：
    接收子模块，用于接收所述证书请求方的证书申请请求；
    身份鉴别子模块，用于根据所述证书申请请求对所述证书请求方进行身份鉴别，获得所述证书请求方的身份鉴别信息；以及
    分配子模块，用于当对所述证书请求方的身份鉴别通过后，为所述证书请求方分配所述待签发实体证书。
  20. 根据权利要求18所述的装置，其中，所述请求模块具体用于，通过对应设置的互信代理模块，向所述系统中其他CA实体对应的互信代理模块请求对所述待签发实体证书进行共识；
    所述签发模块具体用于，若确定所述其他CA实体对应的互信代理模块对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书；并且
    所述更新模块具体用于，在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
  21. 根据权利要求20所述的装置，其中，所述请求模块具体用于，通过对应设置的互信代理模块，向所述系统中其他CA实体对应的互信代理模块发送所述待签发实体证书、所述证书请求方的身份鉴别信息，以请求对所述待签发实体证书进行共识。
  22. 根据权利要求17或18所述的装置，其中，所述CA互信系统还包 括各CA实体对应的中间CA实体；
    所述签发模块具体用于通过所述中间CA实体向所述证书请求方签发所述待签发实体证书。
  23. 根据权利要求17或18所述的装置，还包括：
    删除模块，用于若确定所述其他CA实体对所述待签发实体证书的共识未通过，则删除所述待签发实体证书，并向所述证书请求方签发最终实体证书，其中所述最终实体证书中不包括所述区块链认证标记。
  24. 根据权利要求18所述的装置，还包括：
    第一接收模块，用于接收所述证书请求方的证书更新请求；
    所述分配模块具体用于，根据所述证书更新请求，为所述证书请求方分配新的待签发实体证书；
    所述请求模块具体用于，通过对应设置的互信代理模块，向所述系统中的其他CA实体对应的互信代理模块请求对所述新的待签发实体证书进行共识；
    所述签发模块具体用于，若确定所述其他CA实体对应的互信代理模块对所述新的待签发实体证书的共识通过，则向所述证书请求方签发所述新的待签发实体证书；并且
    所述更新模块具体用于，在所述区块链记录中，增加所述证书请求方的原实体证书对应的更新记录。
  25. 根据权利要求18或24所述的装置，还包括：
    通知模块，用于通知所述其他CA实体吊销所述证书请求方的原实体证书。
  26. 根据权利要求25所述的装置，其中，所述通知模块具体用于，通过所述互信代理模块，向所述其他CA实体对应的互信代理模块发送证书吊销请求，请求吊销所述证书请求方的原实体证书；并且
    所述更新模块具体用于，在所述区块链记录中，增加所述原实体证书对应的吊销记录。
  27. 根据权利要求18所述的装置，还包括：
    第二接收模块，用于接收证书验证请求方的证书验证请求，在所述证书 验证请求中包括待验证实体证书；
    第一验证模块，用于根据所述待验证实体证书确定根CA实体，并与所述根CA实体交互完成对所述待验证实体证书的验证，获得第一验证结果；
    第一确定模块，用于确定所述待验证实体证书中是否包含区块链认证标记；
    第二验证模块，用于若包含所述区块链认证标记，则利用对应设置的互信代理模块和所述区块链认证标记查找存储的区块链记录，根据查找确定是否通过对所述待验证实体证书的验证，获得第二验证结果；以及
    结果发送模块，用于根据所述第一验证结果和所述第二验证结果，向所述证书验证请求方发送最终的验证结果。
  28. 根据权利要求27所述的装置，其中，所述结果发送模块具体用于，若所述第一验证结果和所述第二验证结果均表示通过对所述待验证实体证书的验证，则向所述证书验证请求方发送所述第一验证结果和/或所述第二验证结果；并且
    若所述第一验证结果和所述第二验证结果不一致，则根据设置的验证结果选择信息，选择优先级较高的验证结果作为最终的验证结果，并向所述证书验证请求方发送所述最终的验证结果。
  29. 一种实现证书权威CA互信的装置，该装置应用于CA互信系统中的CA实体，所述CA互信系统包括至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统，各CA实体中存储有区块链记录，区块链记录用于记录对实体证书的操作记录，所述装置包括：
    接收模块，用于接收第一CA实体的证书共识请求；
    共识模块，用于根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识；以及
    更新模块，用于若确定对所述待签发实体证书的共识通过，则更新存储的区块链记录。
  30. 根据权利要求29所述的装置，其中，所述更新模块具体用于，在所述区块链记录中，增加所述待签发实体证书对应的新增记录。
  31. 根据权利要求30所述的装置，其中，所述更新模块具体用于，当有实体证书更新时，在所述区块链记录中，增加对进行更新的实体证书对应的更新记录。
  32. 根据权利要求31所述的装置，其中，所述接收模块还用于，接收所述第一CA实体的证书吊销请求，根据所述证书吊销请求确定是否通过所述证书吊销请求；以及
    所述更新模块具体用于，当通过所述证书吊销请求时，在所述区块链记录中，增加被吊销的实体证书对应的吊销记录。
  33. 一种实现证书权威CA互信的系统，包括：
    至少三个CA实体，各CA实体组成点到点P2P网络并形成区块链系统；各CA实体中存储有区块链记录，用于记录对实体证书的操作记录；
    其中，所述至少三个CA实体中的第一CA实体，为证书请求方分配待签发实体证书，并向所述系统中的第二CA实体请求对所述待签发实体证书进行共识；若确定所述第二CA实体对所述待签发实体证书的共识通过，则向所述证书请求方签发所述待签发实体证书，在所述待签发实体证书中包括区块链认证标记，其中所述区块链认证标记为所述区块链系统的标识，并更新存储的区块链记录；
    所述至少三个CA实体中的第二CA实体，接收所述第一CA实体的证书共识请求，并根据所述第一CA实体的证书共识请求，对所述第一CA实体的待签发实体证书进行共识，若确定对所述待签发实体证书的共识通过，则更新存储的区块链记录。
  34. 根据权利要求33所述的系统，其中，所述各CA实体分别对应设置有互信代理，各CA实体通过对应设置的互信代理组成P2P网络并形成区块链系统；所述区块链记录存储在所述互信代理中。
  35. 一种电子设备，包括：
    处理器，
    存储器，用于存储计算机程序；
    其中，所述处理器在调用并执行所述存储器上存储的计算机程序时，所述处理器实现如权利要求1-12任一项所述的实现证书权威CA互信的方法。
  36. 一种计算机可读存储介质，包括：
    在所述计算机可读存储介质上存储的计算机程序，
    其中，当所述计算机程序被处理器执行时，所述处理器执行如权利要求1-12任一项所述的实现证书权威CA互信的方法。
  37. 一种电子设备，包括：
    处理器，
    存储器，用于存储计算机程序；
    其中，所述处理器在调用并执行所述存储器上存储的计算机程序时，所述处理器实现如权利要求13-16任一项所述的实现证书权威CA互信的方法。
  38. 一种计算机可读存储介质，包括：
    在所述计算机可读存储介质上存储的计算机程序，
    其中，当所述计算机程序被处理器执行时，所述处理器执行如权利要求13-16任一项所述的实现证书权威CA互信的方法。
PCT/CN2018/078848 2017-04-06 2018-03-13 实现ca互信的方法、装置、系统和电子设备 WO2018184446A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710220298.0 2017-04-06
CN201710220298.0A CN108696348A (zh) 2017-04-06 2017-04-06 一种实现ca互信的方法、装置、系统和电子设备

Publications (1)

Publication Number Publication Date
WO2018184446A1 true WO2018184446A1 (zh) 2018-10-11

Family

ID=63713389

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/078848 WO2018184446A1 (zh) 2017-04-06 2018-03-13 实现ca互信的方法、装置、系统和电子设备

Country Status (2)

Country Link
CN (1) CN108696348A (zh)
WO (1) WO2018184446A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112163845A (zh) * 2020-09-29 2021-01-01 深圳前海微众银行股份有限公司 一种跨区块链的交易身份确认方法及装置

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BR112019008174A2 (pt) * 2018-11-07 2019-09-10 Alibaba Group Holding Ltd método implementado por computador, meio de armazenamento legível por computador, não transitório e sistema
TWI732247B (zh) * 2019-07-16 2021-07-01 中華電信股份有限公司 證明簽章時憑證有效性的紀錄方法
CN110636051B (zh) * 2019-08-29 2022-04-15 中芯昊月(深圳)科技控股有限公司 一种基于多用户ca数字证书的区块链交易方法
CN113114463B (zh) * 2020-01-13 2023-04-07 中国移动通信有限公司研究院 一种证书注册方法、验证方法及设备
CN111683060B (zh) * 2020-05-20 2023-01-20 国汽(北京)智能网联汽车研究院有限公司 通信消息验证方法、装置及计算机存储介质
CN114157428A (zh) * 2020-09-04 2022-03-08 中国移动通信集团重庆有限公司 一种基于区块链的数字证书管理方法和系统
CN114726567A (zh) * 2021-01-05 2022-07-08 中国移动通信有限公司研究院 节点交互方法、证书验证方法、装置及相关设备
CN113536284B (zh) * 2021-07-21 2024-06-21 数字广东网络建设有限公司 一种数字证书的验证方法、装置、设备和存储介质
CN115277066B (zh) * 2022-06-13 2023-05-09 广州大学 一种适用于多条区块链的相互认证方法
CN117156440B (zh) * 2023-10-27 2024-01-30 中电科网络安全科技股份有限公司 一种证书认证方法、系统、存储介质和电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105591753A (zh) * 2016-01-13 2016-05-18 杭州复杂美科技有限公司 一种ca证书在区块链上的应用方法
CN106301792A (zh) * 2016-08-31 2017-01-04 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及系统
CN106384236A (zh) * 2016-08-31 2017-02-08 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及系统
WO2017022917A1 (ko) * 2015-08-03 2017-02-09 (주)코인플러그 블록체인을 기반으로 하는 공인인증서 발급시스템

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0414421D0 (en) * 2004-06-28 2004-07-28 Nokia Corp Authenticating users
CN104680061A (zh) * 2015-02-28 2015-06-03 国鼎网络空间安全技术有限公司 一种Android环境下应用程序启动中代码签名验证的方法和系统
CN105701372B (zh) * 2015-12-18 2019-04-09 布比（北京）网络技术有限公司 一种区块链身份构建及验证方法
CN105790954B (zh) * 2016-03-02 2019-04-09 布比（北京）网络技术有限公司 一种构建电子证据的方法和系统
CN105976232B (zh) * 2016-06-24 2020-04-28 深圳前海微众银行股份有限公司 资产交易方法和装置
CN106385315B (zh) * 2016-08-30 2019-05-17 北京三未信安科技发展有限公司 一种数字证书管理方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017022917A1 (ko) * 2015-08-03 2017-02-09 (주)코인플러그 블록체인을 기반으로 하는 공인인증서 발급시스템
CN105591753A (zh) * 2016-01-13 2016-05-18 杭州复杂美科技有限公司 一种ca证书在区块链上的应用方法
CN106301792A (zh) * 2016-08-31 2017-01-04 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及系统
CN106384236A (zh) * 2016-08-31 2017-02-08 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112163845A (zh) * 2020-09-29 2021-01-01 深圳前海微众银行股份有限公司 一种跨区块链的交易身份确认方法及装置
CN112163845B (zh) * 2020-09-29 2024-03-22 深圳前海微众银行股份有限公司 一种跨区块链的交易身份确认方法及装置

Also Published As

Publication number Publication date
CN108696348A (zh) 2018-10-23

Similar Documents

Publication Publication Date Title
WO2018184446A1 (zh) 实现ca互信的方法、装置、系统和电子设备
CN109617698B (zh) 发放数字证书的方法、数字证书颁发中心和介质
US9621355B1 (en) Securely authorizing client applications on devices to hosted services
CN110537346B (zh) 安全去中心化域名系统
US10083291B2 (en) Automating internet of things security provisioning
US10678555B2 (en) Host identity bootstrapping
US20180343126A1 (en) System and method for utilizing connected devices to enable secure and anonymous electronic interaction in a decentralized manner
JP5215289B2 (ja) 分散式の委任および検証のための方法、装置、およびシステム
WO2018112946A1 (zh) 注册及授权方法、装置及系统
JP2021526341A (ja) 電子証明書の管理方法、装置、コンピュータ装置及びコンピュータプログラム
EP2842258B1 (en) Multi-factor certificate authority
US9647998B2 (en) Geo-fencing cryptographic key material
US20150271156A1 (en) Geo-Fencing Cryptographic Key Material
US9178869B2 (en) Locating network resources for an entity based on its digital certificate
WO2019142428A1 (ja) 情報処理装置およびその処理方法
US7930763B2 (en) Method of authorising a computing entity
JP2022552420A (ja) 証明書認証用の分散台帳に基づく方法およびシステム
CN1921383A (zh) 一种基于门限ca和x.509公钥证书的密钥管理实现方法
JP6319817B2 (ja) 検証装置及び電子証明書検証方法
Fugkeaw et al. A robust single sign-on model based on multi-agent system and PKI
CN113114463B (zh) 一种证书注册方法、验证方法及设备
CN113647079B (zh) 用于为用户签发加密保护的真实性证书的方法
Zhou et al. An efficient public-key framework
CN113672959A (zh) 一种可溯源的基于区块链的无纸化办公痕迹保留方法
WO2023287435A1 (en) Blockchain for digital certificate transactions

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: 18780634

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 29/01/2020

122 Ep: pct application non-entry in european phase

Ref document number: 18780634

Country of ref document: EP

Kind code of ref document: A1