Systems and methods for notary agent for public key infrastructure names

A method, system, and apparatus for managing digital certificates, managing a certificate authority (CA), and cross-referencing CA hierarchies. The method includes receiving, by a processor of a CA computing system, at least one of a digital certificate generation request and a digital certificate revocation from a user via a user computing device, the digital certificate generation request including a user public key and a user identity. The method further includes generating a digital certificate for the user and signing the digital certificate with a CA private key, wherein the CA private key is associated with a known CA public key. The method further includes publishing the digital certificate signed with the CA private key to a digital certificate blockchain, determining a certificate status of the digital certificate, and publishing an update to the digital certificate blockchain to reflect the certificate status of the digital certificate.

TECHNICAL FIELD

Embodiments of the present disclosure relate generally to the field of digital certificates.

BACKGROUND

A blockchain is a publicly viewable, append-only, distributed ledger having wide application in the financial services industry. A blockchain includes multiple blocks, each containing data and a hash of the previous block, thereby linking the blocks in the blockchain. Blockchain entries consist of blocks of information that can include transactions, transaction record components, transaction entities, and the like.

A CA is an entity trusted by one or more other entities to create and assign digital certificates. The CA can include multiple CAs issuing certificates, including a root CA (e.g., trust anchor), at least one intermediate CA, and an issuing CA.

A digital certificate is an electronic document used to prove ownership of a public key. Digital certificates, also known as public key certificates, include the public key and the identity of an entity. Digital certificates are issued by a CA, which signs the digital certificate with the CA private key to render the digital certificate unforgeable, allowing for secure transactions between entities using the digital certificate.

A public key infrastructure (PKI) is a set of roles, policies, and procedures used to create, manage, use, store, and revoke digital certificates and manage public key encryption. A PKI facilitates secure electronic transfer of information for various electronic activities (e.g., internet banking, e-commerce, etc.). A PKI binds public keys with respective identities of entities (e.g., individuals, companies, organizations) through registration and issuance of digital certificates by a CA. A PKI creates, stores, and distributes the digital certificates, which verify that a particular public key belongs to a certain entity.

SUMMARY

A first example embodiment relates to a method of managing a digital certificate. The method includes receiving, by a processor of a CA computing system, at least one of a digital certificate generation request and a digital certificate revocation from a user via a user computing device from a user via a user computing device. The digital certificate generation request includes a user public key and a user identity. The method further includes generating a digital certificate for the user and signing the digital certificate with a CA private key. The CA private key is associated with a known CA public key. The method further includes publishing the digital certificate signed with the CA private key to a digital certificate blockchain, determining an update to the digital certificate, and publishing an update block to the digital certificate blockchain to reflect the update to the digital certificate.

Another example embodiment relates to a digital certificate management system. The system includes a network interface, a digital certificate generation circuit, and a policy information circuit. The network interface is configured to facilitate data transmission over a network. The digital certificate generation circuit is configured to receive a digital certificate request from a user and generate a digital certificate associated with the user. The digital certificate includes an identity of the user and a public key of the user. The digital certificate generation circuit digitally signs the digital certificate with a CA private key and publishes the digital certificate to a digital certificate blockchain. The policy information circuit is configured to determine an update to policy information for the digital certificate and publish the update to an update block on the digital certificate blockchain.

DETAILED DESCRIPTION

Referring generally to the figures, systems and methods for PKI management via a blockchain-based system are shown. According to various example embodiments, a PKI management system allows users and relying parties to conduct secure transactions using a blockchain, allowing for real-time updates of digital certificates, listing of revoked certificates, and other information pertinent to conducting a secure transaction.

The blockchain-based PKI management system solves technical problems associated with conventional PKI systems. Conventionally, PKI systems include important CA and digital certificate information scattered in various places (e.g., different websites, servers) and thus, it may be difficult for an entity to locate particular information about the CA or the digital certificate. CAs store digital certificate information on a local server and thus, the information is not easily accessible or ascertainable to those without access to that particular server. The tracking of CA information on the instant blockchain-based system results in transparency and increased trustworthiness of a particular CA. In current PKI systems, it can be difficult to ascertain CA policies and current statuses. Without current knowledge of a CA or digital certificate, users and relying parties can be relying on a CA or certificate that does not fit the relying parties' purposes (e.g., the relying party agreement liabilities are not desirable). Additionally, tracking revocation of certificates via the instant blockchain-based system can make transactions using digital certificates more accurate, efficient, and secure. By relying on a compromised digital certificate, the security of transactions between entities is nonexistent. The users and relying parties would no longer be relying on a revoked digital certificate because information regarding the revocation of the certificate is accessible via blockchain. According to various example embodiments, the instant blockchain-based system utilizes updates to digital certificate information to inform users and relying parties of important CA information (e.g., policies, relying party agreements, audit letters, etc.). Additionally, the instant blockchain-based system publishes information regarding revocation of certificates from a CA, allowing users and relying parties to view those revoked certificates. Further, the instant blockchain-based system preserves the history of certificate lifecycles. Unlike current systems in which certificates are simply replaced once updated, the instant blockchain-based system publishes new information (e.g., an updated certificate) in a new block without deleting other related information (e.g., a prior certificate).

