Distributed ledger-based method and system for certificate authentication

Abstract

A method and system for publishing transactions for adding and removing roles and certificates to and from a distributed ledger and for authenticating the certificates of two connected servers.SOLUTION: A role specifies which servers with the role can publish certificates and what types of transactions for the role. When a role is requested, two transactions to add the role and the issuer certificate are published to the distributed ledger. When a certificate of a server that does not have any role is requested, only a transaction for adding the certificate is published to the distributed ledger. All transactions are published through operations between the certificate requesting server, the certificate issuing server, and the distributed ledger network maintaining the distributed ledger. Two connected servers can verify the authenticity of their other party's identity using a certificate received from the distributed ledger, which has the benefits of certificate immutability and availability of distributed ledger technology.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a method and system for establishing authenticated connections, and more particularly to a method and system for establishing authenticated connections employing distributed ledger technology. [Background technology]

[0002] To ensure a secure network, mutual authentication is a security process in which entities authenticate each other before an actual connection is made. In a network environment, this mutual authentication requires that both the client and server must provide digital certificates to prove their identities. The mutual authentication process allows a connection to occur only if the client and server exchange, verify, and trust each other's certificates. The Transport Layer Security (TLS) protocol and its predecessor, the Secure Socket Layer (SSL) protocol, were developed to address such certificate exchange and verification. The SSL / TLS protocol employs one of the most common types of X.509 certificates, which are public key certificates whose format is specified by the X.509 standard. An X.509 certificate securely associates the identity of a website, individual, or organization with a cryptographic key pair.

[0003] However, X.509 certificates are by no means perfect as far as certificate immutability, certificate availability, and certificate history are concerned. The impact of certificate immutability is that hacker attacks can make unauthorized changes to X.509 certificates. If either the root certificate or the certificate authority (CA) is compromised, system security is at risk. Another drawback of certificate availability is that every server must maintain its own certificate database, resulting in inconsistencies between certificate databases. Regarding the downside of certificate history, not all records, including additions and revocations, are present in the X.509 certificate database due to the two issues mentioned above. Summary of the Invention [Problem to be solved by the invention]

[0004] It is an object of the present invention to provide methods and systems for publishing issuer qualifications and issuer certificates, publishing server certificates in a distributed ledger, and for certificate authentication, which improves certificate immutability and certificate availability when it comes to adding and removing server certificates from a distributed ledger maintained by a distributed ledger network and validating certificates in the distributed ledger. [Means for solving the problem]

[0005] To achieve the above-mentioned objective, a method for publishing an issuer credential and an issuer certificate to a distributed ledger maintained by a distributed ledger network including a certificate-issuing node (CI) through a CI and a certificate-requesting server (CR) that are in communication with each other includes: (a) the CI receiving credential-related information from the CR; (b) the CI signing an issuer credential transaction and submitting the issuer credential transaction to the distributed ledger; (c) one of the CR and the CI creating an issuer certificate for the CR, signing the issuer certificate, and sending the issuer certificate to the CR when the signer of the issuer certificate is not the CR; and (d) after the issuer credential transaction is created in the distributed ledger, any one of the CR and the CI that has the issuer certificate signing an issuer certificate transaction and submitting the issuer certificate transaction to the distributed ledger.

[0006] To achieve the above-mentioned objective, a method for publishing a server certificate to a distributed ledger maintained by a distributed ledger network including a certificate issuing server (CI) through a certificate issuing server (CI) and a certificate requesting server (CR) that are in communication with each other includes the steps of: (a) the CI receiving certificate-related information from the CR; (b) the CI creating a server certificate for the CR, signing the server certificate, and sending the server certificate to the CR; and (c) the CI signing a server certificate transaction and submitting the server certificate transaction to the distributed ledger.

[0007] To achieve the above-mentioned objective, a method for authenticating certificates of a connecting server (CS) and a receiving server (RS) communicatively connected to a distributed ledger network that maintains a distributed ledger includes: (a) the RS exchanging identities with the CS; (b) the RS retrieving the CS's certificate and the CS's certificate issuer public key from the distributed ledger based on the CS's identity; (c) the RS verifying whether the CS's certificate is authentic using the CS's certificate issuer public key; and (d) after verifying that the CS's certificate is authentic, the RS determining that the CS is authorized to receive confidential information from the RS.

[0008] To achieve the aforementioned objectives, a distributed ledger-based system for publishing issuer qualifications and issuer certificates includes a certificate request server (CR) and a distributed ledger network.

[0009] A distributed ledger network maintaining the distributed ledger is communicatively connected to the CR and includes a certificate issuing node (CI). The CI receives credential-related information from the CR, signs an issuer credential transaction, and submits the issuer credential transaction to the distributed ledger. One of the CR and the CI further creates an issuer certificate for the CR and sends the issuer certificate to the CR when the signer of the issuer certificate is not the CR. After the issuer credential transaction is created on the distributed ledger, one of the CR and the CI having the issuer certificate signs an issuer certificate transaction and submits the issuer certificate transaction to the distributed ledger.

[0010] To achieve the aforementioned objectives, a distributed ledger-based system for publishing a server certificate to a distributed ledger includes a certificate request server (CR) and a distributed ledger network.

