Voucher Authentication Method and System Based on Distributed Ledger

Abstract

The present invention discloses a method and system for a distributed ledger to issue transactions for adding and deleting roles and vouchers. The method and system authenticate vouchers for two interconnected servers. The role defines which server issues what kind of transactions for that role and voucher. When a role is requested, two transactions for adding a role and a voucher for the issuer are issued to the distributed ledger. When a voucher for a server with any role is requested, only the transaction for adding the voucher to the distributed ledger is issued. All transactions are issued through the execution of a voucher request server, a voucher issuing server, and a distributed ledger network that maintains the distributed ledger. The two interconnected servers can confirm the authenticity of each other's identities by retrieving vouchers from the distributed ledger, which has the advantages of voucher immutability and availability of distributed ledger technology.

Description

[0001] Cross-reference

[0002] This application claims the priority of U.S. Provisional Application No. 62 / 923,472, filed on Oct. 18, 2019, entitled "Blockchain-Based Mutual Authentication Connection Management", the entire content of which is incorporated herein by reference. Technical Field

[0003] The present invention relates to a method and system for establishing a communication connection for credential authentication, and more particularly to a method and system for establishing a communication connection for credential authentication using distributed ledger technology. Background Art

[0004] To ensure the security of network connections, mutual authentication is a secure process in which each entity authenticates with each other before communication. In a network environment, both the client and the server must provide credentials to prove their identities. In the mutual authentication process, the client and the server must first exchange, confirm, and trust each other's credentials before establishing a connection. The industry has developed solutions for credential exchange and identity confirmation in the Transport Layer Security (TLS) protocol and the previous Secure Socket Layer (SSL) protocol. The SSL / TLS protocol uses the widely used X.509 certificate, which is a public key certificate defined by the X.509 standard. The X.509 certificate is associated with a cryptographic key pair and has the identity of a website, an individual, or an organization.

[0005] However, the X.509 certificate is not perfect in terms of credential immutability, credential availability, and credential history. Hackers can attack and modify the X.509 certificate. Once the root certificate or any certificate authority (CA) is compromised, the system security will also be compromised. The disadvantage of the X.509 certificate in terms of availability is that the server must have its own certificate database, which will cause data inconsistency between different certificate databases. In terms of credential history, the disadvantage of the X.509 certificate is that the X.509 certificate database does not contain records of all newly added and revoked certificates. Summary of the Invention

[0006] An object of the present invention is to provide a method and system for issuing issuer qualifications and issuer certificates for issuing server certificates to a distributed ledger for performing credential authentication. When confirming the certificates in the distributed ledger, the server certificates are added and deleted in the distributed ledger, and the distributed ledger is maintained by a distributed ledger network to improve credential immutability and credential availability.

[0007] To achieve the above object, the present invention discloses a method for issuing an issuer qualification and an issuer certificate to a distributed ledger maintained by a distributed ledger network included in a credential issuing node (CI) and a credential request server (CR), where the CI and the CR can communicate with each other, and the method includes:

[0008] (a) The CI receives qualification-related data from the CR;

[0009] (b) The CI signs and submits an issuer qualification transaction to the distributed ledger;

[0010] (c) When the signer of the issuer certificate is not the CR, one of the CR and the CI generates and signs an issuer certificate for the CR and sends the issuer certificate to the CR; and

[0011] (d) After the issuer qualification transaction is generated in the distributed ledger, one of the CR and the CI signs an issuer certificate transaction of the issuer certificate and submits the issuer certificate transaction to the distributed ledger.

[0012] To achieve the above object, the present invention discloses a method for issuing a server certificate by a credential issuing server (CI) and a credential request server (CR), where the CI and the CR can communicate with each other and can communicate with a distributed ledger maintained by a distributed ledger network including the CI, and the method includes:

[0013] (a) The CI receives certificate-related data from the CR;

[0014] (b) The CI generates and signs a server certificate for the CR and sends the server certificate to the CR; and

[0015] (c) The CI signs and submits a server certificate transaction to the distributed ledger.

[0016] To achieve the above object, the present invention discloses a method for authenticating a certificate for a connecting server (CS) and a receiving server (RS), where the CS and the RS are connected to each other and can communicate with each other and are connected to a distributed ledger network, and the distributed ledger network maintains a distributed ledger, and the method includes:

[0017] (a) The RS exchanges an identification with the CS;

[0018] (b) The RS retrieves the CS's certificate and the public key of the CS certificate issuer from the distributed ledger according to the CS identification;

[0019] (c) The RS verifies whether the certificate of the CS is authentic with the public key of the CS certificate issuer;

[0020] (d) After the certificate of the CS is verified as authentic, the RS determines that the CS has been authenticated and receives secret data from the RS.

[0021] To achieve the above object, a distributed ledger system for issuing issuer qualifications and issuer certificates includes a certificate request server (CR) and a distributed ledger network.