Referring toFIG. 1, a schematic diagram of a PKI management system100is shown, according to an example embodiment. As described in further detail below, the system100facilitates digital certificate management between various parties (e.g., user102, relying party104, CA112) to a transaction using a PKI blockchain system160.

The user102is an entity (e.g., individual, company, organization, etc.) desiring to securely communicate with the relying party104. For example, the user102may be a party requesting and receiving a digital certificate from a CA112to accomplish secure communication with the relying party104. The user102generates a public/private key pair and sends the public key with the digital certificate request to be validated by the CA112. The digital certificate can be published by the CA112to the blockchain to be later accessed by the relying party104for authentication of the user102.

The CA112is a trusted third party of the relationship between the user102and the relying party104. The CA112receives the digital certificate request from the user102, along with the public key of the user102, and generates and signs the digital certificate with the CA private key. The CA112then publishes the generated and signed digital certificate to the blockchain, as described in more detail below. The CA112additionally updates the status of the digital certificates by adding subsequent blocks to the blockchain, as described further herein. Furthermore, the CA112can have a certificate practice statement, policies, relying party agreements, and so on, that the relying party104implicitly agrees to by accepting the digital certificate generated for the user102. The CA112can publish this information on the blockchain (e.g., same or separate blockchain) to be viewable by the relying party104.

As shown inFIG. 1, the CA112can include one or more CAs. A single digital certificate can be shared among multiple CAs. These CAs can include a root CA113(e.g., trust anchor), an intermediate CA115, and an issuing CA117. The root CA113generates a root certificate (e.g., unsigned or self-signed digital certificate). The root CA113can issue multiple certificates, with the root certificate as the originating certificate and the private key of which is used to sign subsequent certificates. All certificates immediately following the root certificate inherit the trustworthiness of the root certificate. Certificates further down the chain of certificates also depend on the trustworthiness of the intermediate CAs115, also known as subordinate CAs. There can be multiple intermediate CAs115between the root CA113and the issuing CA117. Publishing information regarding all CAs to the blockchain can be beneficial in determining where a problem with a certificate may have arisen within the chain of CAs. Additionally, different root certificates may be used to issue certificates for different business purposes and tracking the business purpose information can be helpful to linearly determine the root certificate and associated root CA113.

The relying party104is an entity (e.g., individual, company, organization, etc.) receiving a request to securely communicate from the user102. The relying party104views the digital certificate of the user102that has been published to the blockchain to verify the identity of the user102prior to authorizing a secure communication. The relying party104relies on the CA112as a trusted third party and uses the CA public key to determine that the user102has a verified identity. As noted above, the relying party104implicitly agrees to the terms of the digital certificate issuing from the CA112. Thus, it is beneficial to the relying party104to view the certificate practice statement, policies, relying party agreements, and the like, via the blockchain.

The following is an example interaction between the user102, relying party104, and the CA112. The system100allows the user102to submit a digital certificate request to the CA112(received and processed by the CA computing system116). The user computing system106generates a public/private key pair to send to the CA112. The CA112verifies the identity of the user102, generates a digital certificate including the identity and the public key of the user102, and signs the digital certificate with the CA private key. The CA112publishes the digital certificate of the user102with the identity and public key of the user102and the public key of the CA112to the digital certificate blockchain121, described further herein. To participate in a secured communication with the relying party104, the user102sends a message request (e.g., secure network request, communication request, transaction request, etc.) to the relying party104(received and processed by the relying party computing system108). For example, the message request is for secured communication via a website. In this example, the user102submits the message request to the relying party104. Using the PKI blockchain system160, the relying party104can access the signed digital certificate of the user102on the digital certificate blockchain121, described further herein. In one embodiment, the digital certificate information may be included with the message request from the user102. In another embodiment, the creation and publication of digital certificates as well as access to the published certificates occurs exclusively within the PKI blockchain system160. The relying party104can additionally access current policy information and relying party agreements within the PKI blockchain system160via the digital certificate blockchain121, as well as check whether the digital certificate has been revoked. The relying party104verifies the identity of the user102using the CA public key. The relying party104then establishes the secure connection, thereby allowing the user102to communicate with the relying party through the secured connection.

