Method and device for automated digital certificate validation

Abstract

To facilitate a digital certificate verification by using a block chain.SOLUTION: A public key may be recorded to a block chain by a certificate that the public key is quickly and easily verified by an authentication station, and the certification is not in invalidation by an optional third party. The authentication station may expire a certification nearly immediately, and / or may perform certification of a new key at the same time for the same entity while expiring an old key. The verification can be combined to a new transaction so that no gap occurs between a dependence to the certificate and the verification of an effectiveness. In some cases, each transaction in which the certificate is used functions as a certificate transaction to be linked for updating the certificate for enabling the use thereafter.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to blockchain networks, and more particularly to the use of blockchain to facilitate digital certificate validation. [Background technology]

[0002] In a public key infrastructure, a computing device may have a public-private key pair to facilitate secure communications, digital signatures, non-repudiation, and other functions. As part of the public key infrastructure, the computing device may register its public key with a certificate authority, which provides the computing device with a digital certificate that confirms the ownership and authorization of the public key.

[0003] A problem with using certification authorities is that once a digital certificate is issued, it remains valid until its specified expiration date. However, public keys can be compromised, necessitating certificate revocation. To address this problem, certification authorities maintain "revocation lists" that detail which digital certificates should be considered revoked and periodically update and publish these lists. Entities wishing to validate a public key can rely on a digital certificate but must obtain and examine the corresponding certificate revocation list to determine whether the digital certificate has been revoked by the certification authority. This system and its inherent delays mean that some digital certificates may have expired, and that revocation may not yet be published or available to entities seeking to rely on the digital certificate. [Brief explanation of the drawings]

[0004] Reference will now be made, by way of example, to the accompanying drawings which illustrate exemplary embodiments of the present application. [Figure 1] 1 illustrates a schematic diagram of an exemplary system for managing a public key infrastructure. [Figure 2]1 illustrates, in flow chart form, one exemplary method for registering a public key with a certificate authority. [Figure 3] 1 illustrates, in flow chart form, one exemplary method for verifying a public key. [Figure 4] 1 illustrates, in flowchart form, an exemplary method for validating a digital certificate. [Figure 5] 1 illustrates, in flowchart form, another exemplary method for validating a digital certificate. [Figure 6] 1 illustrates, in flowchart form, a further exemplary method for validating a digital certificate using linked certificate transactions. [Figure 7] 1 illustrates, in block diagram form, a simplified example of a node that may implement at least a portion of one of the described methods.

[0005] In the drawings, like reference numbers are used to denote like elements and features. DETAILED DESCRIPTION OF THE INVENTION

[0006] In one aspect, a computer-implemented method for managing a public key infrastructure using a blockchain network may be provided. The method may include generating a digital certificate for a first entity having a first public key by creating an attestation transaction, where the attestation transaction includes a digital signature from a certificate authority, a first output to an address based on a second public key, and a second output having an information field including the first public key, determining a attestation transaction identifier from a hash of the attestation transaction, and propagating the attestation transaction on the blockchain network. The digital certificate includes the first public key and the attestation transaction identifier.

[0007] In some implementations, the second output includes an OP_RETURN field that includes at least the first public key. In some implementations, the first output includes a pay-to-public-key-hash (P2PKH) operation that references an address obtained as a hash of the second public key. In some implementations, the certificate authority holds a second private key that corresponds to the second public key.

[0008] In some implementations, the method may further include verifying the digital certificate. Validating the digital certificate may include obtaining a copy of the attestation transaction from the blockchain based on the attestation transaction identifier in the digital certificate, determining that the first output is an unspent transaction output, and determining that a first public key included in a second output in the attestation transaction matches the public key in the digital certificate. In some such implementations, determining that the first output is an unspent transaction output includes determining that the first output is in an unspent transaction output pool of the blockchain network. In some such implementations, the input to the attestation transaction may further include a certificate authority public key, and verifying the digital certificate may further include determining that the attestation transaction is signed by a certificate authority based on the certificate authority public key.

[0009] In some implementations, the method may further include revoking the digital certificate by generating a revocation transaction that includes the first output of the attestation transaction as input and propagating the revocation transaction on the blockchain network.

[0010] In some implementations, the method may further include replacing the digital certificate with a new digital certificate for the new public key. The replacing may include creating a new attestation transaction, where the new attestation transaction includes as input the first output of the attestation transaction, the first new output to a new address based on the third public key, and a second new output having an information field, where the information field includes the new public key; determining a new attestation transaction identifier from hashing the new attestation transaction; and propagating the new attestation transaction on the blockchain network. The new digital certificate may include the new public key and the new attestation transaction identifier.

[0011] In some implementations, the information field is an OP_RETURN output.

[0012] In some implementations, the attestation transaction includes an input referencing an unused transaction outpoint address obtained from a hash of the certificate authority public key, and the attestation transaction includes an unlock script for the unused transaction outpoint address including the certificate authority public and a digital signature, the digital signature being generated based on a private key corresponding to the certificate authority public key.

[0013] In some implementations, the first output includes a multi-sig lock script that allows any one of two or more private keys to utilize the first output.

[0014] In a further aspect, the present application describes a computer-implemented method for verifying a digital certificate using a blockchain network. The digital certificate includes a first public key and a certification transaction identifier. The method may include receiving a digital certificate from a first entity and obtaining a copy of the certification transaction from the blockchain based on the certification transaction identifier in the digital certificate, the certification transaction including a digital signature from a certificate authority, a first output to an address based on the second public key, and a second output having an information field. The method may further include determining that the information field includes a public key that matches the first public key in the digital certificate, querying an unspent transaction output pool to determine that the first output in the certification transaction has not been used in any subsequent transaction, and verifying that the first public key has been certified as valid based on these determinations.