[0011] The distributed ledger network maintains a distributed ledger, is communicatively connected to the CR, and includes a certificate issuing server (CI), which receives certificate-related information from the CR, creates a server certificate for the CR, signs the server certificate, transmits the server certificate to the CR, signs the server certificate transaction, and submits the server certificate transaction to the distributed ledger.

[0012] To achieve the aforementioned objectives, the distributed ledger-based system for certificate authentication includes a distributed ledger network, a connection server (CS), and a receiving server (RS).

[0013] A distributed ledger network maintains a distributed ledger.

[0014] The CS is communicatively connected to the distributed ledger network.

[0015] The RS is communicatively connected to the distributed ledger network, exchanges identities with the CS, retrieves the CS's certificate and the public key of the CS certificate issuer from the distributed ledger based on the CS's identity, and verifies whether the CS's certificate is authentic. When it verifies that the CS's certificate is authentic, it determines that the CS is authorized to receive confidential information from the RS.

[0016] According to the above, every server, with a role or no role at all, has its own certificate that is added or removed by authorized servers to or from the distributed ledger. Roles in the distributed ledger specify authorities that regulate which servers with roles are authorized to add what types of roles and certificates, thereby preventing unauthorized entities from corrupting certificates and roles in the distributed ledger. Distributed ledgers are inherently decentralized. This adds a layer of security because there is no centralized entity to target with malicious activity. Distributed ledgers can be spread globally in a replicated manner, avoiding single points of failure. As a result, roles and certificates published in a distributed ledger can also benefit from the immutability of the distributed ledger. Inconsistencies regarding certificates and roles in a distributed ledger are not likely to be an issue, because certificates and roles in a distributed ledger can be constantly and quickly updated based on a consensus mechanism. As a result, certificates added to a distributed ledger by the method and system of the present invention can provide the requirement that servers confirm trust with each other for certificate authentication, which is crucial for secure communication between servers. Furthermore, transparency can also be considered as an advantage of distributed ledger technology: distributed ledgers make all stored information easily and freely accessible, which adds a great deal of desired transparency to certificate authentication when connecting to a server.

[0017] Other objects, advantages and novel features of the present invention will become more apparent from the following detailed description when considered in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 2 is a block diagram illustrating the relationship between server roles and certificates created by the server in accordance with the present invention. [Figure 2] 1 is a flow diagram illustrating a method for publishing issuer entitlements and issuer certificates to a distributed ledger in accordance with the present invention. [Figure 3] 3 is a sequence diagram illustrating the method of FIG. 2 when a certificate request server (CR) requests the role of trustee and a certificate issuing server (CI) assumes the role of trustee quorum. [Figure 4] 3 is a sequence diagram illustrating an embodiment of the method of FIG. 2 when a CR requests the role of administrator and a CI assumes the role of trustee. [Figure 5]3 is a sequence diagram illustrating another embodiment of the method of FIG. 2 when a CR requests the role of administrator and a CI assumes the role of trustee. [Figure 6] 3 is a flow diagram illustrating steps of the method of FIG. 2 for creating an issuer certificate. [Figure 7] 1 is a sequence diagram illustrating a method for publishing a server certificate to a distributed ledger in accordance with the present invention. [Figure 8] 2 is a sequence diagram illustrating an embodiment of a method for authenticating certificates of a connection server (CS) and a receiving server according to the present invention. FIG. [Figure 9] FIG. 9 is a sequence diagram illustrating another embodiment of the method of FIG. 8. [Figure 10] FIG. 1 is a network architecture diagram illustrating an embodiment of a distributed ledger-based system for publishing issuer entitlements and issuer certificates in accordance with the present invention. [Figure 11] FIG. 10 is a network architecture diagram illustrating another embodiment of a distributed ledger-based system for the system of FIG. 9 and a distributed ledger-based system for publishing server certificates. [Figure 12] FIG. 1 is a network architecture diagram illustrating a distributed ledger-based network for certificate authentication. DETAILED DESCRIPTION OF THE INVENTION

[0019] The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is used in connection with a detailed description of certain specific embodiments of the technology. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restrictive manner is specifically defined as such in this "Detailed Description" section.

[0020] The embodiments described below may be implemented with programmable circuitry that is programmed or configured by software and / or firmware, or entirely with special purpose circuitry, or a combination of such forms, where such special purpose circuitry (if any) may take the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), etc.

[0021] Each server in the present invention possesses a certificate as its identity, which is stored in a distributed ledger maintained by the distributed ledger network. A certificate relating to a first server is submitted to a second server associated with it to verify the authenticity of the certificate. After the certificate is verified, the second server trusts the first server and voluntarily transmits secret information to the first server. Similarly, such a scenario can be applied in reverse when the second server provides its certificate to the first server for verification. To add or remove certificates from the distributed ledger, only servers with issuer credentials will be able to do so. To do this, issuer credentials should also be added or removed from the distributed ledger to keep track of which servers can add and remove what types of issuer credentials and certificates. There are distributed ledger rules that specify the types of issuer credentials of servers and the corresponding transactions that add, remove, or revoke issuer credentials and certificates of other servers.