Management of the PKI blockchain system160occurs throughout the interaction between the user102, relying party104, and CA112. The CA112(or other entities, such as an auditor, registration authority, and so on) can update the digital certificate policy information and agreements within the blockchain system160, as described further herein. Additionally, any revoked certificates can be published to the blockchain system160and can be made publicly available such that a relying party104and user102can view such information.

Referring toFIG. 2, a schematic diagram of a PKI management system100is shown, according to an example embodiment. As described in further detail below, the system100facilitates digital certificate issuance by a CA112. Additionally, the system100facilitates maintenance of digital certificates by various parties (e.g., user102, relying party104, CA112, etc.) to a communication using a PKI blockchain system160. As shown, the system100includes a user computing system106communicably and operatively coupled to each of a relying party computing system108associated with a relying party104, a PKI blockchain system160, and a CA computing system116associated with a CA112, over a network110. The network110provides communicable and operative coupling between the CA computing system116, user computing system106, relying party computing system108, the PKI blockchain system160, and the other components disclosed and described herein to provide and facilitate the exchange of communications (e.g., data, instructions, values, commands, etc.). Accordingly, the network110may include, for example, the Internet, cellular networks, proprietary cloud networks, and the like.

The PKI management system100allows management of publicly viewable blockchain entries pertaining to issuance and management of digital certificates. The PKI blockchain system160, described further herein, includes a distributed permission-based blockchain system, where members are authorized to participate. Other embodiments include a permissionless blockchain system in addition to, or instead of, the permission-based blockchain system. For example, for a permissionless blockchain system, an entity does not have to be recognized as having a previous relationship with the system (e.g., public blockchain systems, Bitcoin, etc.), whereas for a permission-based blockchain system, the entity must be recognized as having a previous relationship with the system (e.g., private blockchain systems, private FI systems). For example, in a permission-based blockchain system, an entity desiring to utilize the system100must first be recognized and authorized to partake in the system.

The PKI blockchain system160may include digital certificates of the user102signed by the CA112and information relating to the digital certificates, such as audit letters, policy and practice statements, relying party agreements, and so on. In some embodiments, uniform resource identifiers (URIs) are stored on the PKI blockchain system160. The URIs, for example, may point to a location from which the underlying information may be retrieved. For example, in some embodiments, URIs include uniform resource locators (URLs) of webpages from which the underlying data may be retrieved. In some embodiments, a combination of underlying data (e.g., digital certificates) and URIs (e.g., URLs pointing to audit letters and relying party agreements) are stored on the PKI blockchain system160. In some embodiments, the size of the PKI blockchain system160is prevented from getting excessively large by storing URIs on the PKI blockchain system160rather than the underlying data.

The PKI blockchain system160is communicably and operatively coupled to both the CA computing system116and the relying party computing system108such that access to the system160is available to both the CA112and the relying party104. In some arrangements, the PKI blockchain system160may additionally be accessible to the user102to add any subsequent information regarding a certificate in a subsequent block on the blockchain. As noted above, the PKI blockchain system160may comprise a distributed permission-based blockchain system, where members are authorized to participate. Other embodiments include a permissionless blockchain system in addition to, or instead of, the permission-based blockchain system. In some embodiments, the PKI blockchain system160facilitates cross-referencing of two or more blockchains existing within the blockchain system160. Multiple blockchains (e.g., digital certificate blockchains, revocation blockchains, management blockchains) can be cross-referenced based on user102or common name, which identifies the host name associated with the issued certificate. For example, if a first certificate is issued from a first CA and a second certificate is issued from a second CA under the same common name, the first and second certificates can be linked to each other regardless of whether both certificates have the same public key. In this way, information regarding related certificates that may have been issued from different CAs is easily found without having to identify and sift through multiple blockchains.