[0022] The distributed ledger network maintains a distributed ledger, which is communicatively connected to the CR and includes a certificate issuing node (CI). The CI receives qualification-related data from the CR, signs and submits an issuer qualification transaction to the distributed ledger. When a signer of the issuer certificate is not the CR, one of the CR and the CI generates and signs an issuer certificate for the CR and sends the issuer certificate to the CR. After the issuer qualification transaction is generated in the distributed ledger, one of the CR and the CI signs an issuer certificate transaction of the issuer certificate and submits the issuer certificate transaction to the distributed ledger.

[0023] To achieve the above object, a distributed ledger system for issuing server certificates to a distributed ledger includes a certificate request server (CR) and a distributed ledger network.

[0024] The distributed ledger network includes a distributed ledger, and the distributed ledger network is communicatively connected to the CR and includes a certificate issuing server (CI). The CI receives certificate-related data from the CR, generates and signs the server certificate of the CR, sends the server certificate to the CR, and signs and submits a server certificate transaction to the distributed ledger.

[0025] To achieve the above object, the present invention discloses a certificate authentication system for a distributed ledger, including a distributed ledger network, a connection server (CS) and a receiving server (RS).

[0026] The distributed ledger network maintains a distributed ledger.

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

[0028] The RS is communicatively connected to the distributed ledger network, exchanges an identity with the CS, retrieves a CS's credential and a public key of a CS credential issuer from the distributed ledger based on a CS identity to confirm whether the CS's credential is authentic. When the CS's credential is confirmed to be authentic, the RS determines that the CS has been authenticated and receives secret data from the RS.

[0029] According to the above description, all servers with or without roles have individual credentials, which are added or deleted from the distributed ledger by an authorized server. The role in the distributed ledger defines which role of servers has the power to add or delete which roles and credentials, thereby preventing unauthorized individuals from destroying the credentials and roles in the distributed ledger. And the distributed ledger has a decentralized nature. Since there is no centralized entity that can be the target of malicious attacks, the present invention is more secure. In addition, since the distributed ledger can be globally deployed in a replicated mode to avoid single points of failure. Therefore, the roles and credentials published to the distributed ledger can benefit from the immutability of the distributed ledger. According to the consensus mechanism, the credentials and roles in the distributed ledger can be updated quickly at any time, and inconsistencies in the credentials and roles in the distributed ledger will no longer occur. Therefore, adding credentials to the distributed ledger by the method and system of the present invention requires servers to identify each other by means of credential authentication, which is extremely important for enhancing the security of server communication. Furthermore, the transparency of the distributed ledger is also regarded as an advantage. The distributed ledger can make all stored data easily accessible, improving the transparency of mutual credential authentication when servers communicate.

[0030] Other objects, advantages and novel technical features of the present invention are further described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A block diagram illustrating the relationship between server roles and credentials generated by servers according to the present invention;

[0032] Figure 2 A flowchart illustrating a method of publishing issuer qualifications and issuer credentials to a distributed ledger according to the present invention;

[0033] Figure 3 To illustrate Figure 2 A flowchart of the method in which the CR requests to become a trustee role and the CI is a trustee group role;

[0034] Figure 4 To illustrate Figure 2Flowchart of an embodiment of a method for a CR to request an operator role and a CI to be a trustee role;

[0035] Figure 5 For illustration Figure 2 Flowchart of another embodiment of a method for a CR to request an operator role and a CI to be a trustee role;

[0036] Figure 6 For illustration Figure 2 Step flowchart of a method for generating an issuer certificate;

[0037] Figure 7 Flowchart of a method for publishing a server certificate to a distributed ledger according to the present invention;

[0038] Figure 8 Flowchart of an embodiment of a method for authenticating certificates of a connection server and a receiving server according to the present invention;

[0039] Figure 9 For illustration Figure 8 Another embodiment flowchart of the method;

[0040] Figure 10 Network structure diagram of an embodiment of a distributed ledger system for publishing an issuer qualification and an issuer certificate according to the present invention;

[0041] Figure 11 For illustration Figure 9 Network structure diagram of another embodiment of the distributed ledger system and a distributed ledger system of a publishing server certificate; and

[0042] Figure 12 Network structure diagram of a distributed ledger network for authenticating certificates. Detailed implementation manners

[0043] The terms used herein are used to describe the details in specific embodiments of the present invention, and all terms should be interpreted reasonably in the broadest scope. Certain terms will be emphasized below; any restrictive terms will be defined by specific embodiments.

[0044] The embodiments described below can be implemented by a programmable circuit program, or by software and / or hardware configuration, or entirely by special function circuits, or a combination of the above. The special function circuits (if included in this case) can be implemented in the following forms, for example: one or more application specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), etc.

[0045] Each server in the present invention has a credential of its identity, which is stored in a distributed ledger maintained by a distributed ledger network. The credential of the first server is submitted to a second server connected to the first server to confirm the authenticity of the credential. After the credential is confirmed, the second server trusts the first server and sends secret data to the first server. Similarly, the second server can also provide its credential to the first server for confirmation. Only the server with the issuer qualification can add or delete credentials from the distributed ledger. Therefore, the issuer qualification should be added or deleted from the distributed ledger to monitor which server can add or delete what kind of issuer qualification and credentials. The distributed ledger rules are responsible for defining the types of server issuer qualifications, adding and deleting corresponding transactions, or revoking the issuer qualifications and credentials of other servers.