[0022] Briefly, the described embodiments relate to one or more methods and systems for certificate authentication for publishing issuer credentials and certificates on a distributed ledger. To ensure certificate authentication when any two servers connect, a certificate retrieved from the distributed ledger based on the server's identity and exchanged server certificates can be verified to see if the retrieved certificate is available or matches the exchanged certificate that can be used as a basis to initiate authenticated information transfer between the servers. A distributed ledger-based solution is adopted because it foresees improvements in certificate trust and immutability. The solution consists in a certificate store that stores the credentials and certificates of multiple issuers in a distributed ledger. As the name reflects, issuer credentials are owned by a server with issuing authority that can add and remove issuer credentials and certificates of other servers to and from the distributed ledger. A server with issuer credentials or an issuer role can also have its own certificate in the distributed ledger, while a server without any issuer credentials can only have its own certificate in the distributed ledger. Transactions that add a server's certificate and add a server's issuer role to add a server with an issuer role are published to the distributed ledger through interactions between the distributed ledger and the certificate request server (CR) and the certificate issuing node (CI), two of many servers in the distributed ledger network. Transactions that add a server's certificate to add a server without any issuer role are published to the distributed ledger. In addition to publishing transactions, the operations here also involve the use of a ledger key pair to sign and verify transactions, and a certificate key pair to sign and verify certificates. When an issuer role or certificate is removed or revoked from the distributed ledger, the transaction that removes the issuer role or revokes the certificate is published to the distributed ledger. Details regarding the method and system are described in more detail below.

[0023] The goal of this invention is to emphasize that only issuers can sign and publish certificates. To achieve this goal, we describe two types of issuer roles: trustee and operator, and three types of certificates: root certificates, administrator certificates, and server certificates. All certificates must be published to the distributed ledger, but in a permissioned distributed ledger network, a server with an issuer role, but not every server, can publish certificates and issuer roles for other servers. The trustee and operator issuer roles represent the origin of trust and the administrator of each site, respectively, who is authorized to operate all servers at the site and publish certificates and issuer roles. For simplicity, the term "role" replaces "issuer role" hereafter in this specification. Servers with a trustee role, a server with an operator role, and a server without a role each possess a root certificate, an administrator certificate, and a server certificate, respectively. Despite the differences in names, the three types of certificates are essentially the same as far as their common data fields are concerned, except for the way in which the certificate's public key is used for validation. Root and administrator certificates relate to issuer certificates whose public key can be used to validate certificates signed by the issuer of that certificate, whereas the public key in a server certificate cannot be used to validate other certificates simply because the server holding the server certificate is not authorized to issue any certificates and there are no certificates signed by the server with the server certificate.

[0024] Given the signature relationship between any certificate and its signer's certificate, a simplified way to rephrase that relationship is that the issuer's certificate signs certificates and verifies certificates signed by the issuer. Given any certificate for verification, the certificate can be verified by recursively identifying the issuer certificates that signed it from the distributed ledger, and such verification can proceed all the way back to the top-level certificate, which is the root certificate. See Figure 1, which shows examples of certificate types and entities with issuer roles. The block on the left shows a server with the issuer role in a distributed ledger network, and the block on the right shows three types of certificates that may be published to the distributed ledger by authorized servers. As shown in Figure 1, a server with an operator role is entitled to publish transactions that add its own admin certificate and the server certificates of other servers to the distributed ledger without having any issuer role, and a server with a trustee role is entitled to publish transactions that add its own root certificate to the distributed ledger. The right side of Figure 1 illustrates three types of certificates in a distributed ledger. Each administrator certificate can be used to verify a server certificate signed by the administrator certificate, and a root certificate can be used to verify an administrator certificate signed by a server publishing the root certificate. The certificate validation process can start wherever a server or administrator certificate is located and can end at the root certificate, if available, with other intermediate administrator certificates between the server or administrator certificate and the root certificate being validated in sequence. Meanwhile, the validation process does not need to proceed all the way to the root certificate and can end when a condition is met or not met. Conditions include, but are not limited to, whether the certificate being validated is in a pre-approved list or whether validation ends with the certificate where validation started. Nevertheless, the number of servers with trustee and operator roles, the number of root certificates, administrator certificates, and server certificates, and the certificate hierarchy are not limited to those shown in Figure 1.

[0025] The following table, which shows the distributed ledger rules regarding which roles can publish which types of transactions to the distributed ledger, delves deeper into the relationship between roles and certificates:

[0026] [Table 1]

[0027] According to the table, a server with a trustee role is eligible to publish transactions on the distributed ledger that add and remove operator roles, root certificates, and administrator certificates associated with other servers. Note that a server with a trustee role is not eligible to add or revoke another server's server certificate. A server with a trustee role is not eligible to publish transactions that add and remove other servers' trustee roles alone unless it is the only server with the trustee role on the distributed ledger. Instead, a server with a trustee quorum role, defined as the collective role for a supermajority of at least one server on the distributed ledger that has the trustee role, is eligible to publish transactions that add and remove servers with the trustee role. In contrast to the trustee role, a server with an operator role is eligible to publish transactions to the distributed ledger that add, remove, or revoke operator roles, administrator certificates, and server certificates of other servers. Note that both servers with trustee roles and servers with operator roles can publish transactions that add, remove, and revoke operator roles and server administrator certificates. For servers with no roles, the server is not eligible to publish any transactions.