[0015] In yet another aspect, the present application describes a computer-implemented method for validating a certificate associated with a first node. The method may include receiving a transaction template from the first node, where the transaction template references a proof transaction output and includes a first input signed by a proof transaction key; obtaining a copy of the proof transaction and determining that the proof transaction includes a certificate associated with the first node and that the proof transaction is signed by a certificate authority key; and propagating the transaction template on a blockchain network, where the propagated transaction template includes a second input that transfers resources to an output address. The transaction template is validated by a node on the blockchain network if the proof transaction output is included in a set of unspent transaction outputs.

[0016] In some implementations, the transaction template includes an input from a first public key associated with the first node and the certificate includes the first public key. In some cases, propagating includes adding an output to a second public key associated with the second node to the transaction template before propagating.

[0017] In some implementations, the transaction template includes an output to a first public key associated with the first node, and the certificate includes the first public key. In some cases, propagating includes adding an input from a second public key associated with the second node to the transaction template before propagating.

[0018] In some implementations, the attestation transaction output includes a pay-to-public-key output in the attestation transaction. In some cases, the attestation transaction output is one of multiple pay-to-public-key outputs in the attestation transaction, each of the pay-to-public-key outputs in the attestation transaction accompanied by a different respective public key.

[0019] In some implementations, obtaining includes identifying a last transaction in a series of linked transactions based on the last transaction including the attestation transaction output, and tracing back through the series of linked transactions to identify the attestation transaction. In some cases, obtaining further includes verifying that the attestation transaction output is a multi-signature output in which an authorized signer includes a certificate authority key.

[0020] In some implementations, the set of unspent transaction outputs includes all transaction outputs that have not yet been utilized as inputs to further transactions, and the set of unspent transaction outputs is maintained by the blockchain network.

[0021] In some implementations, the proof transaction output is in a transaction having a transaction identifier, a first input in the transaction template references the transaction identifier, and the proof transaction key is a private key associated with the transaction identifier and the index.

[0022] In some implementations, obtaining includes sending a request for the attestation transaction to a node in the blockchain network and receiving a response including the attestation transaction.

[0023] In some implementations, the obtaining includes receiving, from the first node, a copy of the attestation transaction and a Merkle path associated with the attestation transaction, and the method further includes verifying that the attestation transaction exists in the blockchain based on the copy of the attestation transaction, the Merkle path, and the set of block headers of the blockchain.

[0024] In another aspect, a computing device implementing a node in a network may be provided, which may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processors to perform one or more of the methods described herein.

[0025] In yet another aspect, a computer-readable medium may be provided that stores processor-executable instructions for operating a node in a network, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processor to perform at least one of the methods described herein.

[0026] Other exemplary embodiments of the present disclosure will become apparent to those skilled in the art from a review of the following detailed description in conjunction with the drawings.

[0027] In this application, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, but not necessarily excluding additional elements.

[0028] As used in this application, the phrase "at least one of ... or ..." is intended to cover any one or more of the listed elements, including any one of the listed elements only, any subcombination, or all of the elements, but not necessarily excluding any additional elements, and not necessarily requiring all of the elements.

[0029] This application refers to hashing or a hash function, which is intended to include any one of several cryptographic hash functions that, when applied to any set of data or "message," deterministically produce a unique, fixed-length alphanumeric string. The result of a hash function may be referred to as a hash value, fingerprint, hash result, etc. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0030] As used herein, the term "blockchain" is understood to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, reference may be made herein to Bitcoin as exemplified by the Bitcoin SV protocol; however, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0031] A blockchain is a peer-to-peer electronic ledger implemented using a computer-based, decentralized, distributed system. Blockchains are composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes, among other possible information, the transfer of control of a digital asset between participants in the blockchain system and includes at least one input and at least one output. Each block header contains a summary of the block's contents, for example in the form of a Merkle root, and each block header contains a hash of the previous block header, so that blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs that specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0032] A blockchain is implemented on a network of nodes. Each node is a computing device with network connectivity and runs software implementing the applicable blockchain protocol. Nodes validate transactions and propagate them to other nodes in the network. Specialized network nodes, called "mining nodes" or "miners," collect sets of unconfirmed, or pending, transactions into blocks and attempt to "mine" the blocks. Mining, in these examples, refers to solving a proof-of-work (POW) before any other miners in the network successfully solve the proof-of-work for the respective block. In the Bitcoin example, the POW involves hashing a block header containing a nonce until the result falls below a threshold set by a difficulty parameter. The nonce is repeatedly incremented and hashing is repeated until the result falls below the threshold or the miner receives notification that another miner has succeeded. Variations on the mining process are familiar to those skilled in the art.

[0033] Among the various checks made when validating a transaction, a node determines whether the inputs to the transaction are valid. In particular, the node evaluates whether the unlock script evaluates to true and determines whether the input references an "unspent transaction output" (UTXO) from a prior transaction. Some nodes may maintain a running list or pool of UTXOs to enable fast determination of whether a referenced transaction output is within a UTXO. The list or pool of UTXOs may be referred to as the "unspent transaction output set." Blockchain networks are configured to update and maintain unspent transaction output sets to prevent double-spend attacks. A transaction may be identified by its unique transaction identifier, TxID, which in some implementations is a hash of the transaction. Some transactions may have more than one output, so a unique transaction output (i.e., an outpoint) may be identified by the TxID and an index, where the index points to one of the outputs within the ordered set of outputs from the transaction. If a transaction output exists in the UTXO pool or set, the transaction output is "unspent" and available to serve as an input.