[0046] Briefly, the embodiments described herein relate to a method and system for issuing issuer qualifications and credentials in a distributed ledger for use as credential authentication. To achieve credential authentication for any two connected servers, the retrieved credential from the distributed ledger can be confirmed for its existence or whether the retrieved credential matches the exchanged credential based on the server's identity recognition and the credentials exchanged by the servers, which can serve as the basis for the data for initiating authentication transmitted between the servers. The distributed ledger is adopted herein because of its advantages of credential trust and immutability; moreover, the technical core lies in a credential storage area in the distributed ledger that stores multiple issuer qualifications and credentials. As its name implies, the server with the issuing authority has the issuer qualification, and this server can add or delete issuer qualifications and the credentials of other servers in the distributed ledger. There are also credentials of servers with issuer qualifications or issuer roles in the distributed ledger, while servers without issuer qualifications can only maintain their credentials in the distributed ledger. When adding a server with an issuer role, the transactions for adding the server's credential and the transaction for adding the server's issuer role are issued through the interaction between the distributed ledger, and a credential request server (CR) and a credential issuing node (CI), which are two of the multiple servers in the distributed ledger network. When adding a server without an issuer role, the transaction for adding the server's credential is issued to the distributed ledger. In addition to issuing transactions, the implementation herein also involves signing and confirming transactions with a ledger key pair, and signing and confirming credentials with a credential key pair. When an issuer role or a credential is deleted or invalidated from the distributed ledger, the transaction for deleting the issuer role or revoking the credential is issued to the distributed ledger. The method and system in the present invention will be further described below.

[0047] The object of the present invention is to emphasize that only the issuer can sign or issue a credential. To achieve this object, the present invention includes two issuer roles, which are the Trustee and the Operator; and three types of credentials, namely the root credential, the administrator credential, and the server credential. Although all credentials must be issued to the distributed ledger; in the permitted distributed ledger network, only the server with the issuer role can issue credentials for other servers and issue the issuer role. The issuer roles of the Trustee and the Operator represent that they are trusted, and the administrator executed by each location control server is authorized to issue credentials and the issuer role. For simplicity, the term "role" will replace the "issuer role" herein. The server with the Trustee role, the Operator role, and the server without a role respectively have a root certificate, an administrator credential, and a server credential. Despite different names, from the perspective of the common data field, the above three types of credentials are basically the same, except for the different methods of using the public key for verification. The root credential and the administrator credential belong to the issuer credentials, and their public keys can be used to verify the credentials signed by the issuer of the issuer credential, while the public key in the server credential cannot be used to verify other credentials, because the server with the server credential has no right to issue any credentials and there is no credential signed by any server with the server credential.

[0048] The signing relationship between each credential and the signer credential is that the issuer credential signs and verifies the credential signed by the issuer. For any verified credential, the issuer credential that signs the credential can safely find it from the distributed ledger to verify the credential, and this verification process can be traced back to the original credential, that is, the root credential. Please refer to Figure 1 , which describes examples of the types of credentials and entities with the issuer role. The square on the left is the server with the issuer role in the distributed ledger network, and the square on the right represents the three types of credentials issued by the authorized server to the distributed ledger. As Figure 1 shown, the server with the Operator role is responsible for issuing transactions for adding its administrator credential and the server credentials of other servers, and does not act as the issuer role of the distributed ledger. The server with the Trustee role has the right to issue transactions for adding its root credential to the distributed ledger. In Figure 1Three different types of vouchers in the distributed ledger are shown on the right side. Each administrator voucher can be used to confirm the server vouchers signed by the administrator voucher, and the root voucher can be used to confirm the administrator vouchers signed by the server that issued the root voucher. The confirmation process of the vouchers can start at the location of any server voucher or administrator voucher and end at the root voucher; other intermediate administrator vouchers (if any) between the server voucher or administrator voucher and the root voucher are confirmed in sequence. At the same time, the confirmation process does not need to be executed until the root voucher, and can be terminated as long as the conditions are met or not met. The conditions include (but are not limited to) whether the voucher being confirmed is in the pre-approved list or the start and end of the confirmation are within the same voucher. In any case, the number of servers with the roles of trustee and operator, the number of root vouchers, administrator vouchers, and server vouchers, and the voucher hierarchical structure are not limited to Figure 1 。

[0049] The following table describes the rules for which roles in the distributed ledger can publish which transactions to the distributed ledger, which more details the relationship between the roles and the vouchers.

[0050] Distributed Ledger Rule Table

[0051]

