Method and device for automatic digital certificate verification

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 blockchains to facilitate digital certificate verification.

Background Art

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

[0003] A problem with the use of certificate authorities is that once a digital certificate is issued, it remains valid until its specified expiration date. However, public keys can be exposed to risks and revocation of the certificate may be necessary. To address this problem, certificate authorities maintain "revocation lists" that detail which digital certificates should be considered revoked, and these lists are updated and published periodically. Entities that wish to verify the validity of a public key can rely on the digital certificate, but must obtain and examine the corresponding certificate revocation list to confirm whether the digital certificate has been invalidated by the certificate authority. This system and its inherent delays mean that some digital certificates may have been revoked and their revocation may not yet be public or available to the entity relying on that digital certificate.

Brief Description of the Drawings

[0004] Here, by way of example, reference is made to the accompanying drawings that illustrate exemplary embodiments of the present application.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

[0005] In the drawings, like reference numbers are used to indicate like elements and features. [[Embodiments for Carrying Out 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 a proof transaction, where the proof transaction includes a digital signature from a certification 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 proof transaction identifier from a hash of the proof transaction, and propagating the proof transaction on the blockchain network. The digital certificate includes the first public key and the proof 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 the hash of the second public key. In some implementations, the certificate authority holds a second private key corresponding to the second public key.

[0008] In some implementations, the method may further include verifying a digital certificate. Verifying the digital certificate may include obtaining a copy of the proof transaction from the blockchain based on the proof transaction identifier in the digital certificate, determining that the first output is an unspent transaction output, and determining that the first public key included in the second output in the proof 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 exists in the unspent transaction output pool of the blockchain network. In some such implementations, the input to the proof transaction may further include a certificate authority public key, and verifying the digital certificate may further include determining that the proof transaction is signed by the certificate authority based on the certificate authority public key.

[0009] In some implementations, the method may further include invalidating the digital certificate by generating an invalidation transaction that includes the first output of the proof transaction as an input and propagating the invalidation transaction on the blockchain network.

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

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

[0012] In some implementations, the proof transaction includes an input referencing an unspent transaction outpoint address obtained from a hash of the certificate authority public key, the proof transaction includes an unlock script for the unspent transaction outpoint address including the certificate authority public and digital signature, and the digital signature is 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 enables 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 proof transaction identifier. The method may include receiving the digital certificate from a first entity and obtaining a copy of the proof transaction from the blockchain based on the proof transaction identifier within the digital certificate, where the proof 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. The method may further include determining that the information field includes a public key that matches the first public key within the digital certificate, querying an unspent transaction output pool to determine that the first output within the proof transaction is not being used in any subsequent transaction, and based on these determinations, verifying that the first public key has been proven to be valid.

[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 the certificate associated with the first node and that the proof transaction is signed by a certificate authority key, and propagating the transaction template on the blockchain network, where the propagated transaction template includes a second input for transferring a resource to an output address. The transaction template is validated by nodes on the blockchain network if the proof transaction output is included within an unspent transaction output set.

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

[0017] In some implementations, the transaction template includes an output to a first public key associated with a 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 a second node to the transaction template before propagation.

[0018] In some implementations, the proof transaction output includes a pay-to-public-key output in the proof transaction. In some cases, the proof transaction output is one of a plurality of pay-to-public-key outputs in the proof transaction, and each of the pay-to-public-key outputs in the proof transaction is associated with 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 a proof transaction output, and tracing back the series of linked transactions to identify the proof transaction. In some cases, obtaining further includes verifying that the proof transaction output is a multi-signature output in which the authorized signer includes a certification 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 within a transaction that has a transaction identifier, the 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 an index.

[0022] In some implementations, obtaining includes sending a request for a proof transaction to a node within a blockchain network and receiving a response that includes the proof transaction.

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

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

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

[0026] Other exemplary embodiments of the present disclosure will become apparent to those of ordinary skill in the art upon reviewing 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 sub - combinations of the listed elements, including any one of the listed elements only, any sub - combination, or all of the elements, without necessarily excluding additional elements.

[0028] In this application, the expression "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 sub - combination, or all of the elements, without necessarily excluding any additional elements and without 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 deterministically generate a unique fixed - length alphanumeric string when applied to any set of data or "message". 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] In this specification, the term "blockchain" is understood to include all forms of electronic, computer - based distributed ledgers. These include consensus - based blockchains and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variations. The most well - known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have also been proposed and developed. For convenience and by way of example, this specification may refer to Bitcoin as exemplified by the Bitcoin SV protocol, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are included 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. A blockchain is composed of blocks, and blocks are composed of transactions. Each transaction is a data structure that encodes, among other possible information, the transfer of control of digital assets between participants in a blockchain system, and includes at least one input and at least one output. Each block header includes a summary of the contents of the block, for example in the form of a Merkle root, and each block header includes the hash of the previous block header, so that the blocks are chained together to create a permanent and immutable record of all transactions written to that blockchain since the start of the blockchain. Transactions include small programs known as scripts embedded in their inputs and outputs, which specify how and by whom the outputs of the transactions 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 that has network connectivity and runs software that executes an applicable blockchain protocol. Nodes validate transactions and propagate them to other nodes within the network. Specialized network nodes, referred to as "mining nodes" or "miners", collect sets of unconfirmed transactions, i.e., transactions in progress, into blocks and attempt to "mine" those blocks. Mining, in these examples, refers to solving a Proof of Work (POW) before any other miner in the network succeeds in solving the Proof of Work for each respective block. In the case of Bitcoin, the POW involves hashing a block header including a nonce until the result is below a threshold set by a difficulty parameter. The nonce is repeatedly incremented and the hashing is repeated until the result is below the threshold or the miner receives notice that another miner has succeeded. Variations of the mining process are well known to those skilled in the art.

[0033] Among the various things that are checked 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 previous transaction. Some nodes may maintain an execution list or pool of UTXOs so that they can quickly determine whether a referenced transaction output is within the UTXO. The list or pool of UTXOs may be referred to as the “unspent transaction output set”. The blockchain network is configured to update and maintain the unspent transaction output set to prevent double-spending attacks. A transaction may be identified by its unique transaction identifier TxID, which in some implementations is the hash of the transaction. Some transactions may have more than one output, and thus a unique transaction output (i.e., an outpoint) may be identified by the TxID and an index, which refers to one of the outputs within an ordered set of outputs from the transaction. If a transaction output is present in the UTXO pool or set, the output of that transaction is “unspent” and available for use as an input.

[0034] The unlock script for a transaction output point defines how "control" over its output should be proven for it to be executed. Often, the address associated with a transaction output is the hash of a public key. To prove control over that output, the unlock script often requires a public key and a digital signature generated using the corresponding private key. In this way, the node controlling the private key can control how the transaction output is used at any subsequent input. As will be further explained below, this has the consequence that if a transaction input corresponding to a particular public key contains a digital signature generated using the corresponding private key, the entity associated with that particular public key has effectively signed or attested to the transaction content.

[0035] Public key cryptography has become ubiquitous in online communication. In many cases, processes and policies are required to provide the certainty that a public key is owned by an entity associated with it. The most common way to ensure that a public key is genuine and not exposed to risks is public key infrastructure (PKI). PKI relies on trusted third - party organizations to "authenticate" a public key as valid. These entities are "certificate authorities" (CAs). CAs provide the registration and issuance of digital certificates that confirm the binding between a public key and a specific owner. The holder of the public key provides that public key and its digital certificate to another entity. The other entity can then verify the authenticity of the public key by checking that a trusted CA has digitally signed the public key as belonging to the holder.

[0036] One problem with existing PKIs is that, for example, if a private key is lost or disclosed before the specified expiration date of a certificate, the public key may be put at risk. For that reason, a CA may maintain a certificate revocation list. Entities that wish to rely on a certificate associated with a public key must also search for and examine the relevant certificate revocation list to confirm that the certificate has not been revoked by the CA. This impairs the ability to authenticate keys offline and creates a risk due to the delay between revocation and the issuance of a new certificate revocation list, which is often more than 24 hours.

[0037] According to one aspect of the present application, a blockchain network may be used to improve the public key infrastructure by providing fast and secure validation, revocation, and renewal of digital certificates. The public key may be recorded on the blockchain by a certification authority so that any third party can quickly and easily verify that the public key has been certified by the certification authority and that the certification has not been revoked. By recording the public key in the manner described below, the certification authority may be able to revoke the certification almost instantaneously, 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 the 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 schematically shown. 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 can 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. The CA is shown as being implemented by the server 106, but it will be understood that the CA functionality can 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, but in this example, for ease of explanation, they are shown as separate nodes from the blockchain network 108.

[0040] In this exemplary system 100, the first computing device 102 labeled "Alice" has a public-private key pair for use in asymmetric cryptographic communications. For using the public key in some cryptographic scenarios, Alice may need to have the public key and a corresponding digital certificate that authenticates her association with it. Thus, in operation 110, Alice sends the public key PK along with a registration request AProvide it to the CA. The CA may engage in a certain level of authentication to guarantee Alice's identity as the owner of the public key. In some cases, this authentication may be an automated online operation performed by the 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 determines that the public key PK A is to be proven, and generates a blockchain transaction, a "proof transaction" (CTX), that includes the public key PK A and is signed by the CA. The proof transaction further includes an output controlled by the CA. As shown by operation 112, the transaction is submitted to the blockchain network 108. Next, in operation 114, the CA provides the proof transaction identifier TxID CTX_PKA to Alice. In some implementations, Alice may obtain a copy of the proof transaction from the blockchain network 108 based on the transaction identifier and verify that it conforms to expectations and includes the public key PK A .

[0042] The transaction identifier TxID CTX_PKA effectively forms a digital certificate for Alice together with the public key PK A . In this example, in relation to some communication with a second communication device 104 labeled "Bob", Alice may send that digital certificate to Bob in operation 116. Bob can then authenticate the public key PK A and verify that the proof has not been invalidated 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 proof transaction. From the proof transaction, Bob may verify that it contains the public key PK A and that it is signed by a trusted certificate authority. Bob may further query whether the transaction output controlled by the CA remains "unused", 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, to verify that the proof has not expired. The UTXO pool 130 is a pool of "unused" transaction output points maintained by any one of several nodes of the blockchain network 108.

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

[0045] In operation 202, the certificate authority receives a request for proof of the public key PK A from Alice. The certificate authority may execute an authentication or authorization protocol according to its applicable policies. Those protocols may include automated computer-implemented operations and / or operations facilitated by an administrator. Regardless of the particular authentication operation, in operation 204, a determination is made as to whether to prove Alice's public key. If not, method 200 ends. If proof is permitted, in operation 206, the certificate authority creates a proof transaction. As described above, the proof transaction includes an input containing the public key of the certificate authority and a digital signature from the certificate authority, an output controlled by the certificate authority, and the public key PK AIt includes the following. Taking a specific example, the input can be any nominal value or an arbitrary value UTXO for which the certification authority has a private key to generate a signature in a valid unlock script. The UTXO can be associated with a digital value sufficient to offset any transaction fee to be paid for mining the proof transaction.

[0046] The proof transaction includes a first output based on the CA public key PK selected and controlled by the certification authority CTX_PKA and a second output including, for example, the public key PK in a non-operational information field A and may include two outputs. An example of the latter is the OP_RETURN function in Bitcoin. OP_RETURN is an output where any data can be placed for recording on the blockchain when the transaction is mined.

[0047] The first output can be, for example, a P2PKH (pay to public key hash) operation that designates a transfer to a public key hash (e.g., a Bitcoin address) selected and controlled by the certification authority.

[0048] With the digital signature in the transaction, the certification authority authorizes the input of the UTXO to the transaction, thereby not only satisfying the unlock script but also providing verifiable evidence that the public key PK appearing in the OP_RETURN output has been certified by the certification authority. Note that in some implementations, additional information such as a digital signature from Alice or other such data may appear in the OP_RETURN output field. A When the proof transaction is created, the certification authority, in operation 208, uses the transaction identifier TxID

[0049] to... CTX_PKAHash the transaction to find it and propagate the transaction on the blockchain network as shown by operation 210. To "propagate" a transaction is understood to include submitting it to the nodes of the blockchain network, verifying it there, sending it to all other nodes, and then having all other nodes verify and re-send it until the transaction reaches substantially all nodes within the network. In some embodiments, the certification authority is itself one of the nodes within the blockchain network.

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

[0051] Alice can then provide a digital certificate containing Alice's public key PK A and the certification transaction identifier TxID CTX_PKA to any third party. From this, the third party can verify that Alice's public key has been certified by the CA.

[0052] A simplified example of the certification transaction is shown below:

Table 1

[0053] Note that the unlock script for the input includes the public key of the certification authority and the signature generated by the certification 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 certification authority.

[0054] Referring now to FIG. 3, one exemplary method 300 for verifying a public key is shown. The operations described in the exemplary method 300 may be performed by a computing device attempting to verify a public key that is claimed to be proven using the process illustrated in FIG. 2. The exemplary computing device includes any network-enabled computing device.

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

[0056] From a proof transaction, a computing device may verify certain things. In particular, in operation 306, the computing device may verify that the proof transaction is signed by a certificate authority. The computing device may have, or have access to, a list of recognized or accredited certificate authorities and their respective public keys that may enable the computing device to validate a digital signature. The digital signature may form part of the input to the proof transaction, as described. By confirming that the proof transaction is signed by a trusted or recognized certificate authority, the computing device can confirm that the proof is valid. Note that the computing device does not necessarily need to verify the digital signature within the input, as the transaction will be confirmed and verified by the miner if the transaction 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] As shown by operation 308, the computing device can further verify that one of the output points of the proof transaction remains "unused", i.e., that output point is found in the UTXO pool. This verification operation confirms that the proof remains valid and has not expired. As described above, in most embodiments (alternatives will be described later), this output point is controlled by the certification authority, which enables the certification authority to revoke the proof if the key is compromised, has expired, or has become invalid for other reasons. Revocation or cancellation is easily facilitated by having the certification authority "use" the output point and remove the output point from the UTXO pool. Verification that the output point exists in the UTXO pool can be performed, for example, by querying the UTXO pool based on the TxID number and the output index. In some examples, the computing device can query the UTXO pool through an intermediary such as a node in the blockchain network.

[0058] In operation 310, the computing device checks that the public key PK in the second output of the proof transaction A matches the public key PK received from Alice as part of the digital certificate. A

[0059] When operations 306, 308, and 310 are all confirmed, the computing device determines in operation 312 that the public key PK within the digital certificate received from Alice A is valid.

[0060] Rather than recording the public key proof using a blockchain network, the certificate authority can quickly and easily invalidate the proof by "using" the output point so that the verification in operation 308 ends in failure. Thus, the certificate authority can invalidate the proof of the public key by generating and propagating a transaction that uses the first output of the proof transaction. As described above, the first output can be a P2PKH operation that transfers the 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 requires control over the private key corresponding to the CA public key PK CTX_PKA required for.

[0061] In some cases, rather than simply invalidating the proof, the certificate authority may be required to replace / update the proven public key. For example, if the private key is lost or compromised, the owner (e.g., Alice) may request that the certificate authority update or replace the previously proven public key with a new public key PK A_new . If the certificate authority authenticates the request using the online or offline authentication mechanism being implemented and determines that the update operation should be performed, it creates a new proof transaction CTX new to invalidate the old proof and issue a new proof.

[0062] The new proof transaction features a P2PKH operation that uses the same type of output, i.e., a new public key selected by the CA such as PK CTX_new and an OP_RETURN field containing PK A_new . However, the input is the original proof transaction TxID CTX_PKAIt may include a CA control output point from. By "using" the output as an input to a new proof transaction, invalidation is achieved by removing the output point from the UXTO pool. Advantageously, the invalidation of the old public key proof and the registration of the new public key proof are performed in a single transaction. Further, a separate periodically issued list of certificate invalidations need not be maintained and made available by the certificate authority.

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

[0064] For example, in some situations, the owner of the public key, such as Alice, may have the right to invalidate her own public key. In this configuration, the first output point in the certificate transaction is controlled by Alice, i.e., it refers to the 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 can be advantageous for some public key proof scenarios, such as registration for an online service. An example of an online service is a social media account on a social media platform. The platform can use the mechanism described above to register the user's public key for use on the platform, whereby the user can interact with the platform and / or other users of the platform in a trustworthy manner using their digital certificate backed up via a proof transaction. The user can then invalidate the proof to terminate the account without the cooperation of the platform.

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

[0066] Alternatively, if the revocation of any one of a plurality of parties should 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, Multi-sig may be used in the output.

[0067] In yet another scenario, multi-sig may be configured to ensure that at least a threshold number of entities agree to the revocation of the proof. Multi-sig may be configured to require n out 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 group of individuals, the proven public key associated with the organization may be revocable only if all or at least a threshold number of specific entities such as the CEO, COO, CTO, or other officers or individuals involved with the corporation approve the revocation.

[0068] It will be understood that some or all of the operations of the various above-described exemplary methods may be performed in an order other than that shown, and / or may be performed concurrently without changing the overall operations of those methods.

[0069] Automatic Proof Verification The above method provides a mechanism for issuing digital certificates protected by a blockchain network. This mechanism enables fast verification of the validity of digital certificates and the ability to almost immediately invalidate digital certificates. As described above, to verify the validity of a digital certificate, a node requesting a certificate validity check checks whether the outpoint of the certificate transaction is within the UTXO set and whether the public key in the digital certificate being verified 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 verification of a digital certificate and any subsequent transaction that depends on that verification. During that interval, the digital certificate may be invalidated for some reason. Furthermore, the verification of digital certificates 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 may require those nodes to rely on third-party nodes to perform their verification, raising concerns about security and reliability. Additionally, the nodes that verify that the outpoint is within the UXTO set must be online with active access to the blockchain network, and many nodes such as lightweight SPV may not have that at a particular time.

[0071] According to another aspect of the present application, the certificate validity check can be incorporated into a transaction such that the transaction proceeds only if the digital certificate is valid. This allows lightweight SPV and similar nodes to cooperate with other nodes when generating transactions that incorporate automatic digital certificate validity checks. Advantageously, this can eliminate the temporal gap between the verification of the digital certificate and its reliance on that verification when committing to a transaction.

[0072] In some of the following examples, a node may have its public key attested by a certification authority in the form of a proof transaction, which may take the form of this example:

Table 2

[0073] The above example is a proof transaction that attests to the public key PK of node A A Note that the OP_RETURN output includes a certificate for the public key PK A . In some examples, this may simply be the public key itself. In some cases, it may be the 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 the certification authority, and its unlock script is signed by the certification authority. The output is a pay-to-public-key-hash (P2PKH) for the proof transaction public key

Number

Number

Number

[0075] Such a certificate can be invalidated or made void by using the outpoint in a subsequent transaction that contains a signature using the secret key corresponding to the proof transaction public key. In this example, both the certificate authority node and node A own this key.

Number

[0076] Generally, a node (e.g., Alice) having a digital certificate that proves its public key generates a transaction template that includes the outpoint of the certificate as an input. The input is signed with the proof transaction key, for example, using the secret key corresponding to the P2PKH output of the proof transaction. This transaction template is provided to another node (e.g., Bob) participating in the transaction. Another node, Bob, retrieves the proof transaction based on the reference to the TXID for the proof transaction in the input to the transaction template and the intended public key PK

[0077] A ​Verify that it is actually proven by the proof transaction and add any input / output that completes the transaction template. The transaction template can then be propagated on the blockchain network. If the input signed by the proof 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 neither propagated nor mined. If the input signed by the proof transaction key is valid because it is within the UTXO set, the transaction is verified, propagated, enters the mempool, and ultimately enters the block to be mined.

[0078] In one example, this mechanism can be used to verify the recipient's address. For example, in a situation where Alice requests a digital asset or some other transfer from Bob, Bob may wish to verify that Alice's identity, e.g., Alice's intended public key, is proven before committing to such a transaction. In such a situation, Alice can prepare a transaction template that includes a payment to Alice's public key along with an input that references the proof transaction for that public key. Upon receiving the transaction template, Bob can retrieve the proof transaction from the blockchain, verify that it proves Alice's public key, and confirm that it is digitally signed by a certificate authority. Bob can then add an input to the transaction template for transferring the digital asset, and then the transaction template can 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 above exemplary transaction, Bob

Number

[0080] In another example, this mechanism may be used to verify the sender's address, for example, to meet Know Your Customer (KYC) requirements. For example, Alice is transferring an asset to Bob, and Bob wishes to verify Alice's identity before accepting the transfer. In this case, Alice transfers a digital asset and prepares a transaction template that includes an input signed in relation to her public key PK A This also includes a proof transaction that proves the public key as an input. Upon receiving the transaction template, Bob can obtain the proof transaction, verify that it is signed by a certificate authority, and verify that it proves Alice's public key. If so, Bob completes the transaction template by adding an output for transferring the digital asset to a public key address controlled by Bob. Such an exemplary transaction may take the following form:

Table 4

[0081] In each of the two above detailed examples, it will be understood that as soon as a digital certificate is used in a transaction to prove the validity of a public key, it becomes invalid. That is, the certificate can be used only once and automatically expires once it is used. This can be applied to some cases such as for a single transfer of a large asset value to or from a verified address. Such a transaction can be used in the case of transfer of a motor vehicle, a real estate transaction, sale of stocks, or other such high-value transfers. However, in more low-value daily transactions, it may be cumbersome to go back to the certification authority to request a new certificate each time the certificate is used. Therefore, as will be described later, a multi-use certificate can be constructed.

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

[0083] Method 400 provides an example of automatic certificate verification for verifying the identity of a recipient. In this exemplary transaction, node A is the recipient and node B is the sender. The nodes can communicate over a wired network and / or a wireless network. In some cases, the nodes may communicate using short-range communication, for example via a point-of-sale terminal. Method 400 begins, in operation 402, with node A creating a transaction template. The transaction template proves the identity of node A, for example the public key PK of node A AIncludes an input that references a proof transaction output from a proof transaction to prove. The output within the proof transaction is a pay-to-public-key operation that references the proof transaction public key

Number

Number

[0084] As shown by operation 404, node A sends this transaction template to node B. The transaction template does not yet include an input from node B and / or, if an input is included, is not signed by node B.

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

[0086] Having a copy of the proof transaction, at operation 408, Node B verifies that the proof transaction is signed by the certificate authority using the certificate authority key. Also, Node B verifies that the public key PK of Node A A appears in the OP_RETURN output field of the proof transaction, thereby confirming that the certificate authority is proving the authenticity of the public key of Node A. Node B may further verify the validity of the structure of the proof transaction, in particular, the proof transaction public key that matches the input to the transaction template.

Number

[0087] If these checks fail, for example, if the public key of node A cannot be verified as proven, or if the proof transaction is not structured as expected, node B will not complete the transaction, so it will be understood that method 400 ends. However, assuming that node B verifies that the proof transaction is valid, in operation 410, node B modifies the transaction template to add an input from the address controlled by node B. That is, node B adds a resource input to the transaction template and signs that input. This completes the transaction template, and then node B can propagate it on the blockchain network. Alternatively, node B may send the completed transaction template to node A, and node A may propagate it on the blockchain network.

[0088] In either case, as shown by operation 412, one of two things is done.

Number

Number

[0089] Referring now to FIG. 5, another exemplary method 500 for automatically validating a digital certificate is shown in flowchart form. Similar to FIG. 4, the method 500 shown in FIG. 5 can be executed by a computing device implementing node A, the first node, and node B, the second node. In an example of method 500, a transaction for transferring a resource from node A to node B is generated. Before accepting the transfer of the resource, node B attempts to validate the identity of node A, for example, as part of "know-your-customer" or anti-fraud record-keeping requirements.

[0090] Node A creates a transaction template in operation 502 and includes an input that references a proof transaction output from a proof transaction that proves node A's public key. The input is signed by node A using a proof transaction key corresponding to the proof transaction public key referenced in the proof transaction output. Node A also adds an input for transferring the resource from its proven 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 proof transaction from the blockchain, regardless of whether it is stored locally or remotely. The proof transaction is identified by a transaction identifier that is referenced in the input to the transaction template.

[0092] In operation 508, node B verifies that the proof transaction is signed by the certificate authority using the certificate authority key. Also, node B verifies that the public key PK A of node A appears in the OP_RETURN output field of the proof transaction, thereby confirming that the certificate authority has attested to the authenticity of the public key of node A. Node B may further validate the structure of the proof transaction, in particular, the proof transaction public key

Number

[0093] If these checks fail, for example, if the public key of node A cannot be verified as proven, or if the proof transaction is not structured as expected, node B will not complete the transaction, and it will be understood that method 500 ends. However, assuming that node B verifies that the proof transaction is valid, in operation 510, node B may modify the transaction template to add an output to the address controlled by node B. In some cases, node A may already have added an output for transferring resources to node B, and in that case, node B only needs to verify that the output is correct in operation 510. This completes the transaction template, and then node B can propagate it on the blockchain network. Alternatively, node B may send the completed transaction template to node A, and node A may propagate it on the blockchain network.

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

Number

Number

[0095] Multi-use certificate As described above, in the example mentioned above, it was assumed that the digital certificate becomes invalid because the proof transaction output becomes "used" when it is used in a transaction to prove the validity of the public key. That is, the certificate can only be used once and is automatically invalidated when used. In some situations, it may be desirable for a node to have a multi-use certificate that can be used multiple times without the need to obtain an unused certificate from the certificate authority after each use.

[0096] In one example, a multi-use certificate can be created by providing multiple proof transaction outputs in a certificate transaction. The proof transaction can be structured to provide m possible uses. Each output can only be used once in the verification operation. When each output becomes "used", it becomes unavailable. An example of such a certificate transaction is shown below: [Table 5]

[0097] Public key [Number] They may be the same public key, may be completely independent and different public keys from each other, or may be different public keys that are provably linked to each other. When node A uses this proof transaction in a transaction template like the above example, node A ensures that the proof transaction output referred to as an outpoint in the transaction template is one of the m outputs that have not been used yet.

[0098] Node A can invalidate its own certificate by submitting a transaction that uses all of the remaining unused transaction outputs of the certificate. The certification authority can do the same to invalidate the certificate, but if the certification authority does not have a reliable awareness of which of the outputs in the proof transaction have already been used, the certification authority submits a separate transaction for each output to ensure the invalidation of the certificate.

[0099] The above exemplary multiple-use certificate is advantageous in that node A can use it up to m times. However, after all the outputs are used up, node A must obtain a new certificate from the certification authority. In another example, the certificate verification process can be constructed such that each verification further generates a new outpoint linked to the certificate transaction, thereby constructing a chain of transactions that leads back to the original proof transaction.

[0100] In one exemplary implementation, if the ability of the certification authority to invalidate the certificate is not required, a certificate of the form described above can be used. Each time node A uses the certificate in a transaction, node A ensures that the transaction generates a new pay-to-public-key output and uses it as a proof transaction output in any subsequent transaction that later uses the certificate.

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

Table 6

[0102] Certification transaction public key

Number

[0103] To use the certificate, Node A creates a transaction template that includes a 1-of-2 multi-sig output that references both the certification authority and the new certification transaction key

Number

[0104] As an example, consider that Node A enters into a transaction with Node B, 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 can take the following form:

Table 7

[0105] In the above exemplary transaction, note that one of the inputs is a public key PK controlled by node B B from. This input is added to the transaction template by node B after node B has confirmed that the structure of the transaction template is valid and that the certificate for node A has been verified.

[0106] The transaction is structured to transfer the resource y BSV to the public key PK A as indicated by the first outpoint. Another input references the proof transaction output

Number

Number

[0107] Node B provides the updated proof key to node A and may optionally further evaluate whether node A has properly structured the proof transaction output in the current transaction template so that the certificate authority can invalidate the proof if necessary, but node B does not necessarily have to confirm this to proceed with the transaction.

[0108] After the above transaction is submitted to the blockchain network, Node A can then prove its identity using the new linked public key

Number

Number

Number

Number

Number

Number

Number

[0109] Subsequent transactions with the proof of Node A are executed in the same way, and other nodes trace a series of linked transactions to ensure that their proof transaction outputs are correctly structured until they reach the original proof transaction.

[0110] Referring now to FIG. 6, a portion of method 600 for validating a digital certificate using linked transactions is shown in flowchart form. Method 600 provides an example of automatic certificate verification for verifying the identity of a recipient. In this exemplary 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 the identity of Node A, for example, the public key PK of Node A A includes an input that refers to the proof transaction output from the last transaction in a series of linked proof transactions that trace back to the original proof transaction that proves, for example, the public key PK. The output in the last proof transaction is a pay-to-public-key operation that refers to

Number

Number

[0111] ​In operation 604, node A sends this transaction template to node B. The transaction template does not yet contain the input from node B and / or, if the input is included, it is not signed by node B.

[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 the original proof transaction if node A has not previously used its certificate, or it may be a linked proof transaction. In operation 608, node B evaluates whether it is the original proof transaction. The original proof transaction includes an OP_RETURN output containing the certificate for PK A and the linked proof transaction includes two or more signed inputs that reference the previous transaction outpoint, one of which is the previous proof transaction and the other of which may be an input resource to the linked proof transaction. If node B determines that the retrieved transaction is a linked proof transaction and not the original proof transaction, in operation 610, it determines whether the referenced outpoint is structured validly. For example, the outpoint is, for the referenced proof public key, e.g.,

Number

Number

[0113] Once the original proof transaction is identified, in operation 612, node B verifies that the proof transaction is signed by the certification authority using the certification authority key. Also, it verifies that node A's public key PK A appears in the OP_RETURN output field of the proof transaction, thereby confirming that the certification authority is proving the authenticity of node A's public key. It may further verify that the proof transaction output is a 1-of-2 multi-sig output to the proof transaction public key [Number] and the certification authority public key PK CA When node B is satisfied that the original proof transaction is valid, in operation 614, it adds an input to the transaction template to supply the resources transferred to node A's public key PK

[0114] A Then, in operation 614, it submits the completed transaction template to the blockchain network and, as shown by operation 616, the proof transaction public key in the last proof transaction in the series of proof transactions

Number

[0115] In one implementation, the value transferred to each proof transaction output in a series of proof transaction outputs may be a fixed value x that a verification node confirms when evaluating the format and content of each transaction in the series of transactions. In another implementation, in order to set an upper limit on the number of times a proof can be reused, the value may start from a fixed amount in the original proof transaction and may be decremented by a fixed amount with each use so that no further updates occur at a certain point. In some implementations, the decremented amount may match the amount of the transaction fee.

[0116] It will be understood that the certificate authority can identify the latest transaction in a series of proof transactions and invalidate this certificate by using a 1-of-2 multi-sig output using the certificate authority's key.

[0117] Referring now to FIG. 7, a simplified computing device 700 according to an 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 that may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. Computing device 700 may further include a memory 704 that may include persistent and non-persistent memory for storing values, variables, and in some instances processor-executable program instructions, and a network interface 706.

[0119] Computing device 700 may include a processor-executable application 708 that, when executed, causes 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 in no way intended to limit the scope of this application. Modifications of the innovations described herein will be apparent to those skilled in the art, and such modifications are within the intended scope of this application. In particular, alternative exemplary embodiments can be created by selecting features from one or more of the above-described exemplary embodiments to include sub-combinations of features that may not have been explicitly described above. Additionally, alternative exemplary embodiments can be created by selecting and combining features from one or more of the above-described exemplary embodiments to include combinations of features that may not have been explicitly described above. Features suitable for such combinations and sub-combinations will readily become apparent to those skilled in the art upon review of the present application as a whole. The subject matter described herein and in the claims is intended to cover and embrace all suitable modifications in the art.

Claims

**Claim 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 referring to a current key registration transaction output; Identifying the last transaction in a series of linked transactions based on the last transaction including the current key registration transaction output; Traversing the series of linked transactions to identify and obtain a key registration transaction including 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 wherein the propagated transaction template includes a second input for transferring a resource to an output address; whereby the transaction template is validated by nodes on the blockchain network if the current key registration transaction output is included within a set of unspent transaction outputs. A method. **Claim 2** The method according to claim 1, wherein the transaction template includes an input from the first public key associated with the first node. **Claim 3** The method according to claim 2, wherein propagating includes adding an output to a second public key associated with a second node to the transaction template prior to propagation. **Claim 4** The method according to claim 1, wherein the transaction template includes an output to the first public key associated with the first node. **Claim 5** The method according to claim 4, wherein propagating includes adding an input from a second public key associated with a second node to the transaction template prior to propagation. **Claim 6** The method according to any one of claims 1 to 5, wherein the key registration transaction output includes a pay-to-public-key output in the last transaction. **Claim 7** The key registration transaction output is one of a plurality of pay-to-public-key outputs in the last transaction, and each of the pay-to-public-key outputs in the last transaction is accompanied by a different respective public key, the method according to claim 6. **Claim 8** The obtaining further includes verifying that the key registration transaction output is a multi-signature output in which the permitted signer includes the third party key, the method according to any one of claims 1 to 7. **Claim 9** The set of unspent transaction outputs includes all transaction outputs that have not yet been used as inputs to further transactions, and the set of unspent transaction outputs is maintained by the blockchain network, the method according to any one of claims 1 to 8. **Claim 10** The obtaining includes sending a request for the key registration transaction to a node within the blockchain network and receiving a response including the key registration transaction, the method according to any one of claims 1 to 9. **Claim 11** The 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 on the blockchain based on the copy of the last transaction, the Merkle path, and a set of block headers of the blockchain, the method according to any one of claims 1 to 9. **Claim 12** A computing device for validating a first public key associated with a first node, one or more processors; a memory; computer-executable instructions stored in the memory that, when executed by the one or more processors, cause the processor to execute the method according to any one of claims 1 to 11 and a computing device comprising the same. **Claim 13** A computer-readable medium storing processor-executable instructions for validating a first public key associated with a first node, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processor to execute the method according to any one of claims 1 to 11.

Images