[0034] An unlocking script for a transaction outpoint defines how "control" over that output must be proven in order for it to be executed. Often, the address associated with a transaction output is a hash of a public key. To prove control over that output, the unlocking script often requires a public key and a digital signature generated using the corresponding private key. In this way, the node that controls the private key can control when and how the transaction output is used in any subsequent input. As explained further below, this has the consequence that if a transaction input corresponding to a particular public key includes a digital signature generated using the corresponding private key, then the entity associated with that particular public key has effectively signed or attested to the transaction contents.

[0035] Public key cryptography has become ubiquitous in online communications. In many cases, processes and policies are required to provide certainty that a public key is owned by one associated with a specific entity. The most common approach to ensuring that a public key is authentic and has not been compromised is the Public Key Infrastructure (PKI). A PKI relies on trusted third parties to "certify" public keys as valid. These entities are "Certification Authorities" (CAs). CAs provide registration and issuance of digital certificates that confirm the binding between a public key and a specific owner. A public key holder provides its public key and its digital certificate to another entity. The other entity can then verify the authenticity of the public key by verifying that a trusted CA has digitally signed the public key as belonging to the holder.

[0036] One problem with existing PKIs is that public keys can be compromised if, for example, the private key is lost or disclosed before the certificate's specified expiration date. For that reason, CAs may maintain certificate revocation lists. Entities that wish to rely on a certificate associated with a public key must also locate and consult the associated certificate revocation list to ensure that the certificate has not been revoked by the CA. This compromises the ability to authenticate keys offline and introduces risks due to the delay between revocation and the issuance of a new certificate revocation list, which is often 24 hours or more.

[0037] According to one aspect of the present application, a blockchain network may be used to improve public key infrastructure by providing fast and secure validation, revocation, and renewal of digital certificates. Public keys may be recorded on a blockchain by a certificate authority so that any third party can quickly and easily verify that the public key has been certified by the certificate authority and that the certification has not been revoked. By recording the public key in the manner described below, the certificate authority may be able to revoke a certification almost instantly or may be able to simultaneously certify a new key for the same entity while revoking the old key. In some cases, the ability to revoke a certification may be given to the owner of the public key, or in some cases, to one or a group of other entities.

[0038] Referring now to FIG. 1 , an exemplary system 100 for managing a public key infrastructure is illustrated. The system 100 in this example includes a first computing device 102, a second computing device 104, and a server 106. The first computing device 102 and the second computing device 104 may be implemented by any network-enabled computing device, including a server, a personal computer, a tablet, a smartphone, a connected car, an Internet of Things device, or any other such device. The server 106 is operated by a certification authority (CA) and is configured to receive and respond to requests for digital certificates. While the CA is shown as implemented by the server 106, it will be understood that the CA functionality may be implemented by one or more servers or other computing devices.

[0039] The system 100 further includes a blockchain network 108. The blockchain network 108 includes a network of nodes that operate according to an applicable blockchain protocol. In some implementations, one or more of the first computing device 100, the second computing device 104, and / or the server 106 may be nodes in the blockchain network 108, although in this example they are shown as separate nodes from the blockchain network 108 for ease of explanation.

[0040] In this example system 100, a first computing device 102, labeled "Alice," has a public-private key pair for use in asymmetric cryptographic communications. To use the public key in some cryptographic scenarios, Alice may need to have a corresponding digital certificate that authenticates the public key and its association with Alice. Thus, in operation 110, Alice sends her public key, PK , along with a request to register. Ato the CA. The CA may engage in some level of authentication to ensure Alice's identity as the owner of the public key. In some cases, this authentication may be an automated online operation performed by server 106 based on the data provided in operation 110. In some cases, this authentication may also, or alternatively, include an offline authentication operation. Two-factor authentication and other such techniques may be employed.

[0041] The CA issues the public key PK A Once it is determined that the public key PK A and generates a blockchain transaction, an "attestation transaction" (CTX), signed by the CA. The attestation transaction further includes an output controlled by the CA. As shown by operation 112, the transaction is submitted to the blockchain network 108. Then, in operation 114, the CA generates an attestation transaction identifier TxID CTX_PKA In some implementations, Alice obtains a copy of the proof transaction from the blockchain network 108 based on the transaction identifier and checks that it meets the expectations and provides the public key PK A It can be confirmed that the

[0042] Transaction Identifier TxID CTX_PKA is the public key PK A , which together effectively forms a digital certificate for Alice. In connection with any communication with the second communication device 104, labeled "Bob" in this example, Alice may send that digital certificate to Bob in operation 116. Bob then sends the public key PK A and can verify that the certificate has not been revoked based on the blockchain maintained by the blockchain network 108.

[0043] In particular, in operations 118 and 120, Bob may request and receive a copy of the attestation transaction. From the attestation transaction, Bob may learn that it is Alice's intended public key, PK A and that it has been signed by a trusted certificate authority. Bob can further verify that the proof has not been revoked by querying whether the transaction output controlled by the CA remains "unspent," i.e., whether the transaction output point exists in the UTXO pool 130 of the blockchain network 108, as shown by operations 122 and 124. The UTXO pool 130 is a pool of "unspent" transaction output points maintained by any one of several nodes of the blockchain network 108.

[0044] 2, there is shown in flow chart form one exemplary method 200 for registering a public key with a certificate authority. The exemplary method 200 may be implemented by an authorized certificate authority and by one or more servers suitably programmed to perform the described functions.

[0045] In operation 202, the certificate authority obtains the public key PK A The certificate authority receives a request from Alice for certification of Alice's public key PK. The certificate authority may perform authentication or authorization protocols in accordance with its applicable policies. These protocols may include automated computer-implemented and / or administrator-facilitated operations. Regardless of the particular authentication operation, in operation 204 a determination is made as to whether to certify Alice's public key. If not, method 200 ends. If certification is permitted, in operation 206 the certificate authority creates a certification transaction. As discussed above, the certification transaction involves inputs including the certificate authority's public key and a digital signature from the certificate authority, outputs controlled by the certificate authority, and the public key PK AAs a specific example, the input may be a UTXO of some nominal or arbitrary value for which the certificate authority has the private key to generate a signature on a valid unlock script. The UTXO may be associated with a digital value sufficient to offset any transaction fees that would be paid to mine the proof transaction.