[0028] Since the certificate store in the distributed ledger containing issuer roles and certificates is fundamental for certificate authentication of two servers related to each other, a method of publishing transactions to add and remove roles and certificates is first introduced. When the certificate store is first constructed, it starts with an initiating transaction published to itself, creating the very first server with the role of trustee. The initiating transaction contains the trustee's decentralized identifier (DID), a public key for verifying the distributed ledger signature of any transaction published by the trustee, and the trustee's role.

[0029] Referring to FIG. 2, an embodiment of a method for publishing issuer credentials and issuer certificates to a distributed ledger according to the present invention is provided. The method in this embodiment involves a certificate request server (CR) and a certificate issuing node (CI), both of which are part of a distributed ledger network. The CI may include one or more servers. The method is applied when the CI is a node with a trustee quorum and a trustee role in the distributed ledger, and the CR requests to be added to the distributed ledger by the CI in the role of trustee or operator. In this method, servers without a role and server certificate are excluded from the discussion of the method. Because transactions published to the distributed ledger may be intended to add or remove roles and certificates, the method includes the following steps from steps S210 to S240 for adding roles and certificates:

[0030] Step S200: CI determines the type of transaction to be published, including adding roles and certificates, removing roles, and revoking certificates.

[0031] Step S210: When the transaction type of adding a role and certificate is determined, the CI receives credential-related information from the CR. The credential-related information is required to add the issuer credential or role of the CR in a transaction that is subsequently added to the distributed ledger, and includes the CR's DID, ledger public key, and role. Essentially, each server that has a role in the certificate store has a ledger key pair and a certificate key pair that are related to an asymmetric key pair. The ledger pair has a ledger public key and a ledger private key, and the certificate pair has a certificate public key and a certificate private key. The ledger private key associated with the server is stored on the server and is used by the server to sign any transaction published to the certificate store. The ledger public key associated with the server is sent to the distributed ledger for the transaction to add the server, such as the transaction mentioned in the current step to add a CR. As a result, the distributed ledger can verify any subsequent transaction signed by the server with the server's ledger public key. Meanwhile, the server's certificate private key is used by the server to sign another server's certificate, which may be one of an admin certificate and a server certificate. The server's certificate public key is included in the server's certificate to verify other server certificates signed by the server.

[0032] Step S220: The CI signs the issuer entitlement transaction and submits it to the distributed ledger. The issuer entitlement transaction serves to load the CR onto the distributed ledger and includes the CR's DID and ledger public key, the CI's DID, and the role of the CR to be added to the distributed ledger, and is signed by the CI's ledger private key. From the above table of distributed ledger rules, the CR may request to be added in the role of trustee or operator, while the CI may play the role of trustee quorum or trustee. When the CR requests the role of trustee, the CI should play the role of trustee quorum and include at least one server. When the CR requests the role of operator, the CI may play the role of trustee or operator and is an individual server.

[0033] Step S230: One of the CR and the CI creates an issuer certificate for the CR, signs the issuer certificate, and sends the issuer certificate to the CR when the signer of the issuer certificate is not the CR. When the CR requests the role of trustee, it is the CR that creates and signs the issuer certificate, and the issuer certificate is a root certificate. When the CR requests the role of operator, it is the CI that creates and signs the issuer certificate, and the issuer certificate is an administrator certificate. The issuer certificate is signed by the certificate private key of either the CR creating the issuer certificate or the CI, depending on the role claimed by the CR. If the creator of the issuer certificate is a CI, the CI must send the issuer certificate to the CR for storage and later verification.

[0034] Step S240: After the issuer credential transaction is created on the distributed ledger, either the CR or the CI who owns the issuer certificate signs the issuer certificate transaction and submits it to the distributed ledger. An issuer credential transaction should only be signed and submitted to the distributed ledger after it is created on the distributed ledger. When a CR requests the role of trustee, it creates its own root certificate and is the only CR who owns the root certificate. As a result, it is the CR who signs the issuer certificate transaction and submits it to the distributed ledger, as shown in FIG. 3. When a CR requests the role of operator, the CI creates an administrator certificate for the CR, signs the administrator certificate, and further sends the administrator certificate to the CR. Therefore, both the CI and the CR have the administrator certificate. Therefore, either the CI or the CR can sign the issuer certificate transaction and submit it to the distributed ledger, as shown in FIGS. 4 and 5. For an issuer certificate transaction, the issuer certificate transaction includes the submitter's DID, certificate ID, issuer certificate, and submitter's signature. The submitter may be any one of the CR and CI that has the issuer certificate. The certificate ID is a hash value of the issuer certificate. The issuer certificate includes the CR's identification and certificate public key, an optional role for the CR, and a signature signed by the certificate private key of the issuer certificate's certificate signer. The CR's identification is a subject alternative name (SAN), which may be a web address, e.g., www.tbcasoft.com. The CR's role is optional, as it may be provided to applications that need to verify and utilize the role of the issuer certificate associated with the server that owns the issuer certificate. Before publishing the issuer certificate transaction, the submitter of the issuer certificate transaction signs the issuer certificate transaction with their own ledger private key.