[0052] According to the above table, a server with the role of trustee has the right to publish transactions for adding and deleting operator roles, root vouchers, and administrator vouchers of servers related to the distributed ledger. It should be noted that a server with the role of trustee does not have the right to add or invalidate the server vouchers of other servers. A server with the role of trustee does not have the right to publish transactions for adding and deleting the trustee roles of other servers alone, unless the server is the only server with the role of trustee in the distributed ledger. And a server with the role of Trustee Quorum (which is defined as the role of the aggregate of the absolute majority of at least one server in the distributed ledger, and at least one of these servers has the role of trustee) has the right to publish transactions for adding and deleting servers with the role of trustee. Contrary to the trustee role, a server with the role of operator has the right to publish transactions for adding, deleting, or revoking operator roles, administrator vouchers, and server vouchers of other servers in a distributed ledger. It should be noted that both a server with the role of trustee and a server with the role of operator can publish transactions for adding, deleting, and revoking server operator roles and administrator vouchers. A server without a role has no right to publish any transactions.

[0053] Before the voucher storage area in a distributed ledger with an issuer role and vouchers is mature enough for voucher authentication for two connected servers, it is a priority to issue transactions for adding and deleting roles and vouchers. When the voucher storage area is just established, a genesis transaction is issued to the voucher storage area to generate the first server with a trustee role. The genesis transaction includes the decentralized identifier (DID) of the trustee, the public key for the distributed ledger signature to confirm any transaction issued by the trustee, and the trustee role.

[0054] Please refer to Figure 2 , which provides an embodiment of a method for issuing an issuer qualification and issuer vouchers to a distributed ledger according to the present invention. The method in this embodiment involves a voucher request server (CR) and a voucher issuing node (CI), both of which are part of a distributed ledger network. The CI may include one or more servers. The method is adopted when the CI is a node with a trustee role group or trustee role in the distributed ledger and the CR requests to be added to the distributed ledger as a trustee or operator in the trustee role. In this method, servers and server vouchers without any role are not discussed for the time being. The transactions issued to the distributed ledger may be intended to add or delete roles and vouchers, and the method includes the following steps S210 to S240:

[0055] Step S200: The CI determines the type of the transaction to be issued. The types of transactions include adding roles and vouchers, deleting roles, and invalidating vouchers.

[0056] Step S210: When determining the type of the transaction for adding a new role and credential, the CI receives eligibility-related data from the CR. In the transaction for adding the issuer eligibility or role of the CR, the eligibility-related data is necessary. The eligibility-related data is added to the distributed ledger and includes the DID, the ledger public key, and the role of the CR. Basically, each server with a role in the credential storage area has a ledger key pair and a credential key pair, both of which are asymmetric key pairs. The ledger pair has a ledger public key and a ledger private key, and the credential pair has a credential public key and a credential private key. The ledger private key related to the server is stored in the server, and the server uses the ledger private key to sign the transaction to be published to the credential storage area. The ledger public key related to the server is transmitted to the transaction for adding a new server to the distributed ledger, and this transaction can be the current step of adding the CR. Therefore, the distributed ledger can confirm any subsequent transaction signed by the server using the server's ledger public key. On the other hand, the server signs the credentials of other servers using the server's credential private key, and the credentials can be one of the administrator credential and the server credential. The server's credential public key is included in the server's credential to confirm the credentials of other servers signed by the server.

[0057] Step S220: The CI signs and submits the issuer eligibility transaction to the distributed ledger. The issuer eligibility transaction logs the CR on the distributed ledger. The issuer eligibility transaction includes the DID and the ledger public key of the CR, the DID of the CI, and the role of the CR to be added to the distributed ledger, and the issuer eligibility transaction is signed by the CI's ledger private key. According to the above-mentioned distributed ledger rule table, the CR can request to become a trustee role or an operator, and the CI can request to become a trustee role group or a trustee. When the CR requests to become a trustee role, the CI should become a trustee role group and include at least one server. When the CR requests to become an operator role, the CI can become a trustee role or an operator and be a single server.

[0058] Step S230: One of the CR and the CI generates and signs the issuer credential of the CR and sends the issuer credential to the CR when the signer of the issuer credential is not the CR. When the CR requests to become a trustee role, the CR generates and signs the issuer credential, and the issuer credential is the root credential. When the CR requests to become an operator role, the CI generates and signs the issuer credential, and the issuer credential is the administrator credential. Depending on the role request of the CR, the issuer credential is signed by the credential private key of one of the CR and the CI, and the CR and the CI generate the issuer credential. When the generator of the issuer credential is the CI, the CI must send the issuer credential to the CR for storage and subsequent confirmation.

[0059] Step S240: After a certifier qualification transaction is generated in the distributed ledger, any one of the CR and CI with a certifier credential signs the certifier credential transaction and submits the certifier credential transaction to the distributed ledger. Only after the certifier qualification transaction is generated in the distributed ledger, the certifier qualification transaction shall be signed and submitted to the distributed ledger. When the CR requests to become a trustee role, the CR generates its own root credential, and only the CR has the root credential; thus as Figure 3 shown, the CR signs and submits the certifier credential transaction to the distributed ledger. When the CR requests to become an operator role, the CI generates and signs an administrator credential for the CR and further sends the administrator credential to the CR. Both the CI and the CR have the administrator credential. Therefore, either the CI or the CR can sign and submit the certifier credential transaction to the distributed ledger, as Figures 4-5 shown. The certifier credential transaction includes the DID of the submitter, the credential identification, the certifier credential, and the submitter's signature. The submitter can be either the CR or the CI and has a certifier credential. The credential identification is the hash value of the certifier credential. The certifier credential includes the identity identification and the public credential key of the CR, the optional role of the CR, and the signature signed by the private credential key of the credential signer of the certifier credential. The identity identification of the CR is a Subject Alternative Name (SAN), which can be a website, for example: www.tbcasoft.com. The role of the CR is optional and is necessary to confirm and use the certifier credential role related to the server having the certifier credential. Before publishing the certifier credential transaction, the submitter of the certifier credential transaction signs the certifier credential transaction with its ledger private key.