[0046] The certification transaction uses the CA public key PK, which is selected and controlled by the certification authority. CTX_PKA and a public key PK in, for example, a non-operational information field. A An example of the latter is the OP_RETURN function in Bitcoin. OP_RETURN is effectively an output where arbitrary data can be placed for recording on the blockchain once the transaction is mined.

[0047] The first output may be, for example, a P2PKH (pay to public key hash) operation specifying a transfer to a public key hash (e.g., a Bitcoin address) selected and controlled by a certificate authority.

[0048] By its digital signature on the transaction, the CA not only authorizes the entry of a UTXO into the transaction, thereby satisfying the unlocking script, but also the public key PK that appears in the OP_RETURN output. A Note that in some implementations, additional information may appear in the OP_RETURN output field, such as a digital signature from Alice or other such data.

[0049] Once the attestation transaction is created, the certificate authority generates a transaction identifier TxID in operation 208. CTX_PKA, and propagates the transaction across the blockchain network, as indicated by operation 210. It will be understood that "propagating" a transaction includes submitting it to a node in the blockchain network, where it is validated and then sent to all other nodes, which then validate and re-transmit it, until the transaction has reached substantially all nodes in the network. In some embodiments, the certificate authority is itself one of the nodes in the blockchain network.

[0050] In operation 212, the certificate authority waits for the mining of a block containing the attestation transaction, i.e., the "confirmation" of the transaction, and then in operation 214, the transaction identifier TxID CTX_PKA to Alice. In some implementations, the certificate authority may provide the transaction identifier to Alice before the transaction is mined.

[0051] Alice can then send her public key, PK A and the proof transaction identifier TxID CTX_PKA From this, a third party can verify that Alice's public key is certified by the CA.

[0052] A simplified example of a proof transaction is shown below: [Table 1]

[0053] Note that the input to the unlock script includes the certificate authority's public key and the signature generated by the certificate authority. Alice's public key PK A appears in the OP_RETURN field as the second output. The first output is an arbitrary public key hash controlled by the certificate authority.

[0054] Referring now to Figure 3, one exemplary method 300 for verifying a public key is shown. The operations described in exemplary method 300 may be performed by a computing device attempting to verify a public key that it claims to be certified using the process illustrated in Figure 2. Exemplary computing devices include any network-enabled computing device.

[0055] The method 300 includes, at operation 302, receiving a digital certificate for another entity, such as the first computing device 102 (FIG. 1) labeled “Alice.” The digital certificate contains at least a public key PK A and the proof transaction identifier TxID CTX_PKA Using the attestation transaction identifier, the attestation transaction is obtained from the blockchain network in operation 304. It will be appreciated that the attestation transaction may be obtained from a copy of the blockchain, whether that copy is local to the computing device or whether it is maintained by a node in the blockchain network. Although the transaction may be in a mempool of unconfirmed transactions if it has not yet been confirmed, i.e., is not yet in a mined block, in many implementations the certificate authority may provide the attestation transaction identifier to Alice only after the attestation transaction has been mined.

[0056] From the attestation transaction, the computing device may verify certain things. In particular, in operation 306, the computing device may verify that the attestation transaction is signed by a certificate authority. The computing device may have, or have access to, a list of recognized or certified certificate authorities and their respective public keys, which may allow the computing device to validate the digital signature. The digital signature, as described, may form part of the input to the attestation transaction. By verifying that the attestation transaction is signed by a trusted or recognized certificate authority, the computing device can confirm that the attestation is valid. Note that the computing device does not necessarily need to verify the digital signature in the input, as the transaction will be confirmed and verified by miners if it is on the blockchain. Rather, the computing device may simply verify that the public key identified in the input is associated with a certificate authority.

[0057] The computing device may further verify that one of the output points of the proof transaction remains “unused,” i.e., that the output point can be found in the UTXO pool, as indicated by operation 308. This verification operation confirms that the proof remains valid and has not expired. As noted above, in most embodiments (alternatives are described below), this output point is controlled by a certificate authority, allowing the certificate authority to revoke the proof if the key is compromised, expires, or is no longer valid for other reasons. Revocation or revocation is easily facilitated by having the certificate authority “spend” the output point and remove it from the UTXO pool. Verification that the output point is present in the UTXO pool may be performed, for example, by querying the UTXO pool based on the TxID number and output index. In some examples, the computing device may query the UTXO pool through an intermediary, such as a node in a blockchain network.

[0058] At operation 310, the computing device receives the public key PK in the second output of the attestation transaction. A is the public key PK received from Alice as part of her digital certificate A Verify that it matches.

[0059] If operations 306, 308, and 310 are all verified, then in operation 312, the computing device reads the public key PK in the digital certificate received from Alice. A is determined to be valid.

[0060] By using a blockchain network to record public key certifications, a certificate authority can quickly and easily revoke a certification by "using" the output point to cause the validation in operation 308 to fail. Thus, a certificate authority may revoke a public key certification by generating and propagating a transaction that uses the first output of the certification transaction. As noted above, the first output may be a P2PKH operation that transfers a nominal digital asset to the public key hash address specified in the first output. The unlock script for that first output may, in these examples, require a digital signature from the certificate authority, which is the CA public key PK used in the P2PKH operation. CTX_PKA requires control over the private key corresponding to the