The PKI blockchain system160includes a digital certificate blockchain121, a certificate revocation list (CRL) blockchain123, and a management blockchain125. In some embodiments, the CRL blockchain123can be part of the digital certificate blockchain121, such that the information pertaining to a CRL is stored on the digital certificate blockchain121. In some embodiments, the management blockchain125can also be part of the digital certificate blockchain121, such that information pertaining to policies, agreements, and audit letters is stored on the digital certification blockchain121. The PKI blockchain system160is structured to store a plurality of digital certificates, policies, relying party agreements, revoked certificates, business purposes, etc., on the digital certificate, CRL blockchain, and management blockchains121,123,125. In particular, the digital certificate blockchain121includes a listing of digital certificates of various users102issued by the CA112. Some embodiments include multiple digital certificate blockchains121. For example, in some embodiments, a separate (e.g., parallel, shadow, etc.) digital certificate blockchain121is created for digital certificates relating to particular business purposes. In some embodiments, a separate digital certificate blockchain121is created for digital certificates containing certain types of relyi19ng party agreements (e.g., with varying levels of liability). In some arrangements, the digital certificate blockchain121includes individual regionalized blockchains such that a separate blockchain for each geographic region is created for digital certificates in that particular region. For example, a separate digital certificate blockchain121may exist for certificates issued to a user102in the United States such that certificates in other regions are not viewable within that blockchain.

The CRL blockchain123includes a listing of revoked certificates and related CAs. The CRL blockchain123can include both non-restricted and restricted revocation information. For example, some entities may be able to access and publish on the CRL blockchain123and other entities may not have access to publish on the blockchain123based on an entity-type. For example, an individual may not have access to publish a revoked certificate on the blockchain, but a CA may have access to do so. Some embodiments include multiple CRL blockchains123. For example, in some embodiments, a separate CRL blockchain123is created for CRLs having particular selective encryption. A separate CRL blockchain123may be created for lists in which selective encryption is managed by the CA, an auditor, or other third party.

The management blockchain125includes a listing of policies, relying party agreements, audit letters, and information regarding mergers and acquisitions of CAs. Updates to the policies, relying party agreements, audit letter, and information regarding mergers and acquisitions of CAs are stored on the management blockchain125to be separately accessible. The management blockchain125is maintained separately from the digital certificate blockchain121and the CRL blockchain123such that a user102or permissioned third party may review audit letters, agreements, and policies without sifting through the digital certificate or CRL blockchains121,123.

The user computing system106is associated with or operated by the user102(e.g., individual, company, organization, etc.). The user computing system106may include any type of computing system including, but not limited to, a phone (e.g., smartphone, etc.) and a computing device (e.g., tablet computer, laptop computer, desktop computer, personal digital assistant, etc.). The user computing system106is communicably and operatively coupled to the relying party computing system108and the CA computing system116to facilitate interaction between the user102, relying party104, and CA112. Additionally, in some embodiments, the user computing system106is communicably and operatively coupled to the PKI blockchain system160to facilitate management of digital certificates on the blockchain. The user computing system106includes a network interface circuit114, a key generation circuit122, and a messaging circuit124. In some embodiments, the user computing system106further includes a publishing circuit126.

The network interface circuit114is structured to facilitate operative communication between the user computing system106and other systems and devices over the network110. The user computing system106may, for example, include one or more servers each with one or more processors configured to execute instructions stored in a memory, send and receive data stored in the memory, and perform other operations to implement the digital certificate services described herein associated with the processing modules, databases and processes shown.

The key generation circuit122is structured to generate a public/private key pair associated with the user102for the digital signature of the message sent by the user102, described below in the messaging circuit124. The public/private key pair is associated with a digital certificate in a PKI, for example, the X.509 certificate. A key pair is generated (the private/public key pair must be generated together as they are mathematically related), the private key signs the public key, and the pair is submitted to the CA112. In some embodiments, the key pair can be sent to a front end registration authority (RA), which will verify the identity of the user102. The CA112will receive the verification and generate the digital certificate for the user102. Alternatively, the private/public key pair could be issued with a commercial CA, for example, one associated with a financial institution. In some arrangements, the user computing system106retrieves a public key certificate from the commercial CA and uses the certificate to ascertain the public/private key pair. In other embodiments, the key generation circuit122generates an ephemeral public/private key pair not associated with a digital certificate in a PKI. In these embodiments, the public key can be included in the attributes of the message sent by the user to the relying party, allowing a digital signature verifier to use the included public key component to verify message integrity. In these arrangements, the verifier will be able to verify message integrity (e.g., that it has not been modified), but will not gain origin authenticity assurance (e.g., know who signed the message and who possessed the private key component of the key pair).