[0035] Depending on the role of the certificate request server, step S230 may include different steps that vary depending on the role of the CR. When the role of the CR is trustee, Figure 3 shows a sequence diagram for the CR to request the trustee role, and Figures 4 and 5 show sequence diagrams for the CR to request the operator role. See Figure 6. To suit the role requested by the CR, step S230 includes the following steps:

[0036] Step S231: When the role requested by the CR is a trustee, the CR creates a root certificate. According to the distributed ledger rules that specify that only a server with the role of trustee can add a root certificate, it is the CR that creates the root certificate.

[0037] When the role of the CR is an administrator, step S230 includes the following steps.

[0038] Step S232: When the role requested by the CR is an administrator, the CR sends an administrator certificate signing request (CSR) to the CI. The administrator CSR includes the administrator information and the CR's certificate public key. The administrator information includes fields consisting of the CR's SAN, business name, department name, city, state, country, and contact email.

[0039] Step S233: The CI creates an administrator certificate using the administrator CSR, signs the administrator certificate using the CI's certificate public key, creates the administrator certificate, and sends the administrator certificate to the CR. Because the distributed ledger rules specify that servers with the roles of trustee and operator can add administrator certificates, it is the CI that creates the administrator certificate.

[0040] The difference between Figure 4 and Figure 5 is the server that publishes the issuer certificate transaction. As long as the server has the role to publish the issuer certificate transaction, it should not matter whether the CR or CI publishes the issuer certificate transaction. Since the role to be published is the operator, either the CI that has the role of trustee or operator in Figure 4 or the CR that has the role of operator in Figure 5 can publish the issuer certificate transaction.

[0041] When intending to remove any server or revoke any certificate in the certificate store, the transaction to remove the server or the transaction to revoke the certificate can be published to the distributed ledger. Accordingly, the above method further includes the following steps to remove a server having a role in the distributed ledger and to revoke a certificate. See Figure 2. The above method further includes the following steps to remove and revoke a role and a certificate.

[0042] Step S250: When determining the type of role removal and removing the server with the trustee role, a supermajority of at least one server with the trustee role generates a trustee removal transaction to remove the server, signs the trustee removal transaction, and submits the trustee removal transaction to the distributed ledger. The current step involves an operation to remove the server with the trustee role. The trustee removal transaction includes the server's DID and at least one DID corresponding to the supermajority of the at least one server, and is signed by at least one ledger private key of the supermajority of the at least one server.

[0043] Step S260: When determining the type of role to remove and remove the first server with the role of operator, a second server with the role of trustee or operator and adding the first server to the distributed ledger generates an operator removal transaction to remove the first server from the distributed ledger, signs the operator removal transaction, and submits the operator removal transaction to the distributed ledger. The current step involves an operation to remove the server with the role of operator. The operator removal transaction includes the DID of the second server and the DID of the first server, and is signed with the ledger private key of the second server.

[0044] Step S270: When determining the type of revocation of the issuer certificate of the first server that revokes the certificate in the distributed ledger and has the role of trustee or operator, the second server that has the role of trustee or operator and adds the issuer certificate generates a certificate revocation transaction to revoke the issuer certificate in the distributed ledger, signs the certificate revocation transaction, and submits the certificate revocation transaction to the distributed ledger. Note that when the first server assumes the role of trustee, the second server should also assume the role of trustee, and when the first server assumes the role of operator, the second server may assume the role of trustee or operator. The current steps involve operations to remove the issuer certificate, often the root certificate, when the first server assumes the role of trustee and the second server assumes the role of trustee, or the administrator certificate when the first server assumes the role of operator and the second server assumes one of the roles of trustee or operator. The operator revocation transaction includes the certificate ID of the issuer certificate and the DID of the second server and is signed with the ledger private key of the second server.

[0045] The method for publishing a server certificate to the distributed ledger differs from the previously described method for publishing issuer credentials and certificates in the absence of an issuer credentials transaction, as there is only one transaction to add the server certificate to the distributed ledger. 7, a sequence diagram, shows that a method for publishing a server certificate to a distributed ledger according to the present invention includes the following steps: The distributed ledger is maintained by a distributed ledger network. The distributed ledger network includes multiple servers, two of which are a certificate issuing node (CI) and a certificate request server (CR).

[0046] Step S610: The CI receives certificate-related information from the CR. Since only a server certificate needs to be created, the certificate-related information is all the CI needs from the CR. The certificate-related information includes server information and an authentication public key. The server information includes the CR's Internet Protocol (IP) address and host name.

[0047] Step S620: The CI creates a server certificate for the CR, signs the server certificate, and sends the server certificate to the CR. The server certificate includes the SAN and certification public key of the CR, and is signed by the private key of the CI.

[0048] Step S630: The CI signs the server certificate transaction and submits it to the distributed ledger. The server certificate transaction includes the certificate ID of the server certificate, the server certificate, and the DID of the CI, and is signed by the CI's ledger private key. The certificate IS is a hash value of the server certificate.

[0049] To revoke a server certificate that was added to the distributed ledger, the method for publishing a server certificate to the distributed ledger further includes the following steps:

[0050] The server acting as the operator and adding the server certificate generates a certificate revocation transaction to revoke the server certificate in the distributed ledger, signs the certificate revocation transaction, and submits the certificate revocation transaction to the distributed ledger. The certificate revocation transaction includes the certificate ID of the server certificate and the DID of the server adding the server certificate, and is signed with the ledger private key of the server adding the issuer certificate.

[0051] After implementing the method for adding and removing roles and certificates from the distributed ledger, the next subject of interest is how to use the certificates of the servers associated with each other to verify the authenticity of each other's server certificates to establish a mutually authenticated information exchange. See Figure 8. The method for authenticating the certificates of a Connecting Server (CS) and a Receiving Server (RS) in a distributed ledger network maintaining a distributed ledger according to the present invention includes the following steps from the RS side:

[0052] Step S710: The RS and the CS exchange their identities. The RS's identity is the RS's SAN, and the CS's identity is the CS's SAN. The RS and the CS exchange their SANs with each other. In addition to the identities, in one embodiment, the RS and the CS can further exchange their certificates as shown in FIG. 9.

[0053] Step S720: The RS retrieves the CS's certificate and the CS certificate issuer's public key from the distributed ledger based on the CS identity. The CS identity can be used to retrieve the CS's certificate and the CS certificate issuer's certificate with the CS certificate issuer's public key from the distributed ledger. The CS certificate issuer's public key helps to verify the CS's certificate signed by the CS certificate issuer with the CS certificate issuer's certificate. If the RS's identity cannot be used to retrieve any certificate from the distributed ledger, the distributed ledger can signal that the RS's certificate is not authentic in a quick and easy way.

[0054] Step S730: The RS verifies whether the CS's certificate is authentic using the public key of the CS's certificate issuer. Once the CS's certificate and the CS's certificate issuer's public key are available to the RS, they can be used to directly verify that the CS's certificate is authentic. Alternatively, other verification approaches are available. In one verification approach using an exchanged certificate, the RS further verifies whether both the exchanged CS's certificate and the retrieved CS's certificate match the public key of the CS's certificate issuer. In another verification approach, the RS initializes the CS's certificate as the current certificate, loops to retrieve the next certificate that signs the current certificate using the private key of the certificate issuer of the next certificate, verifies the current certificate using the public key in the next certificate, and determines that the CS's certificate is verified as authentic when the current certificate is valid or the verification condition is met; if not, updates the current certificate to the next certificate. For example, the verification condition may be whether the certificate to be verified is on a pre-approved list.

[0055] After the CS's certificate is verified as authentic, it means that the one-sided certificate authentication on the RS's side is successfully verified, the CS is a trusted server to exchange information with, and the RS willingly sends and receives confidential information to and from the CS.

[0056] The method further includes similar steps for authenticating the RS's certificate as follows:

[0057] Step S740: The CS retrieves the RS's certificate and the RS certificate issuer's public key from the distributed ledger based on the RS's identity.

[0058] Step S750: The CS verifies whether the certificate of the RS is authentic using the public key of the RS certificate issuer.

[0059] Similarly, after the RS's certificate is verified as authentic, it means that the one-sided certificate authentication on the CS's side has been successfully verified, the RS is a trusted server to exchange information with, and the CS willingly sends and receives confidential information to and from the RS.

[0060] Because there is overlap between authenticating the RS's certificate and authenticating the CS's certificate, the detailed description of steps S740 and S750 will not be repeated.

[0061] Having described the above methods in detail, a system for carrying out the above methods is the subject of next discussion. Since there are three methods, namely, a method for publishing issuer credentials and issuer certificates on a distributed ledger, a method for publishing server certificates on a distributed ledger, and a method for authenticating two server certificates in a distributed ledger network, three systems can be provided corresponding to the methods, namely, a distributed ledger-based system for publishing issuer credentials and issuer certificates on a distributed ledger, a distributed ledger-based system for publishing server certificates on a distributed ledger, and a distributed ledger-based system for certificate authentication.

[0062] The participants in a distributed ledger-based system for publishing issuer credentials and issuer certificates are a CR, a CI, and a distributed ledger network. CRs and CIs are servers and nodes, respectively. As a node, a CI may include at least one server when it has the role of trustee quorum, or only one server when it has the role of trustee or operator. The CR and CI may or may not both be part of the distributed ledger network, depending on whether they need to publish transactions to the distributed ledger. When CR10 requests the role of trustee and CI20 assumes the role of trustee quorum, CR10 and CI20 must all remain within the distributed ledger network 30, as shown in FIG. 10, because both CR10 and CI20 publish the root certificate and the transaction to add CR10 with the role of trustee to the distributed ledger. When CR10 requests the role of operator and CI20 assumes the role of trustee, CI20 must always reside within the distributed ledger network 30, while CR10 may or may not reside within the distributed ledger network 30 as issuer certificate transactions may be published by either CR10 or CI20. When issuer certificate transactions are published by CR10, CR10 must also reside within the distributed ledger network 30 as shown in Figure 10. When issuer certificate transactions are published by a CI, CR may reside outside of the distributed ledger network 30 as shown in Figure 11, but must connect to the distributed ledger network 30. As shown in Figure 11, the distributed ledger-based system for publishing server certificates also includes servers CR10 and CI20. CI20 of the system should remain within the distributed ledger network 30, as it is the only server responsible for publishing server certificates to the distributed ledger. Unlike CI20, CR10 does not need to remain within the distributed ledger network 30, as it does not have the role of publishing any transactions. However, CR10 should be connected to the distributed ledger network. For the distributed ledger-based system for certificate authentication shown in Figure 12, the connection server (CS) 40 and receiving server (RS) 50 associated with the system must remain connected to the distributed ledger network 30. Although certificate authentication is a subject that is not related to publishing any transactions, both the connection server (CS) 40 and receiving server (RS) must read from the distributed ledger during the validation process. Additionally, the connection server (CS) 40 and receiving server (RS) are considered to be in a connected state with each other.