[0061] In some cases, a certificate authority may be required to replace / update a certified public key rather than simply revoking the certificate. For example, if a private key is lost or compromised, the owner (e.g., Alice) may request that the certificate authority replace the previously certified public key with a new public key, PK A_new The certification authority may request that the certificate be updated or replaced with a new attestation transaction CTX. The certification authority will authenticate the request using the online or offline authentication mechanism in place and, if it determines that the update action should be performed, will issue a new attestation transaction CTX. new to revoke the old certificate and issue a new one.

[0062] The new proof transaction will have the same type of output, i.e., PK CTX_new A new public key selected by the CA, such as A_new However, the input is the original proof transaction TxID. CTX_PKAThe CA may include a CA-controlled output point from the UXTO pool. Revocation is accomplished by removing that output point from the UXTO pool by "using" that output as input to a new certification transaction. Advantageously, the revocation of the old public key certificate and the registration of the new public key certificate occur in a single transaction. Furthermore, a separate, periodically published list of certificate revocations need not be maintained and made available by the certification authority.

[0063] As mentioned above, in many cases, the first output point of a certification transaction may be controlled by a certificate authority so that only the certificate authority can revoke the public key certification. Revocation is based on "using" that output point using the private key corresponding to the first output point. However, in some cases, it may be advantageous to structure the certification transaction to allow other entities to revoke the certification.

[0064] For example, in some situations, the owner of a public key, such as Alice, may have the authority to revoke their own public key. In this configuration, the first output point in the certification transaction is controlled by Alice, i.e., it references a public key (public key hash) for which Alice has the corresponding private key. That is, the unlock script for the first output point requires a digital signature from Alice. This configuration may be advantageous for some public key certification scenarios, such as registration for an online service. One example of an online service is a social media account on a social media platform. The platform can use the above-described mechanism to register a user's public key for use on the platform, allowing the user to interact with the platform and / or other users of the platform in a trusted manner with their own digital certificate backed up through the certification transaction. The user can then revoke the certificate to terminate the account without the platform's cooperation.

[0065] In another scenario, two or more output points may be provided, any one of which may be "used" to complete the proof. In such a scenario, the third party is configured to test both (or all) such output points of the proof transaction for their presence as unspent transaction outputs in the UTXO pool.

[0066] Alternatively, if revocation from any one of multiple parties is to be facilitated, the first output may be configured to use multiple signatures, i.e., any one of several signatures may be used to "spend" the output. For this purpose, a Multi-sig may be used on the output.

[0067] In yet another scenario, a multi-sig may be configured to ensure that at least a threshold number of entities agree to revoke the certification. The multi-sig may be configured to require n of m signatures to unlock the output, where n≦m. As an example, in the case of an organization such as a corporation, partnership, or other such collection of individuals, a certified public key associated with the organization may be revocable only if all or at least a threshold number of certain entities, such as the CEO, COO, CTO, or other executives or individuals involved in the company, approve the revocation.

[0068] It will be understood that some or all of the above-described operations of the various above-described exemplary methods may be performed in orders other than those illustrated and / or may be performed simultaneously without changing the overall operation of the methods.

[0069] Automated Proof Verification The above-described method provides a mechanism for issuing digital certificates secured by a blockchain network. This mechanism enables fast verification of the validity of the digital certificate and the ability to revoke the digital certificate almost instantly. As described above, to verify the validity of a digital certificate, a node seeking certificate validation checks to ensure that the outpoint of the certificate transaction is within the UTXO set and that the public key in the digital certificate being validated matches the public key in the OP_RETURN field of the certificate transaction.

[0070] One potential drawback of the described method is that there may be a time delay between the validation of a digital certificate and any subsequent transaction that relies on that validation. During that interval, the digital certificate may become revoked for some reasons. Furthermore, validation of a digital certificate relies on accessing and checking the UXTO set, which may be difficult or impossible for some nodes, such as lightweight SPV (simplified payment verification) nodes (e.g., digital wallets). This raises security and reliability concerns because those nodes may need to rely on third-party nodes to perform their validation. Furthermore, the node verifying that an outgoing point is within the UXTO set must be online with active access to the blockchain network, which many lightweight SPV nodes may not have at any given time.

[0071] According to another aspect of the present application, digital certificate validation may be incorporated into transactions such that the transaction only moves forward if the digital certificate is valid. This allows lightweight SPVs and similar nodes to collaborate with other nodes in generating transactions that incorporate automatic digital certificate validation. Advantageously, this can eliminate the time gap between validating a digital certificate and relying on that validation when committing to a transaction.

[0072] In some of the examples below, a node may have its public key certified by a certificate authority node in the form of an attestation transaction, which may take the form of this example: [Table 2]

[0073] In the above example, node A's public key PK A The OP_RETURN output is the public key PK A Note that the OP_RETURN output includes a certificate for the public key. In some instances, this may simply be the public key itself. In some cases, it may be a hash of the public key. In some cases, the certificate included in the OP_RETURN output may include additional data along with the public key.

[0074] Note also that the input is a transaction outpoint controlled by a certificate authority, whose unlock script is signed by the certificate authority. The output is the proof transaction public key.

number

number

number

[0075] Such a certificate is a proof transaction public key

number

[0076] As mentioned above, attestation transactions can be used to automate the validation of digital certificates. In particular, the automation consists in checking the UXTO set. For example, a new transaction, such as a payment transaction, includes as a prerequisite the presence of the attestation transaction outpoint in the UXTO set. This ensures that the new transaction is only valid if the certificate is still valid and has not been revoked.