The messaging circuit124is structured to send a communication request to the relying party computing system108via the network110. The messaging circuit124sends a message request to the relying party computing system108to establish communication between the user102and the relying party104. The message can include a transaction request including, but not limited to, a request to conduct a financial transaction, a request to communicate via a secured network, and so on. The message includes the generated digital certificate of the user102to be used by the relying party104to verify the identity of the user102. In other embodiments, the messaging circuit124does not include the digital certificate of the user102as it may be published to the blockchain via the PKI blockchain management system160(e.g., by the CA computing system116), and is viewable by the relying party104on the digital certificate blockchain121, as described further herein.

In some embodiments, the user computing system106includes a publishing circuit126. The publishing circuit126is structured to receive digital certificate-related information (e.g., policies, relying party agreements, revocation of certificates, etc.); determine whether the information should be published to the digital certificate, CRL, or management blockchains121,123,125; determine what, if any, encryption should be used to process and protect the data; and ultimately publish the data to the correct blockchain in the correct format on the PKI blockchain system160. The publishing circuit126receives information from the CA112(or another trusted third party) as revocations occur or as practices and agreements change. In other embodiments, the CA computing system116additionally, or alternatively, publishes this information to the blockchain system160.

The relying party computing system108may be associated with or operated by the relying party104(e.g., an individual, company, organization, etc.). The relying party computing system108may be communicably and operatively coupled to the PKI blockchain system160to facilitate authentication of a user102using a digital certificate published to the digital certificate blockchain121of the PKI blockchain system160. The relying party computing system108includes a network interface119, a communication circuit142, and a certificate verification circuit138.

The network interface119is structured to facilitate operative communication between the relying party computing system108and other systems and devices over the network110. The relying party computing system108may, for example, include one or more servers each with one or more processors configured to execute instructions stored in a memory, send and receive data stored in the memory, and perform other operations to implement the digital certificate services described herein associated with the processing modules, databases and processes shown.

The communication circuit142is structured to receive a communication request from the user102via the network110. In some embodiments, the communication circuit142receives the signed digital certificate from the user102along with the communication request. The communication circuit142communicates the request to the certificate verification circuit138. The communication circuit142is further structured to complete a secured communication (e.g., transaction) between the user computing system106and the relying party computing system108once the certificate verification circuit138has verified the identity of the user102, as described below. The secured communication can include completing a financial transaction, securing confidential email, etc. The communication circuit142is thus communicably and operatively coupled to the messaging circuit124of the user computing system106to receive a communication request from the user102. The communication circuit142is additionally communicably and operatively coupled to the certificate verification circuit138of the relying party computing system108to communicate the communication request to the certificate verification circuit138.

The certificate verification circuit138is structured to verify the identity of a requesting user102using the signed digital certificate of the user102. In one embodiment, the certificate verification circuit138accesses the digital certificate blockchain121to view the signed digital certificate of the user102. The digital certificate is published to the blockchain121by the CA computing system116and is viewable by the relying party computing system108. In another embodiment, the certificate verification circuit138receives a digital certificate from the user102via the messaging circuit124of the user computing system106. The certificate verification circuit138verifies the digital signature of the user102using the CA public key, which is known to the relying party104. In some embodiments, the certificate verification circuit138additionally checks the CRL blockchain123to determine whether the digital certificate has been revoked. In further embodiments, the certificate verification circuit138can check the digital certificate blockchain121to determine whether there have been updates to the policies, agreements, or practice statements relating to the digital certificate. If the digital certificate has been revoked or a policy has been changed to an undesirable policy for the relying party104, the certificate verification circuit138may deny the communication request from the user102and no secure connection will be established.

In some embodiments, the relying party computing system108includes a publishing circuit146. The publishing circuit146is structured to receive digital certificate related information (e.g., policies, relying party agreements, revocation of certificates, etc.), determine whether the information should be published to the digital certificate or CRL blockchains121,123, determine what, if any, encryption should be used to process and protect the data, and ultimately publish the data to the correct blockchain in the correct format on the PKI blockchain system160. The publishing circuit146receives information from the CA112(or another trusted third party) as revocations occur or as practices and agreements change. In other embodiments, the CA computing system116additionally, or alternatively, publishes this information to the blockchain system160.