[0063] The method and system of the present invention are advantageous in that first, they provide certificate immutability resulting from the fact that the distributed ledger is immutable and shared without being under the control of a single centralized authority, making the distributed ledger solution very well suited to certificate authentication. Second, the history of certificate issuance and revocation is also recorded in the distributed ledger. Regarding certificate availability, the distributed ledger in the distributed ledger network is constantly maintained by a consensus mechanism to ensure consistency across all distributed ledgers in the distributed ledger network, so servers in the distributed ledger network do not need to manage the distributed ledgers in the distributed ledger network.

[0064] Although numerous features and advantages of the present invention have been set forth in the foregoing description, together with details of the structure and function of the invention, the disclosure is illustrative only, and changes may be made in details, particularly as to shape, size, and arrangement of parts, within the scope of the principles of the invention to the fullest extent indicated by the broad general meaning of the terms expressed in the appended claims.

Claims

1. 1. A method for publishing and authenticating an issuer credential and an issuer certificate in a distributed ledger maintained by a distributed ledger network when publishing an issuer credential through a certificate-issuing node (CI) and publishing an issuer certificate through one of the CI and a certificate-requesting server (CR) in communication with the CI, the method comprising: (a) the CI receiving entitlement-related information from the CR; (b) the CI signing an issuer entitlement transaction with the entitlement-related information and submitting the issuer entitlement transaction to the distributed ledger; (c) one of the CR and the CI creating an issuer certificate for the CR, signing the issuer certificate, and sending the issuer certificate to the CR if the signer of the issuer certificate is not the CR; (d) after the issuer entitlement transaction is created on the distributed ledger, one of the CR and the CI, which has the issuer certificate including the entitlement-related information, signs an issuer certificate transaction including the issuer certificate and submits the issuer certificate transaction to the distributed ledger; A method comprising:

2. 2. The method of claim 1, wherein the credential-related information includes the CR's decentralized identifier (DID), ledger public key, and role.

3. 2. The method of claim 1, wherein the issuer entitlement transaction includes the DID and ledger public key of the CR, the DID of the CI, and the role of the CR to be added to the distributed ledger.

4. 10. The method of claim 1, wherein the CI signs the issuer entitlement transaction with the CI's ledger private key.

5. 4. The method of claim 3, wherein the issuer certificate transaction includes a submitter's DID, a certificate ID, the issuer certificate, and the submitter's signature, wherein the certificate ID is a hash value of the issuer certificate, and the issuer certificate includes the CR's identity and certificate public key, an optional role of the CR, and a signature signed by the certificate private key of a certificate signer of the issuer certificate.

6. The method of claim 5, wherein the CR identity is a subject alternative name.

7. 2. The method of claim 1 , wherein an issuer certificate transaction submitter signs the issuer certificate transaction using their own ledger private key, and wherein the distributed ledger network includes the CR when the issuer certificate transaction is submitted by the CR, and wherein the distributed ledger network does not include the CR when the issuer certificate transaction is submitted by the CI.

8. 4. The method of claim 3, wherein the role of the CR to be added to the distributed ledger is trustee, the role of the CI in the distributed ledger is a trustee quorum, the trustee quorum is defined as an issuing role in which a supermajority of at least one server in the distributed ledger has the role of trustee, and the CI includes the supermajority of the at least one server.

9. 9. The method of claim 8, wherein the role of the CR to be added to the distributed ledger is an operator, and the role of the CI in the distributed ledger is the trustee or the operator.

10. 9. The method of claim 8, wherein in step (c), the CR creates the issuer certificate and signs it with the CR's certificate private key that is paired with the CR's certificate public key.

11. 10. The method of claim 9, wherein in step (c), the CI receives an issuer certificate signing request (CSR) from the CR, signs the issuer certificate using the issuer CSR, and signs the issuer certificate using the CI's certificate private key that pairs with the CI's certificate public key, the issuer CSR including operator information and the CR's certificate public key.

12. 12. The method of claim 11, wherein the operator information includes fields consisting of a subject alternative name, a business name, a department name, a city, a state, a country, and a contact email for the CR.