[0077] In general, a node (e.g., Alice) with a digital certificate attesting to its public key generates a transaction template that includes the certificate's outgoing key as input. The input is signed with the attest transaction key, e.g., using the private key corresponding to the P2PKH output of the attest transaction. This transaction template is provided to another node (e.g., Bob) participating in the transaction. The other node, Bob, retrieves the attest transaction based on a reference to the TXID for the attest transaction in the input to the transaction template and provides the intended public key, PK Ais indeed attested by the attest transaction and adds any inputs / outputs that complete the transaction template. The transaction template can then be propagated on the blockchain network. If the input signed by the attest transaction key fails because the output is already used in another transaction, i.e., the output is not in the UTXO set, the entire transaction fails and is not propagated or mined. If the input signed by the attest transaction key is valid because it is in the UTXO set, the transaction is validated, propagated, enters the mempool, and eventually enters the block to be mined.

[0078] In one example, this mechanism may be used to verify a recipient's address. For example, in a situation where Alice requests a digital asset or some other transfer from Bob, Bob may want to validate Alice's identity, e.g., that her intended public key is attested, before committing to such a transaction. In such a situation, Alice may prepare a transaction template that includes a payment for Alice's public key along with an input that references a attestation transaction for that public key. Upon receiving the transaction template, Bob may retrieve the attestation transaction from the blockchain, verify that it attests to Alice's public key, and confirm that it has been digitally signed by a certificate authority. Bob may then add an input to a transaction template that transfers the digital asset, and the transaction template may then be propagated on the blockchain. If Alice's digital certificate is still valid, i.e., it has not expired, the transaction proceeds. An example of such a transaction is shown below: [Table 3]

[0079] In the example transaction above, Bob:

number

[0080] In another example, this mechanism may be used to verify the sender's address, for example to satisfy Know Your Customer (KYC) requirements. For example, Alice is transferring assets to Bob, and Bob wants to verify Alice's identity before accepting the transfer. In this case, Alice transfers digital assets and sends them to Bob, who then sends her public key, PK A , which also includes a proof transaction that certifies its public key as an input. Upon receiving the transaction template, Bob may take the proof transaction, verify that it is signed by the certificate authority, and verify that it certifies Alice's public key. If so, Bob completes the transaction template by adding an output to transfer the digital asset to a public key address controlled by Bob. Such an example transaction may take the following form: [Table 4]

[0081] In each of the two detailed examples above, it will be understood that once a digital certificate is used in a transaction to prove the validity of a public key, it becomes invalid. That is, the certificate may be used only once, after which it automatically expires. This may be applicable in some cases, such as for one-off transfers of large asset values ​​to or from a verified address. Such transactions may be used in the case of car transfers, real estate transactions, stock sales, or other such high-value transfers. However, for lower-value, everyday transactions, it may be cumbersome to return to the certificate authority for a new certificate each time it is used. Therefore, as described below, multi-use certificates may be constructed.

[0082] Referring first to Figure 4, one exemplary method 400 for validating a certificate associated with a first node is illustrated in flowchart form. The method may be implemented by a computing device such as a mobile phone, tablet, personal computer, etc. The computing device includes one or more processor units and associated memory that store computer-executable instructions that, when executed by the processing units, cause the processing units to perform the described operations. In some cases, the computer-executable instructions may be stored in the form of an application, such as, for example, a wallet application.

[0083] Method 400 provides an example of automated certificate validation for verifying the identity of a recipient. In this example transaction, node A is the recipient and node B is the sender. The nodes may communicate over wired and / or wireless networks. In some cases, the nodes may communicate using short-range communications, e.g., via point-of-sale terminals. Method 400 begins in operation 402 with node A creating a transaction template. The transaction template includes a public key, e.g., node A's public key PK, that attests to node A's identity. AThe output in the proof transaction is the proof transaction public key.

number

number

[0084] As indicated by operation 404, node A sends this transaction template to node B. The transaction template does not yet include input from node B and / or, if it does include input, has not been signed by node B.

[0085] Upon receiving the transaction template, in operation 406, Node B identifies the attest transaction based on the reference to the attest transaction in the input to the transaction template. Because the reference includes the transaction identifier of the attest transaction, Node B can retrieve a copy of the attest transaction. If Node B stores a local copy of the blockchain, Node B may obtain the attest transaction by looking it up in its local copy. Otherwise, Node B may send a query or request to a blockchain node for a copy of the attest transaction based on the transaction identifier. In some cases, this verification may be performed as proof of the existence of the attest transaction. That is, when Node B is provided with a copy of the attest transaction and a Merkle proof (Merkle path), Node B may verify that the attest transaction exists in the blockchain from the block header. An SPV node or other lightweight implementation may have a copy of the block header available even when offline, allowing Node B to verify the existence and content of the attest transaction without necessarily requiring live access to the blockchain network. Thus, Node A may provide Node B with a copy of the attest transaction and its Merkle path along with the transaction template.

[0086] Once node B has a copy of the attestation transaction, it verifies in operation 408 that the attestation transaction has been signed by the certificate authority using the certificate authority key. It also verifies that node A's public key PK A appears in the OP_RETURN output field of the attest transaction, thereby confirming that the certification authority is attesting to the authenticity of Node A's public key. Node B may further validate the structure of the attest transaction, in particular, verifying that the attest transaction public key,

number

[0087] It will be appreciated that if these checks fail—for example, if node A's public key cannot be verified as attested, or if the attestation transaction is not structured as expected—node B does not complete the transaction, and method 400 terminates. However, assuming node B verifies that the attestation transaction is valid, in operation 410, node B modifies the transaction template to add an input from an address controlled by node B. That is, node B adds a resource input to the transaction template and signs the input. This completes the transaction template, which node B may then propagate on the blockchain network. Alternatively, node B may send the completed transaction template to node A, which may propagate it on the blockchain network.

[0088] In either case, one of two things occurs, as indicated by operation 412.

number

number