The CA computing system116is associated with or operated by the CA112. The CA computing system116includes a network interface118, an identity verification circuit128and a blockchain publishing circuit130. The network interface118is structured to facilitate operative communication between the CA computing system116and other systems and devices over the network110. The CA computing system116may, for example, include one or more servers each with one or more processors configured to execute instructions stored in a memory, send and receive data stored in the memory, and perform other operations to implement the compliance services described herein associated with the processing modules, databases and processes shown.

The identity verification circuit128is structured to verify the identity of a user102requesting a digital certificate. To generate a digital certificate, the CA computing system116must first verify the identity of the user102that is to be associated with the public key of the user102on the digital certificate. To verify the identity of a user102, the identity verification circuit128receives information from the user computing system106regarding the identity of the user102. The identity verification circuit128checks that the request for a digital certificate is in compliance with certificate practice statements and policies. Then, the identity verification circuit128authenticates the identity of the user102in according with those statements and policies. In some embodiments, the identity verification is completed by a front end RA, as noted above. In this embodiment, the RA checks that requests are valid and authenticates the identity of the user102in accordance with requirements in the practice statements and policies. Once satisfied, the RA forwards the request to the CA112to sign and issue a digital certificate to the intended user102.

The blockchain publishing circuit130is structured to receive digital certificate update information (e.g., policies, practices, revocations, relying party agreements, etc.), determine whether the information should be published to the digital certificate, CRL blockchain, or management blockchains121,123,125, determine what, if any, encryption should be used to process and protect the data, and ultimately publish the data to the correct blockchain in the correct format on the PKI blockchain system160. The blockchain publishing circuit130receives information from the CA computing system116as revocations occur or as practices and agreements change. The blockchain publishing circuit130includes a digital certificate generation circuit132, a policy information circuit134, and a revocation information circuit136.

In some arrangements, the blockchain publishing circuit130utilizes a digital signature schema to provide authentication, integrity, and non-repudiation to a future verifier. The digital signature schema could be used by one or more of the circuits that are included on the blockchain publishing circuit130, for example the digital certificate generation circuit132, the policy information circuit134, or the revocation information circuit136. In those arrangements, the circuits within the blockchain publishing circuit130generate a messaging authentication code (MAC) using a specific symmetric cipher mode of operation called cipher block chaining. Alternatively, the circuits within the blockchain publishing circuit130could generate a keyed hash message authentication code (“HMAC”) that uses a hash algorithm instead of the symmetric cipher. In some arrangements, the blockchain publishing circuit130is structured to publish a cross-reference between multiple CAs such that certificates with the same common name are linked to each other. In addition, the blockchain publishing circuit130can link multiple certificates from the same issuing CA and user with differing public keys.

The digital certificate generation circuit132is structured to receive a request for a digital certificate from a user computing system106. The digital certificate generation circuit132is additionally structured to generate a digital certificate for a user102based on the request and publish the digital certificate to the digital certificate blockchain121on the PKI blockchain system160. The digital certificate includes the identity and public key of the user102received from the key generation circuit122of the user computing system106signed with the public key of the CA112. The digital certificate is published to the digital certificate blockchain121for access by the relying party computing system108. In some arrangements, the digital certificate generation circuit132is structured to generate a cross-reference link between an existing digital certificate chain that a digital certificate is being published to and a different certificate chain generated for a different CA that may be related to the digital certificate either by user or common name, as described above.

The policy information circuit134is structured to receive, organize, and publish information related to the policies and practices of the CA112and other entities (e.g., auditors, registration authorities) to the management blockchain125. The policy information circuit134is structured to also publish to the management blockchain125information related to the merger or acquisition of CAs. For example, policies and practices published to the management blockchain125may include relying party agreements, audit letters, CA policies, business purposes, merger and acquisition data, etc. In some embodiments, the policy information circuit134publishes information related to the policies and practices of the CA112, as well as information related to merger or acquisition of CAs, to the digital certificate blockchain121. The policy information circuit134also organizes the information into restricted and non-restricted information. The restricted information is encrypted by a content encryption key via a corresponding encryption algorithm, whereas the non-restricted information is unencrypted and can be viewed by any entity that accesses the digital certificate blockchain121and the management blockchain125in the PKI blockchain system160. For example, the CA policies and practices may include non-restricted information, viewable by subscribers, auditors, regulators, potential new subscribers, and the like, without requiring a content encryption key.