13. When authenticating certificates of a connecting server (CS) and a receiving server (RS) communicatively connected to the distributed ledger network that maintains the distributed ledger, the method comprises: (e) the RS exchanging identities with the CS; (f) the RS retrieves from the distributed ledger a certificate of the CS and a public key of the CS certificate issuer based on the CS identity, the public key being included in the issuer certificate published in the distributed ledger by the CS certificate issuer in the role of one of the CI and the CR together with the qualification-related information in step (d); (g) the RS verifies whether the certificate of the CS is authentic using the public key of the CS certificate issuer; (h) after verifying the authenticity of the certificate of the CS, the RS determines that the CS is authorized to receive private information from the RS; The method of claim 1 , comprising:

14. 14. The method of claim 13, wherein: (1) the CS retrieves the RS's certificate and the RS certificate issuer's public key from the distributed ledger based on the RS's identity; (2) the CS verifies whether the RS's certificate is authentic using the RS certificate issuer's public key; and (3) after the RS's certificate is verified, the CS determines that the RS is authorized to receive secret information from the CS.

15. 15. The method of claim 14, wherein in step (e), the RS further exchanges certificates with the CS.

16. 16. The method of claim 15, wherein in step (g) and step (2), the RS further verifies whether both the exchanged certificate of the CS and the retrieved certificate of the CS match the public key of the CS certificate issuer, and the CS further verifies whether both the exchanged certificate of the RS and the retrieved certificate of the RS match the public key of the RS certificate issuer.

17. The method of claim 13, wherein the CS identity is a subject alternative name of the CS and the RS identity is a subject alternative name of the RS.

18. 14. The method of claim 13, wherein in step (g), the RS initializes the certificate of the CS as a current certificate, loops to retrieve the next certificate that signs the current certificate with the private key of the certificate issuer of the next certificate, verifies the current certificate with the public key in the next certificate, and determines that the current certificate is verified or the certificate of the CS is verified to be authentic when a verification condition is met, and if not, updates the current certificate to the next certificate; and in step (2), the CS initializes the certificate of the RS as a current certificate, loops to retrieve the next certificate that signs the current certificate with the private key of the certificate issuer of the next certificate, and verifies the current certificate with the public key in the next certificate, and determines that the current certificate is verified or the certificate of the RS is verified to be authentic when the verification condition is met, and if not, updates the current certificate to the next certificate.

19. 1. A distributed ledger-based system for publishing and authenticating certificates, comprising: a certificate-requesting server (CR); a distributed ledger network that maintains a distributed ledger and includes a certificate-issuing node (CI) communicatively connected to the CR; Equipped with The CI receives entitlement-related information from the CR, signs an issuer entitlement transaction with the entitlement-related information, and submits the issuer entitlement transaction to the distributed ledger; one of the CR and the CI further creates an issuer certificate for the CR and sends the issuer certificate to the CR if the signer of the issuer certificate is not the CR; After the issuer entitlement transaction is created on the distributed ledger, one of the CR and the CI, which has the issuer certificate including the entitlement-related information, signs an issuer certificate transaction including the issuer certificate and submits the issuer certificate transaction to the distributed ledger. A system characterized by:

20. 20. The system of claim 19, wherein the entitlement-related information includes the CR's decentralized identifier (DID), ledger public key, and role.

21. 20. The system of claim 19, wherein the issuer entitlement transaction includes the CR's DID and ledger public key, the CI's DID, and the CR's role to be added to the distributed ledger.

22. 20. The system of claim 19, wherein the CI signs the issuer entitlement transaction with the CI's ledger private key.

23. 23. The system of claim 22, wherein the issuer certificate transaction includes a submitter's DID, a certificate ID, the issuer certificate, and the submitter's signature, wherein the certificate ID is a hash value of the issuer certificate, and wherein the issuer certificate includes the CR's identity and certificate public key, an optional role of the CR, and a signature signed by the certificate private key of a certificate signer of the issuer certificate.

24. 20. The system of claim 19, wherein an issuer certificate transaction submitter signs the issuer certificate transaction using their own ledger private key, and wherein the distributed ledger network includes the CR when the issuer certificate transaction is submitted by the CR, and wherein the distributed ledger network does not include the CR when the issuer certificate transaction is submitted by the CI.

25. a connection server (CS) communicatively connected to the distributed ledger network; a receiving server (RS) communicatively connected to the distributed ledger network, which exchanges identities with the CS, retrieves the CS's certificate and the CS's certificate issuer's public key from the distributed ledger based on the CS's identity, and verifies whether the CS's certificate is authentic; and when it verifies that the CS's certificate is authentic, determines that the CS is authorized to receive confidential information from the RS; Equipped with The public key is included in the issuer certificate published on the distributed ledger by the CS certificate issuer in the role of one of the CI and the CR along with the qualification-related information.

20. The system of claim 19.

26. The system of claim 25, wherein the CS retrieves the RS's certificate and the public key of the RS certificate issuer from the distributed ledger based on the RS identity, verifies whether the RS's certificate is authentic, and determines that the RS is authenticated to receive secret information from the CS when it verifies that the RS's certificate is authentic.

27. 27. The system of claim 26, wherein the RS further exchanges certificates with the CS.

28. 28. The system of claim 27, wherein the RS verifies whether both the exchanged certificate of the CS and the retrieved certificate of the CS match the public key of the CS certificate issuer, and the CS verifies whether both the exchanged certificate of the RS and the retrieved certificate of the RS match the public key of the RS certificate issuer.

Images