[0060] Depending on the role of the credential request server, step S230 may include different steps. When the role of the CR is a trustee, Figure 3 Flowchart illustrating the CR's request to become a trustee role, Figure 4 and 5 Flowchart illustrating the CR's request to become an operator role. Please refer to Figure 6 , for implementing the role requested by the CR, step S230 includes the following steps:

[0061] Step S231: When the role requested by the CR is a trustee, the CR generates a root credential. The CR generates a root credential. In the present invention, the distributed ledger rules stipulate that only a server with a trustee role can add a root credential.

[0062] When the role of the CR is an operator, step S230 includes the following steps:

[0063] Step S232: When the role requested by the CR is the operator, the CR sends a Certificate Signing Request (CSR) for the administrator to the CI. The administrator CSR contains the operator data and the public key of the CR's certificate. The operator data includes the SAN of the CR, company name, department name, city, state or province, country, and contact email address.

[0064] Step S233: The CI generates an administrator certificate with the administrator CSR and signs the administrator certificate with the public key of the CI's certificate, generates the administrator certificate, and sends the administrator certificate to the CR. The CI generates the administrator certificate. In the present invention, the distributed ledger rules stipulate that a server with the role of trustee or operator can add an administrator certificate.

[0065] Figure 4 and 5 The difference lies in the server that publishes the issuer certificate transaction. As long as the server has the role of publishing the issuer certificate transaction, either the CR or the CI can publish the issuer certificate transaction. When the role to be published is the operator, Figure 4 the CI with the role of trustee in Figure 5 or the CR with the role of operator in

[0066] Figure 2

[0067]

[0068] Step S250: When determining the type of role to be deleted and deleting a server with the role of trustee, an absolute majority of at least one server with the role of trustee generates a trustee deletion transaction to delete the server, signs the trustee deletion transaction, and submits the trustee deletion transaction to the distributed ledger. This step involves deleting a server with the role of trustee. The trustee deletion transaction includes the DID of the server and the DID of at least one corresponding to the absolute majority of at least one server, and the trustee deletion transaction is signed by at least one ledger private key of the absolute majority of at least one server;

[0068] Step S260: When determining the type of the deleted role and the first server having the operator role, the second server generates an operator deletion transaction to delete the first server from the distributed ledger, signs the operator deletion transaction, and submits the operator deletion transaction to the distributed ledger. The second server originally has the trustee role or is an operator and adds the first server to the distributed ledger. The current step involves deleting the server having the operator role. The operator deletion transaction includes the DID of the second server and the DID of a first server, and the operator deletion transaction is signed by the ledger private key of the second server.

[0069] Step S270: When determining the type of the revoked credential and the issuer credential of the first server having the trustee role or being an operator in the distributed ledger, the second server having the trustee role or being an operator and adding the issuer credential generates a credential revocation transaction to revoke the issuer credential from the distributed ledger, signs the credential revocation transaction, and submits the credential revocation transaction to the distributed ledger. When the first server has the trustee role, the second server should also have the trustee role, and when the first server has the operator role, the second server can have the trustee role or be an operator. The current step involves deleting the issuer credential, and the issuer credential may be a root credential or a manager credential, which is a root credential when the first server has the trustee role and the second server has the trustee role; and is a manager credential when the first server has the operator role and the second role is the trustee or the operator. The credential revocation transaction includes the issuer credential and the credential identification of the DID of the second server, and the credential revocation transaction is signed by the ledger private key of the second server.

[0070] Since there is only one transaction for adding a server credential to the distributed ledger, the method of publishing the server credential to the distributed ledger is different from the method of publishing the issuer qualification credential described above in that the issuer qualification transaction is omitted. Figure 7 is a flowchart illustrating the method of publishing a server credential to a distributed ledger according to the present invention, which includes the following steps. The distributed ledger network maintains a distributed ledger. The distributed ledger network includes a plurality of servers, two of which are a credential issuer node (CI) and a credential request server (CR).

[0071] Step S610: The CI receives credential-related data from the CR. Only the server credential needs to be generated here, and the CI only needs to obtain the credential-related data from the CR. The credential-related data includes server data and an authentication public key. The server data includes the Internet Protocol (IP) address and the CR host name.

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

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

[0074] To invalidate the server certificate newly added to the distributed ledger, the method of publishing the server certificate to the distributed ledger further includes the following steps:

[0075] The server with the operator role and adding the server certificate generates a certificate revocation transaction to invalidate the server certificate from the distributed ledger, signs the certificate revocation transaction, and submits the certificate revocation transaction to the distributed ledger. The certificate revocation transaction includes the server certificate and the certificate identification of the DID of the server adding the server certificate. The certificate revocation transaction is signed by the ledger private key of the server adding the issuer certificate.

[0076] After discussing how to add and delete roles and certificates from the distributed ledger, next, we will discuss how to use the certificates of servers connected to each other to confirm the authenticity of the server certificate to achieve mutual authentication of data exchange. Please refer to Figure 8 , the method for authenticating the certificates of the connecting server (CS) and the receiving server (RS) in the distributed ledger network. The distributed ledger network maintains a distributed ledger according to the present invention. The method includes the following steps at the RS side:

[0077] Step S710: RS and CS exchange their identities. The identity of RS is the SAN of RS, and the identity of CS is the SAN of CS. RS and CS exchange their SANs with each other. In addition to the identity, in some embodiments, RS and CS may further exchange their certificates, as Figure 9 shown.

[0078] Step S720: RS retrieves the certificate of CS and the public key of the CS certificate issuer from the distributed ledger according to the CS identity. The CS identity can be used to retrieve the certificate of CS and the certificate of the CS certificate issuer from the distributed ledger. The certificate has the public key of the CS certificate issuer. The public key of the CS certificate issuer is used to confirm the certificate of CS, and the certificate is signed by the CS certificate issuer with the certificate of the CS certificate issuer. If the certificate cannot be retrieved from the distributed ledger using the identity of RS, it means that the certificate of RS is not authentic.

[0079] Step S730: The RS confirms whether the CS's certificate is authentic with the public key of the CS certificate issuer. When the CS's certificate and the public key of the CS certificate issuer are accessible to the RS, the CS's certificate and the public key of the CS certificate issuer can be directly used to confirm whether the CS's certificate is authentic. Other confirmation methods are included in the present invention. One of the confirmation methods is to use the exchanged certificate, and the RS further confirms whether both the exchanged CS's certificate and the retrieved CS's certificate match the public key of the CS certificate issuer. In another confirmation method, the RS initializes the CS's certificate as the current certificate and retrieves the next certificate in a loop. The next certificate signs the current certificate with the private key of the next certificate's issuer, and the public key in the next certificate is used to confirm the current certificate. When the current certificate has been confirmed or a confirmation condition has been met, it is determined that the CS's certificate is confirmed as authentic; otherwise, the current certificate is updated to the next certificate. For example, the confirmation condition can be whether the certificate to be confirmed is on a pre-approved list.

[0080] After the CS's certificate is confirmed as authentic, this indicates that the unilateral certificate authentication on the RS side has successfully confirmed the CS as a trustworthy server for exchanging data, and the RS is willing to send and receive secret data from the CS.

[0081] This method further includes the following steps similar to the RS's certificate authentication.

[0082] Step S740: The CS retrieves the RS's certificate and the public key of the RS certificate issuer from the distributed ledger according to the RS identity.

[0083] Step S750: The CS confirms whether the RS's certificate is authentic with the public key of the RS certificate issuer.

[0084] Similarly, after the RS's certificate is confirmed as authentic, this indicates that the unilateral certificate authentication on the CS side has successfully confirmed the RS as a trustworthy server for exchanging data, and the CS is willing to send and receive secret data from the RS.

[0085] Since the certificate authentications of the RS and the CS are similar, the details of steps S740 and S750 will not be elaborated here.

[0086] After describing the above methods, the systems for implementing the above methods will be further described. As the present invention discloses three methods for issuing issuer qualifications and issuer certificates to a distributed ledger, issuing server certificates to a distributed ledger, and authenticating certificates between two servers in a distributed ledger network, the present invention discloses three systems corresponding to the individual methods; namely, a distributed ledger system for issuing issuer qualifications and issuer certificates to a distributed ledger, a distributed ledger system for issuing server certificates to a distributed ledger, and a distributed ledger system for certificate authentication.

[0087] The distributed ledger system for issuing issuer qualifications and issuer certificates involves a CR, a CI, and a distributed ledger network. The CR and the CI are a server and a node respectively. When the CI has a group of trustee roles, it includes at least one server; and when the CI has a trustee role or is an operator, it can be a single server. Depending on whether the CR and the CI need to issue transactions to the distributed ledger, the CR and the CI can be part of the distributed ledger network or not. When the CR10 requests to become a trustee role and the CI20 becomes a group of trustee roles, both the CR10 and the CI20 must remain in the distributed ledger network 30, as Figure 10 shown. This is because both the CR10 and the CI20 are for adding root certificates and the CR10 has a trustee role to issue transactions to the distributed ledger. Since the issuer certificate transaction can be issued by the CR10 or the CI20, when the CR10 requests to become an operator role and the CI20 has a trustee role, the CI20 must remain in the distributed ledger network 30, while the CR10 does not necessarily need to remain in the distributed ledger network 30. When the issuer certificate transaction is issued by the CR10, the CR10 must remain in the distributed ledger network 30, as Figure 10 shown. When the issuer certificate transaction is issued by the CI, the CR does not need to remain in the distributed ledger network 30, as Figure 11 shown, but it must be connected to the distributed ledger network 30. The distributed ledger system for issuing server certificates also includes the CR10 and the CI20, both of which are servers. The CI20 is the only role with the right to issue server certificates to the distributed ledger, so the CI20 must remain in the distributed ledger network 30. Unlike the CI20, the CR10 does not have a role in issuing transactions, so there is no need for it to remain in the distributed ledger network 30. Nevertheless, the CR10 still needs to be connected to the distributed ledger network. As Figure 12As shown, in a distributed ledger system for voucher authentication, the connection server (CS) 40 and the receiving server (RS) 50 must be connected to the distributed ledger network 30. Voucher authentication is directly related to the release transaction. Both the connection server (CS) 40 and the receiving server (RS) must read the distributed ledger during the confirmation process. In addition, both the connection server (CS) 40 and the receiving server (RS) need to be connected to each other.