The policy and practice information can contain general information related to the obligations and actions the CA112would be required to perform throughout the active life of a digital certificate. The policies and practices information can be selectively encrypted and may outline the specific information related to the actions the CA112has agreed to take in regards to the CA's policies for one or more digital certificates. The policy and practice information may be specific to a single digital certificate. For example, the management blockchain125may contain non-restricted policy information of the CA that the CA will inform all users102and relying parties104of all revoked certificates in a timely manner, whereas the restricted practice information on the management blockchain125may be that the CA112will notify a specific user102and relying party104within 24 hours that a certificate has been revoked. The practice data needs to be restricted for security purposes: third party entities (and potential security attackers) should not know the exact time it will take the CA112to notify of certificate revocations, and the other users do not need to know of the specific negotiated terms of users on the system, for confidentiality purposes.

In some embodiments, the management blockchain125includes multiple different service policies and practices (e.g., corresponding to different products, different business purposes, etc.). In some embodiments, the different service policies and practices are stored in individual management blockchains125. However, in other embodiments, the different services policies and practices are stored in a single management blockchain125. As described above, in some embodiments, the service policies and practices are stored on the digital certificate blockchain121and can be stored in individual digital certificate blockchains121in a similar manner.

In some embodiments, business purposes published by the policy information circuit134identify certain business applications for which use of a particular certificate is authorized. For example, the policy information circuit134may specify that a first certificate is to be used only to sign mortgages, while a second certificate is to be used only to sign legal documents. This additional information published by the policy information circuit134overcomes technical problems associated with current systems. For example, current systems include a key usage field that specifies certain cryptography details regarding a certificate. For example, a key usage field may specify that a key is to be used for digital signatures or for key management. However, the key usage field is not used to specify particular business applications for which the key is to be used. Accordingly, the policy information circuit134provides an additional level of granularity by which further information on key usage may be specified.

The revocation information circuit136is structured to organize and publish the information related to the revocations of digital certificates to the CRL blockchain123of the PKI blockchain system160. For example, revocation information may indicate that a digital certificate for a CA has been revoked. The revocation information circuit136publishes a block to the CRL blockchain123indicating the certificate that has been revoked. In some arrangements, when publishing the revocation information, the revocation information circuit136can confirm that a corresponding private key has been destroyed.

The revocation information circuit136may implement a variety of publishing mechanisms depending on the desired schema of the PKI system. In some arrangements, the revocation information circuit136can catalog revocations as they occur and then encrypt and publish the revocations to the CRL blockchain123after a period of time (e.g., every hour, every day, etc.). In other arrangements, the revocation information circuit136can publish revocations to the CRL blockchain123in real-time as they occur. In some embodiments, the revocation information circuit136can publish revocations directly to the digital certificate blockchain121, or on a parallel or shadow blockchain to the digital certificate blockchain121linking the revocation information with the policy information of each digital certificate. In some embodiments, the revocation information circuit136is structured to create an associated CRL blockchain123for each digital certificate practices and policies in the digital certificate blockchain121.

By publishing revocation information to the centralized, publically-available CRL blockchain123, the revocation information circuit136enables users to manage revocations much more efficiently than current systems. For example, in current systems, system administrators must manually update certificate chains once CRLs are updated. In contrast, by publishing CRLs to the CRL blockchain123, various embodiments automatically update certificate chains once a CRL is posted.

Referring now toFIG. 3, a flow diagram of interactions between a user102, a relying party104, and a CA112, including use of the PKI blockchain system160is shown, according to an example embodiment. First, at302, a user102generates a public/private key pair using the key generation circuit122and at304, sends a request for a digital certificate to the CA112(received and processed by the CA computing system116). The user102sends the public key along with the digital certificate request to the CA112. At306, the CA computing system116verifies the identity of the user102using the identity verification circuit128and generates a digital certificate for the user102using the digital certificate generation circuit132. At308, the identity verification circuit128signs the digital certificate using the digital certificate generation circuit132. At310, the CA112publishes the digital certificate to the digital certificate blockchain121within the PKI blockchain system160.

At312, the user102sends a communication request to the relying party104. As shown at314, all user requests (e.g., the communication request206sent at312) are received at a communication circuit142of the relying party computing system108. The communication circuit142may communicate directly with user devices (e.g., user computing systems106) via a network (e.g., network110). The communication circuit142communicates the request to the certificate verification circuit138.

The certificate verification circuit138accesses the digital certificate blockchain121to view the digital certificate of the user102. At316, the certificate verification circuit138authenticates the digital certificate using the CA public key. At318, the communication with the user102is then authorized via the digital certificate and at320, the communication circuit142completes a secured communication with the user102.