[0089] Referring now to Figure 5, another exemplary method 500 for automatically validating digital certificates is illustrated in flowchart form. Similar to Figure 4, the method 500 illustrated in Figure 5 may be performed by computing devices implementing a first node, Node A, and a second node, Node B. In the example method 500, a transaction is generated to transfer a resource from Node A to Node B. Node B attempts to validate the identity of Node A, for example, as part of a "know-your-customer" or anti-fraud record-keeping requirement, before accepting the transfer of the resource.

[0090] Node A creates a transaction template in operation 502 and includes an input that references the attest transaction output from a attest transaction that attests to node A's public key. The input is signed by node A using the attest transaction key that corresponds to the attest transaction public key referenced in the attest transaction output. Node A also creates a transaction template with its attested public key PK A In operation 504, node A sends the transaction template to node B.

[0091] In operation 506, Node B retrieves a copy of the attestation transaction from the blockchain, whether stored locally or remotely. The attestation transaction is identified by the transaction identifier referenced in the input to the transaction template.

[0092] In operation 508, node B verifies that the attestation transaction has been signed by the certificate authority using the certificate authority key. A appears in the OP_RETURN output field of the attest transaction, thereby confirming that the certification authority is attesting to the authenticity of Node A's public key. Node B may further validate the structure of the attest transaction, in particular, verifying that the attest transaction public key,

number

[0093] It will be appreciated that if these checks fail, for example, if node A's public key cannot be verified as attested, or if the attestation transaction is not structured as expected, method 500 terminates as node B does not complete the transaction. However, assuming node B verifies that the attestation transaction is valid, in operation 510, node B may modify the transaction template to add an output to an address controlled by node B. In some cases, node A may have already added an output to transfer resources to node B, in which case node B need only verify that the output is correct in operation 510. This completes the transaction template, which node B may then propagate on the blockchain network. Alternatively, node B may send the completed transaction template to node A, which may propagate it on the blockchain network.

[0094] After the transaction is sent to a node in the blockchain network, one of two things happens, as indicated by operation 512.

number

number

[0095] Multiple Use Certificate As noted earlier, the examples above assumed that a digital certificate becomes invalid once it has been used in a transaction to prove the validity of a public key, as the proof transaction output becomes "used." That is, a certificate can only be used once, and is automatically revoked once used. In some situations, it may be desirable to have a certificate that can be used multiple times without requiring a node to obtain an unused certificate from a certificate authority after each use.

[0096] In one example, a multi-use certificate may be created by providing multiple attestation transaction outputs to a certificate transaction. The attestation transaction may be structured to provide m possible uses. Each output may be used only once in a validation operation. Once an output is "used," it is no longer available. An example of such a certificate transaction is shown below: [Table 5]

[0097] public key

number

[0098] Node A may revoke its own certificate by submitting a transaction that uses all of the certificate's remaining unused transaction outputs. A certificate authority may do the same to revoke a certificate, but if the certificate authority does not have reliable knowledge of which of the outputs in the certification transaction have already been used, the certificate authority submits a separate transaction for each output to ensure the certificate is revoked.

[0099] The above exemplary multi-use certificate is advantageous in that it can be used by node A up to m times, but after all outputs are exhausted, node A must obtain a new certificate from the certificate authority. In another example, the certificate validation process may be constructed such that each validation further generates a new outgoing point linked to the certificate transaction, thereby building a chain of transactions back to the original attestation transaction.

[0100] In one exemplary implementation, if a certificate authority does not require the ability to revoke certificates, the form of certificate described above may be used. Each time node A uses a certificate in a transaction, node A ensures that the transaction generates a new pay-to-public-key output to use as the proof transaction output in any subsequent transactions that later use that certificate.

[0101] In another exemplary implementation, to ensure that the certificate authority can revoke the certificate, the attestation transaction and each subsequent transaction in the chain use a multi-sig output. The multi-sig output allows a 1-of-2 signature to unlock the output, which includes the public keys for both the certificate authority and node A. One illustrative example is shown below: [Table 6]

[0102] Proof Transaction Public Key

number

[0103] To use the certificate, node A must create a new certificate transaction key with the certificate authority.

number

[0104] As an example, consider node A entering into a transaction with node B, where node B transfers a resource to node A and node A uses its digital certificate to prove the validity of its public key. Such a transaction may take the following form: [Table 7]

[0105] In the example transaction above, one of the inputs is a public key PK controlled by Node B. B Note that this input is from . This input is added to the transaction template by node B after node B verifies that the structure of the transaction template is valid and the certificate for node A is verified.

[0106] The transaction begins with the exchange of resource y BSV with public key PK as indicated by the first outgoing point. A Another input is the proof transaction output.

number

number

[0107] Node B may provide an updated attestation key to Node A and optionally further evaluate whether Node A has properly structured the attestation transaction output in the current transaction template so that the certification authority can revoke the attestation if necessary, although Node B does not necessarily need to confirm this in order to proceed with the transaction.

[0108] After the above transaction is submitted to the blockchain network, node A then creates a new linked public key

number

number

number

number

number

number

number

[0109] Subsequent transactions with node A's proof are executed in the same way, with other nodes tracing back through the chain of linked transactions to ensure that their proof transaction outputs are correctly structured until they reach the original proof transaction.

[0110] Referring now to Figure 6, a portion of a method 600 for validating a digital certificate using linked transactions is illustrated in flowchart form. Method 600 provides an example of automated certificate validation to verify the identity of a recipient. In this example transaction, node A is the recipient and node B is the sender. Method 600 begins in operation 602 with node A creating a transaction template. In this example, the transaction template verifies node A's identity, e.g., node A's public key PK A The output of the last proof transaction is the proof transaction public key.

number

number

[0111] Node A sends this transaction template to node B in operation 604. The transaction template does not yet include input from node B and / or has not been signed by node B if it does include input.