[0088] Since the distributed ledger is immutable and not controlled by a single centralized administrator, the methods and systems in the present invention can provide vouchers with immutability, which makes the distributed ledger conducive to voucher authentication. Moreover, the voucher issuance and cancellation history are also recorded in the distributed ledger. In terms of voucher availability, since the distributed ledger is jointly maintained by common institutions, the servers in the distributed ledger network do not need to manage the distributed ledger, which also ensures the consistency of the distributed ledger.

[0089] Although many technical features and advantages of the present invention have been described above, the disclosed functions and detailed structures are all exemplary illustrations. Without departing from the spirit of the present invention, the broadest interpretation of the scope of the claims of the present invention covers improvements obtained by changing the shape, size, and component configuration of the present invention based on the teachings of this specification.

Claims

1. A method for issuing issuer qualifications and vouchers for a distributed ledger to authenticate vouchers. When an issuer qualification and a voucher request server CR and one of the CIs issue an issuer voucher to the distributed ledger via a voucher issuing node CI, the CI and the CR can communicate with each other. The distributed ledger is maintained by a distributed ledger network, and the distributed ledger network includes the CI. The method includes: (a) The CI receives qualification-related data from the CR; (b) The CI signs and submits an issuer qualification transaction to the distributed ledger; (c) One of the CR and the CI generates and signs an issuer voucher for the CR and, when a signer of the issuer voucher is not the CR, transmits the issuer voucher to the CR; and (d) After the issuer qualification transaction is generated in the distributed ledger, one of the CR and the CI having the issuer voucher signs the issuer voucher transaction and submits the issuer voucher transaction to the distributed ledger; Among them, The issuer voucher transaction includes the issuer voucher, and the issuer qualification transaction includes the qualification-related data.

2. The method according to claim 1, wherein the data related to the qualification includes a distributed identifier DID, a ledger public key, and the role of the CR.

3. The method according to claim 1, wherein The issuer qualification transaction includes the DID added to the distributed ledger and one of the ledger public keys of the CR, the DID of the CI, and the role of the CR.

4. The method according to claim 1, wherein, The CI signs the issuer qualification transaction with the ledger private key of the CI.

5. The method according to claim 3, wherein the issuer voucher transaction includes the DID of the submitter, voucher identification, the issuer voucher, and a signature of the submitter. The voucher identification is a hash value of the issuer voucher. The issuer voucher includes an identification and the voucher public key of the CR, an optional role of the CR, and a signature signed by the voucher private key of the voucher signer of the issuer voucher.

6. The method according to claim 5, wherein the identification of the CR is the subject alternative name.

7. The method according to claim 1, wherein the submitter of the issuer voucher transaction signs the issuer voucher transaction with its ledger private key. When the issuer voucher transaction is submitted by the CR, the distributed ledger network includes the CR, and when the issuer voucher transaction is submitted by the CI, the distributed ledger network does not include the CR.

8. The method according to claim 3, wherein the role of the CR to be added to the distributed ledger is the trustee, and the role of the CI in the distributed ledger is the trustee group. The trustee group is defined as the majority of the issuer roles of at least one server having the trustee role in the distributed ledger, and the CI includes the majority of the at least one server.

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

10. The method according to claim 8, wherein in step (c), the CR generates the issuer certificate and signs the issuer certificate with a certificate private key of the CR, and the certificate private key of the CR can be paired with the certificate public key of the CR.

11. The method according to claim 9, wherein in step (c), the CI receives an issuer certificate signing request CSR from the CR, generates the issuer certificate with the issuer CSR, and signs the issuer certificate with a certificate private key of the CI, and the certificate private key of the CI can be paired with the certificate public key of the CI, wherein the issuer CSR includes operator data and the certificate public key of the CR.

12. The method according to claim 11, wherein the operator data includes the subject alternative name of the CR, company name, department name, city, state or province, country, and contact email box of the CR.