Referring now toFIG. 4, a method400of generating a digital certificate and updating the certificate via the PKI management system100is shown, according to an example embodiment. In describing method400, references may be made toFIGS. 1-3.

At402, a request to generate a digital certificate is received. The digital certificate request may include information relating to an identity of a user and the public key of the user. The public key of the user is generated by the user computing device106in combination with a private key. In some arrangements, the request is transmitted from a user device (e.g., a personal computer, a smartphone, user computing system106, etc.) and received by the digital certificate generation circuit132of the CA computing system116.

At404, upon receiving the request, the digital certificate is generated. The digital certificate includes the identity and public key of the user. The digital certificate can include other information, such as the identity of the CA112, the lifetime of the certificate, and other user information.

At406, the digital certificate is signed by the CA. The CA112signs the digital certificate using the CA private key. The digital signature serves as a certification from the CA112that information provided in the certificate can be trusted.

At408, the digital certificate is published to the blockchain. More specifically, the signed digital certificate is published to the digital certificate blockchain121of the PKI blockchain system160. The digital certificate is accessible by relying parties to verify the user102and authorize a communication request from the user102.

At410, updates to the digital certificate are determined. Any updates to the digital certificate and/or CA112are ascertained by the policy information circuit134. The policy information circuit134can determine any changes or updates to any relying party agreements, audit letters, CA policies, business purposes, merger and acquisition data, etc. The policy information circuit134can also organize the information into restricted and non-restricted information.

At412, updates to the digital certificate are found at412are published to the blockchain. The policy information circuit134can publish any relying party agreements, audit letters, CA policies, business purposes, merger and acquisition data, etc. The policy information can be published on a separate second blockchain parallel to and associated with the digital certificate blockchain121(e.g., a parallel or shadow blockchain), or can be published on the digital certificate blockchain121in a subsequent block on the blockchain121.

Referring now toFIG. 5, a method500of monitoring and updating digital certificate status via the PKI management system100is shown, according to an example embodiment. In describing method500, references may be made toFIGS. 1-3.

At502, the digital certificates are monitored. The published digital certificates can be monitored in real-time by the CA computing system116. The published digital certificates can additionally be monitored by any other entity via the blockchain. Varying levels of access can be afforded to different parties based on the status of the entity (e.g., an individual may have a lower level of access than a financial institution, etc.). Some entities may not be able to access the blockchain to view this information.

At504, a certificate is found to be revoked. The revocation information circuit136of the CA computing system116can determine that a digital certificate has been revoked and can determine the CA associated with the revoked certificate. Alternatively, the user102or relying party104can determine that a certificate has been revoked and can communicate the revocation to the CA computing system116or can directly update the blockchain if update access is granted.

At506, the revoked certificate is published to the blockchain. Upon finding a certificate has been revoked, the revoked certificate is published to the CRL blockchain123by the revocation information circuit136. In some arrangements, the revocation information circuit136can publish revoked certificates periodically (e.g., every hour, every day, etc.). In other arrangements, the revocation information circuit136can publish revocations to the CRL blockchain123in real-time as they occur. In other embodiments, the revocation information circuit136can publish revocations directly to the digital certificate blockchain121, or as a parallel or shadow blockchain to the digital certificate blockchain121linking the revocation information with the policy information of each digital certificate. In some embodiments, the revocation information circuit136is structured to create an associated CRL blockchain123for each digital certificate in the digital certificate blockchain121.

The blockchain-based PKI management system solves technical problems associated with conventional PKI systems. Specifically, in current systems in instances where a digital certificate has been compromised, users and third parties may unknowingly rely on a revoked certificate and may compromise important security information by relying on those certificates. In conventional systems it is not easily ascertainable when and where the compromise may have taken place. In the instant system, users and relying parties would no longer be relying on a revoked digital certificate because information regarding the revocation of the certificate is readily accessible via blockchain. The instant blockchain-based system utilizes updates to digital certificate information to inform users and relying parties of updates to important CA information. In this way, the instant blockchain-based system preserves the history of certificate lifecycles. Unlike current systems in which certificates are simply replaced once updated, the instant blockchain-based system publishes updated certificates in a new block without deleting information related to any prior certificates. Thus, tracking revocation of certificates via the instant blockchain-based system can make transactions using digital certificates more accurate, efficient, and secure.