[0112] In operation 606, upon receiving the transaction template, node B obtains a copy of the transaction referenced in the input to the transaction template. The transaction may be an original attestation transaction if node A has not used that certificate before, or it may be a linked attestation transaction. In operation 608, node B evaluates whether it is an original attestation transaction. An original attestation transaction is a PK A , and the linked attestation transaction includes two or more signed inputs that reference a previous transaction outpoint, one of which may be a previous attestation transaction and the other of which may be an input resource to the linked attestation transaction. If Node B determines that the retrieved transaction is a linked attestation transaction and not the original attestation transaction, then in operation 610 it determines whether the referenced outpoint is validly structured. For example, if the outpoint does not contain a referenced attestation public key, e.g.,

number

number

[0113] Once the original attestation transaction is identified, node B verifies in operation 612 that the attestation transaction was signed by the certificate authority using the certificate authority key. A appears in the OP_RETURN output field of the prove transaction, thereby confirming that the CA has attested to the authenticity of node A's public key. This is because the prove transaction output is

number

[0114] If node B is satisfied that the original attestation transaction is valid, then in operation 614 it obtains node A's public key PK A It then, in operation 614, submits the completed transaction template to the blockchain network, along with the attestation transaction public key in the last attestation transaction in the chain of attestation transactions, as shown by operation 616.

number

[0115] In one implementation, the value transferred to each attestation transaction output in a series of attestation transaction outputs may be a fixed value x that the validator node verifies when evaluating the format and content of each transaction in the series. In another implementation, to place an upper limit on the number of times a proof can be reused, the value may start out as a fixed amount in the original attestation transaction and be decremented by a fixed amount with each use, so that at some point no further updates occur. In some implementations, the decremented amount may correspond to the amount of the transaction fee.

[0116] It will be appreciated that the certificate authority may revoke this certificate by identifying the most recent transaction in a series of certification transactions and using a 1-of-2 multi-sig output using the certificate authority's key.

[0117] 7, a simplified computing device 700 according to one example of the present application is shown in block diagram form. The computing device 700 may perform one or more of the functions described above. In this sense, it may function as the first computing device 102 (FIG. 1), the second computing device 104 (FIG. 1), or the server 106 (FIG. 1) in some implementations.

[0118] Computing device 700 includes a processor 702, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. Computing device 700 may further include memory 704, which may include persistent and non-persistent memory for storing values, variables, and in some cases, processor-executable program instructions, and a network interface 706.

[0119] Computing device 700 may include processor-executable applications 708 that include processor-executable instructions that, when executed, cause processor 702 to perform one or more of the functions or operations described herein.

[0120] The various embodiments presented above are merely examples and are not intended to limit the scope of the present application in any way. Variations of the innovations described herein will be apparent to those skilled in the art, and such variations are within the intended scope of the present application. In particular, features from one or more of the above-described exemplary embodiments may be selected to create alternative exemplary embodiments including subcombinations of features that may not be explicitly described above. In addition, features from one or more of the above-described exemplary embodiments may be selected and combined to create alternative exemplary embodiments including combinations of features that may not be explicitly described above. Features suitable for such combinations and subcombinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter described in this specification and claims is intended to cover and encompass all appropriate modifications in technology.

Claims

1. 1. A computer-implemented method for validating a first public key associated with a first node, comprising: receiving a transaction template from the first node, wherein the transaction template includes a first input that references a current key registration transaction output; identifying a last transaction in a series of linked transactions based on the last transaction including the current key registration transaction output; tracing back through the series of linked transactions to identify and obtain a key registration transaction that includes the first public key associated with the first node, and verifying that the key registration transaction is signed by a third-party key; propagating the transaction template on a blockchain network; and wherein the propagated transaction template includes a second input that transfers a resource to an output address; whereby the transaction template is validated by a node on the blockchain network if the current key registration transaction output is included in a set of unspent transaction outputs. method.

2. 2. The method of claim 1, wherein the transaction template includes input from the first public key associated with the first node.

3. 3. The method of claim 2, wherein propagating includes adding an output to a second public key associated with a second node to the transaction template prior to propagating.

4. 2. The method of claim 1, wherein the transaction template includes an output to the first public key associated with the first node.

5. 5. The method of claim 4, wherein propagating includes adding input from a second public key associated with a second node to the transaction template prior to propagating.

6. The method of claim 1 , wherein the key registration transaction output comprises a pay-to-public-key output of the last transaction.

7. 7. The method of claim 6, wherein the key registration transaction output is one of multiple pay-to-public-key outputs in the final transaction, each of the pay-to-public-key outputs in the final transaction involving a different respective public key.

8. 8. The method of claim 1, wherein obtaining further comprises verifying that the key registration transaction output is a multi-signature output in which an authorized signer includes the third-party key.

9. 9. The method of claim 1, wherein the set of unspent transaction outputs comprises all transaction outputs that have not yet been utilized as inputs to further transactions, the set of unspent transaction outputs being maintained by the blockchain network.

10. 10. The method of claim 1, wherein obtaining comprises sending a request for the key registration transaction to a node in the blockchain network and receiving a response including the key registration transaction.

11. 10. The method of claim 1, wherein obtaining includes receiving, from the first node, a copy of the last transaction and a Merkle path associated with the last transaction, and the method further includes verifying that the last transaction is recorded in the blockchain based on the set of the copy of the last transaction, the Merkle path, and a block header of a blockchain.

12. 1. A computing device for validating a first public key associated with a first node, comprising: one or more processors; Memory and computer-executable instructions stored in the memory that, when executed by the one or more processors, cause the processors to perform the method of any one of claims 1 to 11; 1. A computing device comprising:

13. 12. A computer-readable medium storing processor-executable instructions for validating a first public key associated with a first node, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the processors to perform the method of any one of claims 1 to 11.

Images