13. The method according to claim 1, when authenticating the certificates of the connection server CS and the receiving server RS, the CS and the RS are interconnected and communicable with each other and are communicably connected to the distributed ledger network, the method includes: (e) The RS and the CS exchange identifications; (f) The RS retrieves the certificate of the CS and the public key of the CS certificate issuer from the distributed ledger according to the CS identification; (g) The RS confirms whether the certificate of the CS is authentic with the public key of the CS certificate issuer; and (h) After the certificate of the CS is confirmed to be authentic, the RS determines that the CS has been authenticated and receives secret data from the RS.

14. The method according to claim 13, wherein: (1) According to the RS identification, the CS retrieves the certificate of the RS and the public key of the RS certificate issuer from the distributed ledger; (2) The CS confirms whether the certificate of the RS is authentic with the public key of the RS certificate issuer; and (3) After the certificate of the RS is confirmed, the CS determines that the RS has been authenticated and receives secret data from the CS.

15. The method according to claim 14, wherein in step (e), the RS further exchanges a certificate with the CS.

16. The method according to claim 15, wherein in steps (g) and (2), the RS further confirms whether the exchanged certificate of the CS and the retrieved certificate of the CS match with the public key of the CS certificate issuer, and the CS further confirms whether the exchanged certificate of the RS and the retrieved certificate of the RS match with the public key of the RS certificate issuer.

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

18. The method according to claim 14, wherein, In this step (g), the RS initializes the certificate of the CS as a current certificate and iteratively retrieves the next certificate, where the next certificate signs the current certificate with a private key of a certificate issuer of the next certificate, verifies the current certificate using the public key in the next certificate, and determines that the certificate of the CS is verified as genuine when the current certificate has been verified or a verification condition has been met; otherwise, updates the current certificate to the next certificate; and In this step (2), the CS initializes the certificate of the RS as the current certificate and iteratively retrieves the next certificate, where the next certificate signs the current certificate with a private key of a certificate issuer of the next certificate, verifies the current certificate using the public key in the next certificate, and determines that the certificate of the RS is verified as genuine when the current certificate has been verified or a verification condition has been met; otherwise, updates the current certificate to the next certificate.

19. A distributed ledger system for issuing issuer qualifications and certificates for a distributed ledger to authenticate certificates, comprising: A certificate request server CR; and A distributed ledger network that maintains a distributed ledger, is communicatively connected to the CR, and includes a certificate issuing node CI; Wherein, The CI receives qualification-related data from the CR, signs and submits an issuer qualification transaction to the distributed ledger; One of the CR and the CI generates and signs an issuer certificate for the CR and transmits the issuer certificate to the CR when a signer of the issuer certificate is not the CR; After the issuer qualification transaction is generated in 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; wherein the issuer certificate transaction includes the issuer certificate, and the issuer qualification transaction includes the qualification-related data.

20. The system according to claim 19, wherein the qualification-related data includes a distributed identifier DID of the CR, a ledger public key, and a role.

21. The system according to claim 19, wherein the issuer qualification transaction includes the DID and ledger public key of the CR added to the distributed ledger, the DID of the CI, and the role of the CR.

22. The system according to claim 19, wherein the CI signs the issuer qualification transaction with a ledger private key of the CI.

23. The system according to claim 22, wherein the issuer certificate transaction includes the DID of the submitter, a certificate identifier, the issuer certificate, and a signature of the submitter, where the certificate identifier is a hash value of the issuer certificate, and the issuer certificate includes an identity and a certificate public key of the CR, an optional role of the CR, and a signature signed with a certificate private key of the certificate signer of the issuer certificate.

24. The system according to claim 19, wherein the issuer vouches for the transaction submitter to sign the issuer voucher transaction with its ledger private key, and when the CR submits the issuer voucher transaction, the distributed ledger network includes the CR, and when the CI submits the issuer voucher transaction, the distributed ledger network does not include the CR.

25. The system according to claim 19, comprising: A connection server CS communicatively connected to the distributed ledger network; and A receiving server RS communicatively connected to the distributed ledger network, exchanging an identification with the CS, retrieving the CS's voucher and the public key of the CS voucher issuer from the distributed ledger based on the CS identification to confirm whether the CS's voucher is authentic, the RS initializes the CS's voucher as a current voucher and cyclically retrieves a next voucher, wherein the next voucher signs the current voucher with a private key of a voucher issuer of the next voucher, uses the public key in the next voucher to confirm the current voucher, and when the current voucher has been confirmed or a confirmation condition has been met, determines that the CS's voucher is confirmed as authentic, otherwise, updates the current voucher to the next voucher, and when the CS's voucher is confirmed as authentic, determines that the CS has been authenticated and receives secret data from the RS.

26. The system according to claim 25, wherein the CS retrieves the RS's voucher and the public key of the RS voucher issuer from the distributed ledger based on the RS identification to confirm whether the RS's voucher is authentic, and when the RS's voucher is confirmed as authentic, determines that the RS has been authenticated to receive secret data from the CS.

27. The system according to claim 26, wherein the RS further exchanges a voucher with the CS.

28. The system according to claim 27, wherein the RS confirms whether the exchanged CS voucher and the retrieved CS voucher match with the public key of the CS voucher issuer, and the CS confirms whether the exchanged RS voucher and the retrieved RS voucher match with the public key of the RS voucher issuer.

Images