Multi-factor authentication using blockchain transactions

Abstract

A method of providing a credential to enable a second party to verify the identity of a first party. The first party is associated with a first public key registered with a third party. One or more first credentials are provided to the second party. A request transaction is obtained, the request transaction comprising a) an input comprising a signature generated based on a corresponding private key of the third party, and b) an output locked to a second public key of the first party. The second public key is based on the first public key. The second public key is based on the first public key. A confirmation transaction is generated, the confirmation transaction comprising an input referencing the output of the request transaction and a signature generated based on a private key corresponding to the second public key of the first party. The confirmation transaction is transmitted to nodes of a blockchain network for inclusion in a blockchain.

Description

Technical Field

[0001] This disclosure relates to methods for using blockchain transactions to verify the identity of parties. Background Technology

[0002] A blockchain is a form of distributed data structure in which copies of the blockchain are maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain consists of a chain of data blocks, where each block comprises one or more transactions. Each transaction can point back to previous transactions in sequence, and each transaction can span one or more blocks. Transactions are submitted to the network to be included in new blocks through a process called "mining," which involves each of multiple mining nodes competing to perform "proof-of-work," i.e., solving cryptographic puzzles based on pending transactions waiting to be included in a block.

[0003] Traditionally, transactions in blockchains are used to transfer digital assets—data that acts as a store of value. However, it's also possible to leverage blockchains to add additional functionality on top of them. For example, blockchain protocols can allow additional user data to be stored in the output of a transaction. Modern blockchains are increasing the maximum data capacity that can be stored in a single transaction, enabling the consolidation of more complex data. This can be used, for example, to store electronic documents, or even audio or video data, within the blockchain.

[0004] Each node in the network can have one, two, or all of the following three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions throughout the network. Mining nodes mine transactions into blocks. Storage nodes store copies of their respective mined blocks in the blockchain. To record a transaction in the blockchain, the parties send the transaction to one of the network's nodes for propagation. Mining nodes receiving the transaction may compete to mine it into a new block. Each node is configured to adhere to the same node protocol, which includes one or more conditions for transaction validity. Invalid transactions are neither propagated nor mined into blocks. Assuming the transaction is verified and therefore accepted by the blockchain, additional user data is thus retained as an immutable public record on every node in the P2P network.

[0005] Multi-factor authentication (MFA) is increasingly being introduced into various systems that require verification of individuals or entities seeking access. For example, MFA might be used when attempting to access an online banking account. An MFA is an authentication protocol that requires entities seeking access to the system to provide multiple authentication methods, typically based on separate credential categories. Typically, the first factor is a password, while another factor can range from biometric data to SMS text. These MFA schemes are expected to provide a higher level of security for systems using them. Summary of the Invention

[0006] Two-factor authentication (2FA) is a type of MFA that requires two different forms of credentials to verify or authenticate a user's identity. For 2FA, SMS text messages are typically used. In this implementation, after the password is submitted, an SMS text message containing a specific code is sent to the user. The user then uses this code as a second authentication factor. The security of this system presupposes that a malicious actor (in addition to the target's password) is unlikely to have access to the target's SMS phone calls and / or text messages.

[0007] However, despite the increasing inclusion of 2FA in authentication protocols, problems and vulnerabilities still exist in such 2FA designs. For example, the timing of SIM switching allows attackers to steal a target's phone number, meaning they can intercept SMS messages and obtain verification codes.

[0008] Therefore, an improved and more secure protocol is needed to solve the current multi-factor authentication problem, especially a protocol that is not easily intercepted by attackers who attempt to steal personal identities.

[0009] According to one aspect disclosed herein, a method is provided for providing credentials to enable a second party to verify the identity of a first party, wherein the first party is associated with a first public key, wherein the first public key is registered with a third party, wherein the method includes: providing one or more first credentials to the second party; obtaining a request transaction, the request transaction being a blockchain transaction that has been transmitted to one or more nodes of a blockchain network, and including a) an input comprising a signature generated based on a corresponding private key of the third party and b) an output locked to a second public key of the first party, wherein the second public key is based on the first public key; generating a confirmation transaction, the confirmation transaction being a blockchain transaction, which includes an input referencing the output of the request transaction and a signature generated based on a private key corresponding to the second public key of the first party; and causing the confirmation transaction to be transmitted to one or more nodes of the blockchain network for inclusion in the blockchain.

[0010] Due to the cryptographic nature of public-private key pairs, only a party authorized to access the correct private key can generate a signature, which can be verified using the corresponding public key registered by a third party. Therefore, a signed confirmation transaction acts as another (e.g., a second) credential (or authentication factor) that can be used to verify the identity of the first party. Since the request transaction has an output locked to the registered public key, only the first party can generate a transaction (confirmation transaction) that unlocks (i.e., spends) that output. Thus, any party can verify the identity of the first party by checking whether the first party has generated a confirmation transaction. If a party cannot generate a confirmation transaction, they cannot access the correct private key and therefore are not the first party.

[0011] Note that in order to register their public key with a third party, the first party does not need to share their private key (hence the use of the word "private"). In fact, the first party never needs to share their private key with any other party. Therefore, the provided method does not rely on sharing any authentication codes, thus resisting the opportunity for attackers to intercept these codes and use them to improperly identify themselves as the first party.

[0012] This method can be used as part of a 2FA protocol, where the signed confirmation transaction is the second credential (or authentication factor). However, more generally, this method can be used as any MFA protocol, where the signed confirmation transaction serves as the nth credential.

[0013] As an illustrative example, a user (the first party) can be a customer of a merchant (the second party) and may have already registered their public key with their bank (the third party). When attempting to purchase from the merchant, the customer provides the merchant with initial credentials such as credit card information, name and address, and contact number. The merchant can request the bank to verify the user's identity, thereby generating a request transaction that can pay the public key registered by the first party. The public key can be registered as part of the bank's Know Your Customer (KYC) protocol. The user obtains this request transaction, for example, by scanning the blockchain, and then generates a signed confirmation transaction. The bank sees that the confirmation transaction has been signed by a signature that only the first party (if they possess the private key corresponding to their registered public key) can generate, and notifies the merchant that the user they are processing is indeed the first party. The merchant and user can then proceed with their transaction, such as purchasing goods or services.

[0014] As another example, a user (the first party) might be trying to access their email account, which is hosted by an online provider (the second party). The user first provides their username and password, and in response, the request transaction is submitted to the nodes of the blockchain network. This request transaction can be generated by the online provider (in this case, the second party is the third party) or a trusted third party. Once a signed confirmation transaction is generated, the user is granted access to their email account.

[0015] According to another aspect disclosed herein, a method for verifying the identity of a first party is provided, wherein the first party is associated with a first public key, wherein the first public key is registered with a third party, and wherein the method includes: receiving a request for verifying the identity of the first party; generating a request transaction, the request transaction being a blockchain transaction, which includes a) an input including a signature generated based on a corresponding private key of the third party and b) an output locked with a second public key of the first party, wherein the second public key is based on the first public key; causing the request transaction to be transmitted to one or more nodes of a blockchain network for inclusion in the blockchain; and determining whether a confirmation transaction has been transmitted to one or more nodes of the blockchain network for inclusion in the blockchain, the confirmation transaction being a blockchain transaction including an input referencing the output of the request transaction and a signature generated based on a private key corresponding to the second public key of the first party.

[0016] As described above, the output of the request transaction is locked to the registered public key. For example, this output could be a "payment public key hash" (P2PKH) output, which requires the input of the spending transaction to contain the registered public key and a signature generated using the private key corresponding to the registered public key. Only the first party knows the private key required to correctly generate such input. Therefore, the party (e.g., the second or third party) can verify the identity of the user reported as the first party by determining whether a confirmation transaction for the spending request transaction has been submitted to the blockchain network. Note that, as will be discussed below, neither the request transaction nor the confirmation transaction needs to be recorded in the blockchain to verify the identity of the first party.

[0017] In some cases, the second party may use an independent third party (such as a trusted third party) as part of the agreement to verify the identity of the party. In other cases, the second party itself may be a third party that registers the public key for the first party. Attached Figure Description

[0018] To aid in understanding the embodiments of this disclosure and to demonstrate how these embodiments can be implemented, reference is made to the accompanying drawings by way of example only, wherein:

[0019] Figure 1This is a schematic block diagram of a system used to implement blockchain;

[0020] Figure 2 Several examples of transactions that can be recorded in a blockchain are illustrated schematically;

[0021] Figure 3 This is a schematic block diagram of another system used to implement blockchain;

[0022] Figure 4 This is a schematic block diagram of a short-node software that processes transactions based on a node protocol of the output model.

[0023] Figure 5 This is a schematic diagram of a system that uses blockchain transactions to verify the identity of the parties involved.

[0024] Figure 6 This is a schematic diagram of another system that uses blockchain transactions to verify the identity of the parties involved.

[0025] Figure 7 This is a sequence diagram of an exemplary method for verifying the identity of parties using blockchain transactions obtained from the blockchain;

[0026] Figure 8 This is a sequence diagram of another exemplary method for verifying the identity of parties using blockchain transactions obtained from the blockchain;

[0027] Figure 9 This is a sequence diagram of an exemplary method for verifying the identity of parties using blockchain transactions obtained from a mempool of transactions;

[0028] Figure 10 This schematically illustrates a chain of unconfirmed transactions in a memory mining pool;

[0029] Figure 11 This schematically illustrates a double-spending attempt on a transaction in a memory mining pool; and

[0030] Figure 12 This illustration shows how a memory mining pool can act as a communication medium. Detailed Implementation

[0031] Example System Overview

[0032] Figure 1An exemplary system 100 for implementing blockchain 150 is generally shown. System 100 includes a packet-switched network 101, which is typically a wide area network, such as the Internet. Packet-switched network 101 includes a plurality of nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within packet-switched network 101. Each node 104 includes a pair of peer computer devices, with different computer devices in node 104 belonging to different peers. Each node 104 includes a processing device that includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium or media. Memory may include one or more storage units employing one or more storage media, such as magnetic media like hard disks; electronic media like solid-state drives (SSDs), flash memory, or EEPROMs; and / or optical media like optical disc drives.

[0033] Blockchain 150 comprises a chain of data blocks 151, wherein individual copies of blockchain 150 are maintained at each of the multiple nodes of the P2P network 160. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses a specific transaction protocol from beginning to end. In a common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the quantity of digital assets belonging to user 103, whose output is cryptographically locked (requiring the user's signature to unlock and thus cash out or spend). Each input points back to the output of the previous transaction 152, thereby linking the transactions.

[0034] At least some of nodes 104 act as forwarding nodes 104F for forwarding and thus propagating transaction 152. At least some of nodes 104 act as miners 104M for mining block 151. At least some of nodes 104 act as storage nodes 104S (sometimes also called "full copy" nodes), each storing a corresponding copy of the same blockchain 150 in its respective storage. Each miner node 104M also maintains a mining pool 154 for transaction 152 awaiting mining into block 151. A given node 104 can be a forwarding node 104, a miner 104M, a storage node 104S, or any combination of two or all of them.

[0035] In a given current transaction 152j, each input includes a pointer to the output of a previous transaction 152i in the transaction sequence, specifying that the output will be cashed out or “spent” in the current transaction 152j. Generally, a previous transaction can be any transaction in mining pool 154 or any block 151. A previous transaction 152i does not necessarily exist when the current transaction 152j is created or even sent to network 106, but it will need to exist and be verified for the current transaction to be valid. Therefore, “previous” here refers to the predecessor in a logical sequence linked by pointers, not necessarily the creation or sending time in chronological order, and thus transactions 152i and 152j that were not created or sent in chronological order are not excluded (see the discussion of orphan transactions below). A previous transaction 152i can also be referred to as a preceding transaction or a prior transaction.

[0036] The inputs of the current transaction 152j also include the signature of user 103a, who has locked the output of the previous transaction 152i. In turn, the output of the current transaction 152j can be crypto-locked to the new user 103b. The current transaction 152j is thus able to transfer the amount defined in the inputs of the previous transaction 152i to the new user 103b along with the amount defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to distribute the input amount among multiple users (one of which may be the original user 103a, so as to allow for modification). In some cases, a transaction may also have multiple inputs to collect the amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0037] The above can be referred to as an "output-based" transaction protocol, sometimes also called an Unspent Transaction Output (UTXO) type protocol (where the output is referred to as a UTXO). The user's total balance is not defined in any single number stored in the blockchain, but rather the user needs a specific "wallet" application 105 to organize the values ​​of all the UTXOs scattered across many different transactions 152 in the blockchain 151.

[0038] Another type of transaction protocol can be called an "account-based" protocol, as part of an account-based transaction model. In an account-based system, each transaction does not define the amount to be transferred by referencing the UTXOs of previous transactions in a past transaction sequence; instead, it defines the amount to be transferred by referencing the absolute account balance. The current state of all accounts is stored separately by miners relative to the blockchain and is continuously updated. In such a system, transactions are ordered using the account's running transaction record (also known as a "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign transactions. This data field can point back to previous transactions, for example, when the previous transaction ID is included in the data field.

[0039] Using any type of transaction protocol, when user 103 wishes to formulate a new transaction 152j, he / she sends the new transaction from his / her computer terminal 102 to one of the nodes 104 of the P2P network 106 (now typically a server or data center, but in principle it could also be another user terminal). The node 104 checks the validity of the transaction according to the node protocol applied at each node 104. The details of the node protocol will correspond to the type of transaction protocol used in the blockchain 150 under discussion, together forming the overall transaction pattern. The node protocol typically requires node 104 to check whether the cryptographic signature in the new transaction 152j matches an expected signature that depends on a previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may include checking whether the user cryptographic signature included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i to which the new transaction is spent, where the condition typically includes checking that at least the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, this condition may be defined, at least in part, by a custom script included in the input and / or output. Alternatively, it may be determined solely by the node protocol, or possibly by a combination of these. Either way, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more additional nodes 104, and so on. In this way, the new transaction is propagated throughout the network of nodes 104.

[0040] In the output-based model, the definition of whether a given output (e.g., a UTXO) is spent depends on whether it has not yet been validly cashed by the input of another preceding transaction 152j, according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to spend or cash has not yet been spent / cashed by another valid transaction. Similarly, if invalid, transaction 152j will not be propagated or recorded in the blockchain. This prevents double-spending, i.e., a spender attempting to spend the same transaction's output multiple times. On the other hand, the account-based model prevents double-spending by maintaining account balances. Again, due to the predefined transaction order, the account balance has only a single defined state at any given time.

[0041] In addition to verification, at least several nodes in 104M compete to be the first to create a transaction block in the so-called mining process, reinforced by "proof-of-work." At mining node 104M, new transactions are added to the pool of valid transactions that have not yet appeared in the block. Miners then compete to assemble a new valid block 151 of transaction 152 from transaction pool 154 by attempting to solve a cryptographic puzzle. This typically involves searching for a "nonce" value such that when the nonce is concatenated with transaction pool 154j and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition could be that the hash output has a certain number of leading zeros. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs. Therefore, this search can only be performed by brute force, consuming significant processing resources at each node 104M attempting to solve the puzzle.

[0042] The first miner node 104M to solve the problem announces the solution to network 106, thus proving that the solution can be easily verified by other nodes 104 in the network (once the hash solution is given, it can be directly verified that the solution causes the hash output to satisfy the condition). Then, based on the solution announced by the winner that has been verified at each of these nodes, the transaction pool 154 marked by the winner's solution is recorded as a new block 151 in blockchain 150 by at least a number of nodes 104 acting as storage nodes 104S. A block pointer 155 is also assigned to a new block 151n, which points back to the previously created block 151n-1 in the chain. Since creating a new block 151 requires a significant amount of effort, proof-of-work helps reduce the risk of double-spending, and since any block containing double-spending may be rejected by other nodes 104, mining nodes 104M are encouraged not to include double-spending in their blocks. Once created, block 151 cannot be modified because it is identified and maintained according to the same protocol at each storage node 104S in the P2P network 106. Block pointer 155 also imposes order on each block 151. Since transaction 152 is recorded in ordered blocks at each storage node 104S in the P2P network 106, this provides an immutable public ledger of transactions.

[0043] Note that different miners 104M competing to solve the puzzle at any given time can do so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they begin searching for a solution. Whoever solves their respective puzzle is able to first define which transactions 152 will be included in the next new block 151n and update the current unmined transaction pool 154. Miners 104M then continue competing to create blocks from the newly defined unmined pool 154, and so on. There is also a protocol for resolving potential "forks," where two miners 104M solve each other's puzzles in a very short time, allowing a conflicted view of the blockchain to propagate. In short, whichever tooth of the fork is the longest will become the final blockchain 150.

[0044] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a new quantity of digital assets out of thin air (as opposed to a normal transaction that transfers a certain quantity of digital assets from one user to another). Therefore, the winning node is said to have "mined" a certain quantity of digital assets. This special type of transaction is sometimes called a "genesis" transaction. It automatically forms part of the new block 151n. This reward incentivizes miner 104M to participate in the proof-of-work competition. Typically, the regular (non-genesis) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the winning miner 104M for creating the block 151n containing that transaction.

[0045] Because mining involves computing resources, each miner node 104M typically takes the form of a server comprising one or more physical server units, or even an entire data center. Each forwarding node 104M and / or storage node 104S can also take the form of a server or a data center. However, in principle, any given node 104 can take the form of a user terminal or a group of user terminals networked together.

[0046] Each node 104's memory stores software configured to run on the processing unit of node 104 to perform one or more of its respective functions and process transactions 152 according to the node protocol. It should be understood that any action attributed to node 104 can be performed by software running on the processing unit of the corresponding computer device. Furthermore, the term "blockchain" as used herein is a general term referring to a type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0047] Similarly, connected to network 101 are the computer devices 102 of each of the multiple parties 103 acting as consumer users. These parties act as payers and receivers in transactions but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily run mining protocols. For illustrative purposes, two parties 103 and their respective devices 102 are shown: a first party 103a and his / her own computer device 102a, and a second party 103b and his / her own computer device 102b. It should be understood that more such parties 103 and their respective computer devices 102 may exist and participate in the system, but for convenience, they are not shown. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to as Alice in this document and the second party 103b as Bob, but it should be understood that this is not restrictive and any reference to Alice or Bob in this document may be replaced with "the first party" and "the second party".

[0048] Each party 103's computer device 102 includes its own processing means, which includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, dedicated processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory cells employing one or more storage media, such as magnetic media like hard disks; electronic media like SSDs, flash memory, or EEPROMs; and / or optical media like optical disc drives. The memory on each party 103's computer device 102 stores software including a corresponding instance of at least one client application 105 arranged to run on the processing means. It should be understood that any action belonging to a given party 103 herein can be performed using the software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device (such as a smartwatch). The computer device 102 of the given party 103 may also include one or more other networked resources, such as cloud computing resources accessed through a user terminal.

[0049] The client application or software 105 may initially be provided to the computer device 102 of any given party 103 via a suitable computer-readable storage medium or medium, such as by downloading from a server, or by a removable storage device, such as a removable SSD, flash memory key, removable EEPROM, removable disk drive, magnetic floppy disk or tape, optical disc (such as CD or DVDROM), or removable optical drive, etc.

[0050] The client application 105 includes at least a "wallet" function. This has two main functions. One is to enable the relevant user party 103 to create, sign, and send transactions 152 to be disseminated throughout the node 104 network and thus included in the blockchain 150. The other function is to report back to the relevant party the amount of digital assets he or she currently owns. In an output-based system, this second function includes organizing the amounts defined in the outputs of various transactions 152 belonging to the relevant party and distributed throughout the blockchain 150.

[0051] An instance of client application 105 on each computer device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This enables the wallet function of client 105 to send transaction 152 to network 106. Client 105 is also able to contact one, several, or all of the storage nodes 104 to query blockchain 150 for any transaction for which party 103 is the recipient (or actually view transactions of other parties in blockchain 150, since in this embodiment blockchain 150 is a public facility that provides trust in partial transactions by virtue of public visibility). The wallet function on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify transaction 152 according to a node protocol, and in the case of forwarding nodes 104F, each node 104 forwards transaction 152 to propagate it throughout network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol together with a given node protocol implements a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150 (although the transaction protocol may allow different transaction subtypes to exist within it). All nodes 104 in network 106 use the same node protocol (although it can handle different transaction subtypes in different ways according to the rules defined for the transaction subtypes, and different nodes can assume different roles and thus implement different corresponding aspects of the protocol).

[0052] As mentioned, blockchain 150 includes a chain of blocks 151, where each block 151 comprises a set of one or more transactions 152 created by the proof-of-work process as described above. Each block 151 also includes block pointers 155 pointing back to previously created blocks 151 in the chain to define the order of blocks 151. Blockchain 150 also includes mining pools 154 waiting to be included in valid transactions in new blocks undergoing the proof-of-work process. Each transaction 152 (not the founding transaction) includes pointers back to previous transactions to define the order of the transaction sequence (note: the sequence of transactions 152 allows for branching). The chain of blocks 151 goes back to the founding block (Gb) 153, which is the first block in the chain. One or more original transactions 152 in the early stages of chain 150 point to the founding block 153, not to previous transactions.

[0053] When a given party 103, Alice, wishes to send a new transaction 152j to be included in blockchain 150, she (using the wallet functionality in her client application 105) formulates the new transaction according to the relevant transaction protocol. She then sends transaction 152j from client application 105 to one of the one or more forwarding nodes 104F she is connected to. For example, this might be the forwarding node 104F that is closest to or has the best connection to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes the new transaction according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets specific conditions for being "valid," examples of which will be discussed in more detail later. In some transaction protocols, the conditions used for verification can be configured on a per-transaction basis via a script included in transaction 152. Alternatively, the condition might simply be a built-in feature of the node protocol, or defined by a combination of the script and the node protocol.

[0054] If the newly received transaction 152j is deemed valid through testing (i.e., "verified"), any storage node 104S that receives transaction 152j will add the new verified transaction 152 to the mining pool 154 that maintains a copy of the blockchain 150 at that node 104S. Furthermore, any forwarding node 104F that receives transaction 152j will propagate the verified transaction 152 forward to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152j is valid, meaning it will quickly spread throughout the P2P network 106.

[0055] Once granted access to mining pool 154, which maintains copies of blockchain 150 at one or more storage nodes 104, miner nodes 104M will begin competing to solve a proof-of-work puzzle concerning the latest version of mining pool 154, including the new transaction 152 (other miners 104M may still be trying to solve the puzzle based on older versions of mining pool 154, but whoever succeeds first will define where the next new block 151 ends and where the new mining pool 154 begins, and eventually someone will solve the portion of mining pool 154 that includes Alice's transaction 152j). Once the proof-of-work for mining pool 154 including the new transaction 152j is completed, the new transaction becomes immutably part of block 151 in blockchain 150. Each transaction 152 includes pointers back to earlier transactions, thus the order of transactions is also immutably recorded.

[0056] UTXO-based model

[0057] Figure 2An example of a transaction protocol is shown. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following will describe a protocol based on output or "UTXO". However, all possible embodiments are not limited to this.

[0058] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure with one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been cashed). The UTXO specifies the amount of digital assets (store of value). Among other information, it may also contain the transaction ID of the transaction from which it originates. The transaction data structure may also include a header 201, which may include an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to miner 104M.

[0059] Note that, although Figure 2 Each output in the transaction is displayed as a UTXO, but a transaction may additionally or alternatively include one or more non-cost transaction outputs.

[0060] Suppose Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the sequence, Alice's new transaction 152j is marked as "TX1". This new transaction extracts a certain amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of them to Bob. The previous transaction 152i in Figure 2 The label is "TX0". TX0 and TX1 are just arbitrary labels. They do not necessarily mean that TX0 is the first transaction in blockchain 151, nor do they necessarily mean that TX1 is the immediately following transaction in mining pool 154. TX1 can point back to any previous (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0061] When Alice creates her new transaction TX1, or at least when she sends it to network 106, the previous transaction TX0 may have already been verified and included in blockchain 150. It may then be included in one of the blocks 151, or it may still be waiting in pool 154, in which case it will soon be included in the new block 151. Alternatively, TX0 and TX1 can be created and sent together to network 102, or TX0 may even be sent after TX1 if the node protocol allows buffering "orphan" transactions. The terms "previous" and "later" used in the context of transaction sequences refer to the order of transactions in the sequence defined by the specific transaction pointers within the transaction (which transaction points back to which other transaction, etc.). They can be equivalently replaced with "predecessor" and "successor," or "ancestor" and "descendant," "parent" and "child," etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to a previous transaction (ancestor transaction or "parent" transaction) will not be verified unless the parent transaction is verified. Child transactions that arrive at node 104 before their parent transaction are considered orphan transactions. Depending on the node protocol and / or miner behavior, such orphan transactions may be discarded or buffered for a period of time to wait for the parent transaction.

[0062] One or more outputs 203 of the previous transaction TX0 include a specific UTXO, denoted here as UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by that UTXO, and a locking script that defines the conditions that must be met by the unlocking script in the subsequent transaction's input 202 in order to verify the subsequent transaction and thereby successfully cash out the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction containing that amount). That is, the locking script defines the unlocking conditions, which typically include the following condition: the unlocking script in the subsequent transaction's input includes a cryptographic signature from the party who locked the previous transaction.

[0063] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language that can be recognized by the node protocol. A specific example of this language is called "Script" (capital S). The locking script specifies the information required to consume transaction output 203, such as requiring Alice's signature. The locking script appears in the output of each transaction. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it could contain Bob's signature. The unlocking script appears in the input 202 of each transaction.

[0064] Therefore, in the example shown, T X0The UTXO0 in output 203 includes the locking script [Checksig P] A This script requires Alice's signature (Sig P). A In order to cash out UTXO0 (strictly speaking, to make subsequent transactions attempting to cash out UTXO0 valid). [Checksig P] A The public key P contains Alice's public-private key pair. A T X1 Input 202 includes pointing back to T X1 pointers (e.g., via their transaction ID T) X ID0, in various embodiments, is the transaction ID of the entire transaction T. X0 (hash of T) X1 Input 202 includes the identification of T X0 The index of UTXO0 within T, to the index of T X0 It will be processed as its identifier in any other possible output. X1 Input 202 also includes an unlock script. <Sig P A This includes Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predefined portion of data (sometimes called a "message" in cryptography). Which data (or "message") Alice needs to sign to provide a valid signature can be defined by a locking script, a node protocol, or a combination of these.

[0065] When new transaction T X1 Upon reaching node 104, the node applies the node protocol. This includes running a locking script and an unlocking script together to verify that the unlocking script meets the conditions defined in the locking script (the conditions may include one or more criteria). In various embodiments, this involves cascading two scripts:

[0066] <Sig P A > <P A >||[Checksig P A ]

[0067] Here, "||" indicates cascading, "<...>" indicates placing data on the stack, and "[...]" unlocks functions contained in the script (in this example, a stack-based language). Equivalently, scripts can run one after another using a shared stack, without cascading. Either way, when run together, each script uses Alice's public key P. A (Included in the locking script in the TX0 output) to authenticate: T X1 The locking script in the input contains Alice's signature on the expected data portion. The expected data portion itself ("the message") also needs to be included in T.X0 This authentication is performed in China. In various embodiments, the signature data includes the entire T... X0 (Since it already exists, there is no need to include a separate element to explicitly specify the signature portion of the data.)

[0068] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice signs a message by encrypting it with her private key, a given Alice public key, and the plaintext message (the unencrypted message), another entity (e.g., node 104) can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and affixing it to the plaintext version of the message as a seal, allowing any public key holder to authenticate the signature.

[0069] If T X1 The unlock script in the middle satisfies T X0 One or more conditions specified in the locking script (as shown in the example, if Alice's signature is provided in T) X1 If it is certified in the middle, then node 104 considers T to be... X1 Valid. If the node is a mining node with 104M, this means that the node will time the transaction T. X1 Add it to transaction pool 154 that is waiting for proof of work. If the node is a forwarding node 104F, the node will pass transaction T. X1 Forward to one or more other nodes 104 in network 106 so that transaction T X1 The spread is pervasive across the network. Once T X1 It has been verified and included in Blockchain 150, which will come from T X0 UTXO0 is defined as already spent. Note that T X1 This only applies when a transaction that has been spent but not yet spent outputs a 203 error. If T X1 If an attempt is made to spend the output that has already been spent by another transaction 152, then even if all other conditions are met, T X1 This will also be invalid. Therefore, node 104 also needs to check the previous transaction T. X0 Whether the UTXO referenced in the transaction 152 has been spent (has constituted a valid input to another valid transaction) is a key factor. This is one reason why it is important for blockchain 150 to impose a prescribed order on each transaction 152. In practice, a given node 104 can maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it has constituted a valid input to another valid transaction in blockchain 150.

[0070] Note that in a UTXO-based transaction model, a given UTXO must be spent as a whole. It cannot "leave" a small portion of the amount defined in the UTXO while spending another portion. However, the amount from a UTXO can be distributed among multiple outputs of the next transaction. For example, T X0 The amount defined in UTXO0 in T can be used in T X1 This involves splitting the data across multiple UTXOs. Therefore, if Alice doesn't want to give Bob all the amounts defined in UTXO0, she can use the difference to allocate T... X1 The second output is used to give change to oneself or to pay another party.

[0071] In practice, Alice usually needs to pay fees for the winning miners because the rewards from the initiating transaction alone are often insufficient to incentivize mining. If Alice doesn't pay miner fees, then T... X0 It might be rejected by miner nodes at 104M, therefore, although technically valid, transaction T... X0 It will still not be propagated and included in blockchain 150 (the mining protocol does not force miner 104M to accept transaction 152 if the miners do not want it). In some protocols, mining fees do not need to have their own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by each input 202 and the total amount specified in each output 203 of a given transaction 152 is automatically provided to the winning miner 104. For example, suppose the pointer to UTXO0 is T X1 The only input, and T X1 There is only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference is automatically given to the winning miner 104M. However, alternatives or additional provisions do not necessarily exclude the possibility that the miner fee may be explicitly specified in one of the UTXOs 203 of transaction 152.

[0072] It should also be noted that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, then this is another reason for invalidity in most transaction models. Therefore, such a transaction will not be propagated or mined into block 151.

[0073] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere in blockchain 150. Therefore, typically, a given party 103's assets are dispersed across the UTXOs of various transactions 152 throughout blockchain 150. Nowhere in blockchain 150 is a number stored to define the total balance of a given party 103. The role of the wallet function in client application 105 is to consolidate the values ​​of all the various UTXOs locked to the corresponding party that have not yet been spent in another subsequent transaction. This can be done by querying a copy of blockchain 150 stored on any storage node 104S (e.g., the storage node 104S closest to or best connected to the corresponding party's computer device 102).

[0074] Note that script code is usually represented in a schematic way (i.e., not in the exact language). For example, it can be represented using [Checksig P] A [Checksig P] A ] = OP_DUP OP_HASH160<H(Pa)> OP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting opcode that accepts two inputs (signature and public key) and uses the Elliptic Curve Digital Signature Algorithm (ECDSA) to verify the validity of the signature. During runtime, any signatures ("sig") that appear are removed from the script, but additional requirements (such as hash puzzles) remain in the transaction verified by the "sig" input. As another example, OP_RETURN is an opcode in the scripting language used to create a non-spent output for a transaction that can store metadata within the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata could include files that you wish to store in the blockchain.

[0075] Signature P A This is a digital signature. In various embodiments, this is based on ECDSA using elliptic curve secp256k1. A digital signature signs a specific piece of data. In various embodiments, for a given transaction, the signature will sign a portion of the transaction inputs and all or part of the transaction outputs. The specific portion of each output to be signed is determined by the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select which outputs to sign (and is therefore determined at the time of signing).

[0076] A locking script, sometimes called a "scriptPubKey," refers to the fact that it includes the public key of the party locking the corresponding transaction. An unlocking script, sometimes called a "scriptSig," refers to the fact that it provides the corresponding signature. However, more generally, in all applications of Blockchain150, the requirement to authenticate a signature is not essential for redeeming a UTXO. More generally, scripting languages ​​can be used to define one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0077] Optional side channel

[0078] Figure 3 Another system 100 for implementing blockchain 150 is shown. System 100 is relative to... Figure 1 The described system is essentially the same, except for the additional communication functionality involved. Client applications on each of Alice's and Bob's computer devices 102a and 120b respectively include additional communication functionality. That is, (at the instigation of any party or third party) Alice 103a is able to establish a separate side channel 301 with Bob 103b. Side channel 301 enables data exchange independently of the P2P network. This communication is sometimes referred to as "off-chain." For example, this can be used to exchange transactions 152 between Alice and Bob without (not yet) publishing the transaction to network P2P 106 or entering blockchain 150, until one of the parties chooses to broadcast the transaction to network 106. Alternatively or additionally, side channel 301 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0079] Side channel 301 can be established through the same packet-switched network 101 as the P2P overlay network 106. Alternatively or additionally, side channel 301 can be established through different networks, such as mobile cellular networks, or local area networks such as local wireless networks, or even direct wired or wireless links between Alice and Bob's devices 1021, 102b. Generally, side channel 301 referred to anywhere herein can include any one or more links for exchanging data "off-chain" (i.e., independently of the P2P overlay network 106). When more than one link is used, the bundle or collection of off-chain links can be referred to as side channel 301. Therefore, note that if Alice and Bob exchange some information or data or something similar via side channel 301, it does not necessarily mean that all of these data must be sent via the exact same link or even the same type of network.

[0080] Node software

[0081] Figure 4 The illustration shows an example of node software 400 running on each node 104 of a P2P network 106, in either a UTXO-based or output-based model. Node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a set of one or more blockchain-related functional modules 405. At any given node 104, these modules may include any one, two, or all three of the following: a mining module 405M, a forwarding module 405F, and a storage module 405S (depending on the node's role). Protocol engine 401 is configured to identify different fields of transaction 152 and process them according to the node protocol. When a transaction 152m-1(Tx) is received, it indicates that the transaction is related to another previous transaction 152m-1(Tx). m-1 The output (e.g., UTXO) of the transaction's input is 152m (Tx). m When ), the protocol engine 401 identifies Tx m The unlock script is then passed to script engine 402. Protocol engine 401 also uses Tx... m Pointers in the input are used to identify and retrieve Tx m-1 If Tx m-1 If it is not yet on blockchain 150, then Tx can be retrieved from the corresponding node's own pending transactions in mining pool 154. m-1 , or if Tx m-1 If it's already on blockchain 150, then Tx can be retrieved from a copy of block 151 in blockchain 150 stored at the corresponding node or another node 104. m-1 Regardless of the method, the script engine returns a 401 error in Tx. m-1 The locked script is identified in the output pointed to by the pointer and passed to the script engine 402.

[0082] Script engine 402 therefore has the ability to retrieve Tx m-1 The locking script and from Tx m The corresponding input unlock script. For example, Figure 4 Tx1 and Tx2 are shown, but this also applies to any pair of transactions, such as Tx0 and Tx1, etc. Script engine 402 runs these two scripts as previously described, which will include placing data onto stack 403 and retrieving data from stack 403 according to the stack-based scripting language used (e.g., Script).

[0083] By running the scripts together, script engine 402 determines whether the unlock script meets one or more criteria defined in the locking script—that is, whether it "unlocks" the output containing the locking script. Script engine 402 returns this determination to protocol engine 401. If script engine 402 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns "true". Otherwise, it returns "false".

[0084] In the output-based model, a "true" result from script engine 402 is one of the conditions for transaction validity. Typically, one or more other protocol-level conditions evaluated by protocol engine 401 must also be met; for example, Tx m The total amount of digital assets specified in each output must not exceed the total amount pointed to by each input, and Tx m-1 The output pointed to by the pointer has not yet been spent by another valid transaction. Protocol engine 401 evaluates the result from script engine 402 along with one or more protocol-level conditions, and only when all of them are true will protocol engine 401 validate transaction Tx. m Protocol engine 401 outputs an indication of whether a transaction is valid to application-level decision engine 404. Only in Tx m If it is indeed effective, the decision engine 404 can choose to control one or both of the mining module 405M and the forwarding module 405F, thereby targeting Tx. m Execute their respective blockchain-related functions. This may include: the mining module 405M transferring Tx m Add to the corresponding mining pool 154 of the node to mine block 151, and / or forwarding module 405F will transfer Tx m The transaction is forwarded to another node 104 in the P2P network 106. However, note that in various embodiments, while the decision engine 404 will not choose to forward or mine invalid transactions, this does not necessarily mean that mining or forwarding valid transactions will be forced simply because a transaction is valid. Optionally, in various embodiments, the decision engine 404 may apply one or more additional conditions before triggering any one or both functions. For example, if the node is a mining node 104M, the decision engine may only choose to mine the transaction if it is both valid and leaves sufficient mining fees.

[0085] It's also important to note that while the terms "true" and "false" are certainly one possible implementation, they are not limited to returning a result represented by a single binary digit (bit). More generally, "true" can refer to any state indicating a successful or positive result, and "false" can refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model ( Figure 4In (not shown), the result "true" can be indicated by the combination of implicit, protocol-level verification of the signature performed by node 104 and the additional affirmative output of the smart contract (the overall result is considered true when both independent results are true).

[0086] Authentication Protocol

[0087] Two-factor authentication (2FA) via SMS text is an increasingly adopted protocol to enhance system and data security. Persistent breaches of private and public systems, along with increasingly stringent data regulations, mean companies are increasingly encouraging or compelling their customers to provide their phone numbers in order to protect customer data and services through 2FA protocols. By using a phone number, after providing initial factors (such as a password login), an SMS containing alphanumeric values ​​is sent to the customer's phone. The customer then enters this value into the system login; if correct, the customer is "authenticated" and gains access. The system's security rests on the premise that malicious actors are unlikely to know the customer's password and possess their phone number. However, vulnerabilities and flaws have been demonstrated in this system. One such vulnerability is known as "SIM swapping," where an attacker creates a fake ID using public information (such as name and address) and then uses that ID to impersonate the phone owner at a mobile operator's store. This could allow the attacker to obtain a new SIM card with the owner's phone number, enabling them to intercept SMS texts containing alphanumeric values.

[0088] The shortcomings outlined above are addressed by the proposed authentication mechanism described in this paper. The use of blockchain eliminates the need for a middleman in mobile phone operations, and the transparency of blockchain means that if, for any reason, a malicious actor does manage to steal a user's private key, transactions generated using the stolen private key are immutable on the blockchain and can serve as evidence in fraud cases.

[0089] Another known example of 2FA is a software-based authenticator that implements a two-step verification service, where the user (or malicious actor) needs access to the physical device running the authenticator application. While it has some advantages over SMS-based protocols, such authenticators also have drawbacks, such as their reliance on the availability of a centralized system and their vulnerability to phishing attacks. In contrast, authentication protocols use decentralized systems (blockchain networks), thus ensuring that the failure of any single node does not impair system availability.

[0090] As will be described below, embodiments of this disclosure provide an authentication protocol that enables a first party to use signed blockchain transactions as verification credentials, and enables a second and / or third party to use those signed blockchain transactions to verify the identity of the first party. These embodiments can be used as part of a multi-factor authentication protocol.

[0091] Figure 5 An example system 500 for implementing an authentication protocol is shown. The system includes a first party 501 and a second party 502. Figure 5 (Referring to "user" and "access party" in the text). The first party 501's operation includes a corresponding computer device with a client application configured to generate blockchain transaction 152 and transmit it to blockchain network 106, and to obtain blockchain transaction 152 (e.g., from blockchain 150). For example, the first party could act as Alice 103a, as referenced... Figures 1 to 3 Operate the wallet application 105a as described. Figure 5 In the example, the second party 502 also operates a corresponding computer device with a client application configured to generate blockchain transaction 152 and transmit it to blockchain network 106, and to obtain blockchain transaction 152 (e.g., from blockchain 150). In this case, the second party 502 can play the role of Bob 103b, as referenced... Figures 1 to 3 The wallet application 105b is operated as described. It should be understood that the first party 501 and the second party 502 can perform some or all of the actions of both Alice 103a and Bob 103b. That is, in principle, the first party 501 and the second party 502 can have the same blockchain-related capabilities, and the naming convention is for illustrative purposes only.

[0092] The second party 502 acts as an "access holder," meaning they control access to resources or services. For example, the second party 502 could control access to physical resources such as tangible products or digital resources such as digital tickets, ballots, tokens, etc. Examples of services include: online accounts, such as bank accounts, email accounts, online retail accounts, etc.; digital streaming services, and so on. The second party 502 could be a retailer, company, university, charity, etc. The first party 501 could be a customer, employee, student, donor, etc.

[0093] As an example, the second party 502 could be the owner of the property, and the first party 501 could be a vacationer who has paid the second party 502 for weekend access to the property.

[0094] First party 501 registers its public key with second party 502. As described above, those skilled in the art will be familiar with public keys (and public-private key pairs). For example, first party 501 may register its public key during its first interaction with second party 502, for example, as part of a KYC protocol or account setup.

[0095] like Figure 5 As shown, the first party 501 provides one or more first credentials (1-FA) to the second party 502. For example, the first credentials could be a username, password, credit card, name, address, driver's license, passport, easy-to-remember words, key card, etc. This can be achieved via wired or wireless connection 503 (e.g., see reference 502). Figure 3 The described side channel 301) provides the first credential to the second party 502. For example, the first party may transmit the first credential to the second party via email, SMS text, Wi-Fi, Bluetooth, NFC, etc. The first credential may be provided in response to an inquiry (or request) from the second party 502, such as as part of an online purchase or account login. Alternatively, the first party 501 may provide the first credential to the second party 502 without receiving a direct request. For example, continuing with the example of the first party 501 being a vacationer, the first party 501 may present a key card or code (the first credential) at the entrance of a property.

[0096] In response to receiving the first credential, the second party generates a 502 request transaction Tx. rt And prompt the requesting transaction Tx rt Transmitted to blockchain network 106, for example, the second party 502 will request transaction Tx rt The request transaction Tx is transmitted to one or more nodes in network 106 or to different entities that subsequently transmit the request transaction to network 106. rt It must include at least the first input and the first output. Request transaction Tx rt Additional inputs and / or outputs may be included. The first input includes the signature of the second party 502. That is, the second party 502 signs the transaction using a signature generated using the second party 502's private key, which may correspond to a public key of the first party 501 or a generally known public key. The first output is locked to the public key registered by the first party 501, such that a signature generated using the private key corresponding to the public key registered by the first party 501 is required to unlock and thereby cash out or spend it.

[0097] The output can be a P2PKH output that includes the hash of the registered public key (public key hash). To spend a P2PKH output, the input to the spending transaction must contain a public key such that its hash (e.g., OP_HASH160) matches the public key hash in the P2PKH output. In other words, the P2PKH output requires the spender to provide two items: a public key whose hash matches the address in the P2PKH output; and a signature valid for both the public key and the transaction message (this order is not required).

[0098] The first party 501 can obtain the requested transaction Tx from the second party 502. rt However, preferably, the first party finds the requesting transaction Tx by scanning the memory mining pool of blockchain 150 or blockchain network 106. rt Once a transaction has been executed over the network, it is transmitted and stored in a so-called memory mining pool (RAM pool) until a mining node includes it in the next block 151. Each node on network 106 operates its own memory mining pool. Request transaction Tx rt UTXOs that can be paid to a public key or public key address can be obtained by scanning a blockchain or a memory mining pool. In other words, the wallet application of the first party scans the blockchain or memory mining pool to find transactions that can be paid to its registered public key or the hash of that registered public key.

[0099] In obtaining the requested transaction Tx rt At that time, the first party 501 generates a confirmation transaction Tx. ct Confirm transaction Tx ct It will cost the request transaction Tx rt The output of . That is, it references the request transaction Tx locked by the registered public key of the first party 501. rt The output of the request transaction Tx. rt The output confirms transaction Tx. ct The input includes a signature generated using the private key corresponding to the registered public key. Based on the request transaction Tx rt The output type can be specified, and the input can also include the registered public key. This will be the case if the output is a P2PKH output. Confirm transaction Tx ct This includes outputs that can be locked to a second party 502, a first party 501, or different parties. Preferably, the output is locked to the second party 502 so that the second party (i.e., the second party's wallet application) can scan the blockchain or mempool to find the UTXO of the public key (or its hash) that can be paid to the second party 502.

[0100] In response to receiving confirmation of transaction Tx ctWith any optional additional verification steps, the second party 502 grants the first party 501 access to resources or services.

[0101] Therefore, confirm transaction Tx ct The presence of blockchain 150 or in-memory mining pools serves as an additional credential or authentication factor for verifying the identity of the first party 501.

[0102] Figure 6 Another example system 600 for implementing an identity authentication protocol is shown. Figure 6 The system involves a third party (referred to as the "trusted third party") 601. In this example, the second party (access party) 502 retains control over access to resources or services, but the task of registering the public key and generating request transactions for the first party 501 is delegated to the third party 601. The third party 601 can be a certificate authority, such as a party entrusted with verifying public keys. For example, the third party can perform rigorous initial identity verification on an individual to bind that individual to their public key. As an example, the third party 601 can hold a face-to-face meeting with the first party 501 to verify that they match official documents such as a passport or driver's license.

[0103] In this example, the second party 502 may or may not operate the computer device configured to access the blockchain network, while the third party 601 does operate the corresponding computer device 106, which includes a client application configured to generate blockchain transactions 152 and transmit them to the blockchain network 106, as well as to obtain blockchain transactions 152 (e.g., from blockchain 150). Effectively, the third party 601 can perform reference... Figures 1 to 3 Some or all of the actions described and attributed to Alice 103a or Bob 103b.

[0104] Note that in Figure 5 In the example below, the actions belonging to the third party 601 can be performed by the second party 502, meaning that in this example, the second party 502 and the third party 601 are the same party.

[0105] First party 501, for example, responds to a request for a first credential and provides one or more of the first credentials to second party 502. Second party 501 sends a request (2FA-request) to third party 601 to verify the identity of a user claiming to be first party 501. The 2FA-request can be transmitted via side channel 504 (e.g., the Internet) or using blockchain transaction 152.

[0106] The third party, 601, generates a request transaction Tx.rt As described above, the request transaction includes the output of the public key locked to the first party's 501 registration. Figure 5 The difference between this example and the previous one lies in the request transaction Tx. rt The input includes a signature generated by the third party 601. However, it is not excluded that the request transaction may include signatures from both the second party 502 and the third party 601. The third party 601 will request transaction Tx. rt Transmitted to blockchain network 106.

[0107] The first party 501 obtains the requested transaction Tx, for example, by scanning Blockchain 150 or a memcrypt pool. rt Generate and confirm transaction Tx ct and confirm the transaction Tx ct Transmitted to blockchain network 106.

[0108] The third party 601 determines the confirmation transaction Tx, for example, by scanning the blockchain 150 or by scanning the memory mining pools of one or more nodes in network 106. ct Has it ever been transmitted to blockchain network 106? If the confirmed transaction Tx ct If the information is already recorded in the blockchain or exists in one or more corresponding memory mining pools, the third party sends an indication to the second party 502 to notify the second party that the identity of the first party has been verified. For example, the third party 601 can transmit the indication via side channel 504, or transmit a blockchain transaction 152 containing the indication to the second party 502. In some examples, only when transaction Tx is confirmed... ct (and the corresponding request transaction Tx) rt The third party 601 will only transmit the instruction once it has been recorded in blockchain 150.

[0109] In response to receiving the instruction, the second party 502 grants the first party 501 access to the resources or services.

[0110] Figure 7 An exemplary sequence diagram for verifying the identity of the first party 501 is shown. Figure 7 This illustrates how a first party can include two distinct users: "User A" 701a operating the corresponding wallet application 702a (though not required) and "User B" 701b operating the corresponding wallet application 702b. In the case where the first party 501 comprises a single user, User A 701a and User B 701b are the same user.

[0111] User A 701a provides one or more credentials to the access party 502. The access party transmits a request to the trusted third party 601 to verify user A's identity. The trusted third party 601 transmits a request transaction Tx to the blockchain 150 that holds user B's public key. rt User B's wallet application 702b receives a request for transaction Tx from blockchain 150. rt The request is then communicated to user B (701a) in order to provide a second credential. User B uses wallet application (702b) to generate a confirmation transaction (Tx). ct And the wallet application 702b will confirm the transaction Tx ct Transmitted to blockchain 150. Trusted third party 601 obtains confirmation of transaction Tx from blockchain 150. ct The access party 502 is then instructed to verify the identity of the first party. Access party 502 grants user A 701a access to the resource or service. In this example, user B 701b verifies the identity of user A 701a. For instance, user A might be a child wishing to purchase goods from a merchant or access streaming service content, while user B could be a parent who can first decide whether access to purchase or access is appropriate and then verify the child's identity. However, preferably, user A is user B, and user A is providing confirmation to verify their own identity.

[0112] As an optional feature, the output of a request transaction locked to the public key of the first party can be additionally locked to the public key of the party that generated the request transaction, namely the second party 502 or the third party 601. In this case, the output is a multisignature output. A multisignature (also called a multi-signature) output challenges the input of a spending transaction to include a signature that corresponds to an m-to-n public key in the multisignature output. Therefore, in these examples, the output can be unlocked (i.e., spent) by the first party 501. The output can alternatively be unlocked by the second party 502 or the third party 601 (depending on which party generated the request transaction). For example, if the second party 502 generated the request transaction, the output might be a 2-to-1 multisignature output that can be unlocked independently by either the first party 501 or the second party 502. Note that once the output is unlocked (i.e. spent) by one of the parties, the other party cannot unlock it (i.e., double-spend). When the first party 501 unlocks the multisignature output, the cost transaction is a confirmation transaction. When the second party 502 or the third party 601 unlocks the multisignature output, the cost transaction is a cancellation transaction. For example, if a period of time has elapsed since the request transaction was committed to network 106, the cancellation transaction allows the second party 502 or the third party 601 to remove the request transaction from the UTXO set.

[0113] As another optional feature, and to enhance the privacy of the first party 502, the first party 502 can register a first public key with the second party 502 or the third party 601, and the second or third party can lock the output of the requested transaction to a second public key generated based on the first public key. The second public key is generated in a predetermined manner known to both the first party 501 and the second or third party 502, 601. This allows the first party 501 to scan the blockchain 150 or a mem-pool to find the second public key or its hash to obtain the requested transaction. For example, the first party 501 can generate a pseudo-random number and share it with the second party 502 or the third party 601, and vice versa. The pseudo-random number can be combined with the first public key to generate the second public key. Depending on the public key scheme used, the pseudo-random number may first have to be multiplied by the generation point, for example, if an ECDSA scheme is used. The pseudo-random number can be shared among the parties using a Diffie-Hellman exchange or a variant thereof. If the first party 501 subsequently interacts with the second party 502, for example, to gain access to another resource or service, then the second or third party may apply the same pseudo-random number to the second public key to generate a third public key and lock the output of subsequent request transactions to that third public key.

[0114] Another optional feature is in requesting transaction Tx rt The output uses a challenge. This challenge will confirm the transaction Tx. ct The input is required to include the scheduled response. Note that this query is for confirming transaction Tx. ct The input includes supplementary requirements for the signature of the first party, 501.

[0115] First, the first party 501 may transmit a message to the second party 502, or the second party 502 may transmit a message to the first party 501. In some examples, the first party 501 and the second party 502 may jointly generate the message by exchanging information. This message may include details of the authentication request, such as information about the resource or service that the first party 501 is attempting to access, time and / or date information, etc. Typically, the message can contain information of any form. In some examples, the message includes a pseudo-random number used to generate a second public key. The message may be sent in encrypted form, in which case the first party 501 and the second party 502 must know or share a decryption key. Methods for sharing decryption keys are well known to those skilled in the art. One such method is the Diffie-Hellman exchange.

[0116] The first party, 501, obtained the request transaction Tx rt After that, the request transaction Tx can be determined. rtIs the message in its original form (i.e., as plaintext) or in its encrypted form (e.g., as ciphertext)? Alternatively, the first party 501 can determine the requesting transaction Tx. rt Whether to include the hash (or more) of the message in its raw or encrypted form. Multiple hashing is the result of applying a hash function two or more times to a message. Note that a particular hash function itself may hash the message multiple times. Typically, multiple hashing by applying, for example, a double hash function can include: applying a first hash function once or more, followed by applying a second hash function once or more, where the first and second hash functions can be the same or different hash functions. Furthermore, the hash function may be applied one or more times to the first and / or second hash functions themselves. The notation H is used below. 2 (X) refers to applying a double hash function to message X, where H 2 (X)=H A (H B (X)), and where H A and H B These can be the same or different hash (or more) functions. For example, the hash function H160 itself uses two different hash functions, RIPEMD160 and SHA256, i.e., hash160(X) = RIPEMD160(SHA256(X)).

[0117] If request transaction Tx rt If the expected message or the expected hash of the message (which may be a multi-hash) is included, then the first party can generate only a confirmation transaction Tx using 501. ct Preferably, if the requesting transaction Tx rt Including the double hash of the message, the first party (501) can generate only the confirmation transaction Tx. ct In the third party 601, a request transaction Tx is generated. rt In such cases, the second party 502 and the third party 601 share a message or a (multiple) hash of the message.

[0118] Request transaction Tx rt The output may include the expected message or the expected hash of the message (possibly a multi-hash). Preferably, the output includes a request to know the message in order to confirm transaction Tx. ct The input to a transaction is a challenge to unlock the output. For example, the output could include a hash puzzle. A hash puzzle takes an input value, applies a hash function to that input value, and compares it to a predetermined hash. If the hash of the input value matches the predetermined hash, the output is a value such as 1 or "true". Including a hash puzzle in the output of a transaction requires that the input to the transaction include an exact input value (or preimage) that can be hashed to obtain the predetermined hash.

[0119] For example, if requesting transaction Tx rt If the output includes the message hash, then confirmation of transaction Tx is required. ct The input includes the message itself. If the request is for transaction Tx... rt If the output includes a double hash of the message, then confirmation of transaction Tx is required. ct The input contains the hash of the message. Typically, confirmation of transaction Tx is required. ct The input includes the request transaction Tx rt The preimage of the (multiple) hash contained in the output.

[0120] The following example illustrates the use of an authentication protocol in a two-factor authentication system. In this example, a user is purchasing goods (hereinafter referred to as a "sales transaction") and is expected to sign a blockchain transaction to indicate their permission to conduct credit card transactions. After such a signed transaction is generated, the credit card company and / or business is expected to proceed to complete the sale. The sale requires a FIAT currency payment card, and the first credential (or factor) is the payment card (credit or debit card) itself (or at least the associated number).

[0121] Preferably, several key aspects must be considered when implementing an MFA system. Efforts must be made to prevent malicious actors from disrupting the system and causing undesirable consequences. Many individuals, except in most cases, prefer not to disclose details of their financial transactions. It is desirable to complete the 2FA process as quickly as possible. If disagreements ultimately exist among the parties involved, a degree of transparency may be required for auditing purposes.

[0122] A single design based on the 2FAB scheme may not be able to fully satisfy each of the above criteria simultaneously. Therefore, after proposing the basic design, additional designs are proposed to address the above considerations.

[0123] The following examples use the following acronyms. PF1 701a (e.g., First Party 501) is an individual seeking payment for goods or services. This includes someone bringing a basket of goods to the checkout in a store, or someone making an online purchase from an internet-enabled device. WF1 702a is PF1's blockchain wallet. This wallet is responsible for accessing and submitting transactions to blockchain 150 on behalf of PF1. WF1 is also able to calculate hashes of strings / texts, and store and record these hashes and associated text. Enterprise 703 (e.g., Second Party 502) is the company from which PF1 will pay for the goods and services. Bank 704 (e.g., Third Party 601) represents the institution that issues, regulates, and manages the use of credit / debit cards. PF2 701b is the individual responsible for signing and confirming the transaction, representing the Second Party. PF2 can be the same person as PF1. In fact, ideally, the same individual should be responsible for verifying both the First and Second Party. However, PF1 and PF2 are not always the same individual. For this reason, PF1 and PF2 represent their respective identities throughout WP, allowing for situations where they are not the same person. WF2 702b is PF2's blockchain wallet. This wallet is responsible for accessing the blockchain and submitting transactions on behalf of PF2. WF2 is also able to observe any 2FA requests from banks on the blockchain and then relay these requests to PF2.

[0124] To facilitate the design of the 2FA system, the following assumptions are made. First, when a credit card is granted by a credit card company or bank 704, the individual registers a public key (e.g., an ECDSA public key). This public key is associated with the individual's bank account. If the user or bank requires it for security or other reasons, the user can register a new public key with the bank (replacing the previous one). The second assumption is that when bank 704 grants the credit card, the individual and the bank reach a consensus on a secret value S. If encryption of sales transaction data on the blockchain is required / requested, bank 704 may use this secret value S. This secret value S can be securely generated and exchanged between the credit card holder and bank 704 using the Diffie Helman protocol and is associated with the cardholder's account. If the user or bank 704 believes that the previous S has been compromised for security or other reasons, the user can re-engage with bank 704 and generate a new secret value S (replacing the previous one).

[0125] Figure 8An exemplary sequence diagram of a 2FA system is shown. The first three steps (from top to bottom) represent the interaction between PF1 and Enterprise 703 when an individual decides to purchase a basket of goods and services. Here, PF1 has identified the required items and presents this list to Enterprise 703 in the form of a formal purchase order or other form. Enterprise 703 constructs an invoice or bill to communicate with PF1 (the invoice is expected to include the enterprise's identification information). If PF1 is satisfied with the details of the invoice, PF1 provides Enterprise 703 with its necessary credit card details. Note that the purchase order, invoice, and credit card do not necessarily have to be handed to each other in person; this can be communicated using electronic devices such as card readers, cash registers, or mobile phones. After Enterprise 703 obtains the credit card information, the cashier constructs a message, such as a formal "Sales Transaction Digital Representation" (STDR). This can be a combination of the invoice and PF1's credit card information. Enterprise 703 generates a summary (i.e., hash) of transaction H (STDR) and communicates it to PF1. PF1 is required to have a computing device capable of verifying the correctness of the H (STDR) value, such as a smartphone. This function can be performed by WF1 available on smartphones. Assuming H(STDR) has been correctly calculated, the wallet will retain a record of this hash and the STDR itself in anticipation of the next stage of the 2FA request.

[0126] Assuming PF1 confirms the H (STDR) value, enterprise 703 can continue processing the user's credit card. Enterprise 703 then transmits the STDR information to PF1's bank 704.

[0127] The bank uses a 704 verification function to check this information (such as company identifier, credit card information, STDR format, etc.) and retrieves the public key (P key) currently registered for that credit card. CC =v CC G), where v CC G is the private key, and G is the generation point. Following the verification, bank 704 uses a hash function such as H(·) = SHA256 to generate the double hash H of the STDR. 2 (SDTR), and create a "2FA request transaction" (Tx) to be submitted to the blockchain. rt The output of the transaction (labeled output-2FA for illustrative purposes) uses double hashing to "lock". The "2FA request transaction" Tx rt This is a bank's 704 formal request for a second certification factor in relation to a sales transaction. The "requested" second factor is determined by P. CC The generated digital signature (ECDSA) is used to sign blockchain transactions. This digital signature must appear in the input script of the spending transaction that uses the aforementioned output (output-2FA) in order to spend it. The following table provides Tx rt Example:

[0128]

[0129] For Tx rt The input for this transaction was made by bank 704 using public key P. Bank =v bank G signs the transaction, and the public key is expected to be known and trusted by all stakeholders of the proposed system. The transaction has two outputs—the first is output-2FA, and the second is a non-spendable (e.g., OP_RETURN) output. The non-spendable output is used to store metadata related to the transaction. Besides the OP_RETURN output, there are other ways to store metadata in a transaction. The OP_RETURN output shows examples of metadata that can be included in a transaction. These are described in the table below.

[0130]

[0131] For output-2FA, it is protected by the locking script copied below.

[0132]

[0133] The first part of the locking script requests H 2 The preimage of (SDTR), which will soon become H(STDR), the latter part of which requests the ECDSA signature Sig(P) associated with the public key registered to the credit card. CC Suppose there exists a scenario where PF2 is unaware of the 2FA request or unwilling to acknowledge the transaction (e.g., because they haven't recalled and approved the sales transaction), requesting transaction Tx rt The following changes can be made. One approach is to allow banks to have 704 transactions that have been spent (Tx). rt The output-2FA option. After a period of time, for example, based on the bank's judgment, if PF2 has not spent the output-2FA (i.e., provided a second authentication factor), then bank 704 can "return" the output-2FA to itself. This will adjust the output-2FA locking script to allow bank 704 or PF2 to unlock the output.

[0134]

[0135] As shown in the script above, this can be achieved by including an m-choose-n multisignature condition that requests signatures for two public keys P. Bank or P CCThe signature of any of the signatures. Here, the locking script begins with the required number of valid signatures (m), then lists the set of n public keys that the m signatures must correspond to, followed by the value n, and the opcode OP_CHECKMULTISIG used to check if all m signatures are valid. Thus, Bank 704 can spend output-2FA if necessary. In transaction Tx rt After its creation, it was subsequently submitted to the blockchain by Bank 704.

[0136] When Tx rt When successfully mined (i.e., block 151 is included in blockchain 150), PF2's continuous scanning of the blockchain (UTXO) to find the wallet (WF2) that made the 2FA request will eventually notice the existence of the transaction on blockchain 150 and alert PF2 to the request. Wallet WF2 will always specifically look for transactions containing blocks starting with P... CC For target (optional, with <2FAB-ID>) <txrt-id>The output of the transaction is output-2FA (target).

[0137] Assuming PF2 is PF1 (in the case of a dual-wallet, WF2 would be WF1), this wallet can verify whether the stored H (STDR) received from the initial contact point between PF1 and Enterprise 703 matches the decrypted version of STDR in the OP_RETURN output and the H in output-2FA. 2 (STDR) corresponds to this. If these values ​​match (or do not match) and PF2 wants to conduct a sales transaction, then PF2 selects that option in wallet WF2.

[0138] According to the instructions of PF2, WF2 creates transaction Tx. ct This transaction is a 2FA confirmation transaction. It is a formal confirmation from PF2 that the bank has completed the sales transaction (704).

[0139]

[0140] Tx ct The input to a transaction is Tx. rt The output is output-2FA. Therefore, the unlocking script for output-2FA will be:

[0141] <Sig(P CC )><P CC ><H(STDR)>]]>

[0142] Alternatively, if banks are allowed to cancel Tx using 704... rt :

[0143] 0 < sigP CC > <H(STDR)>

[0144] PF2 must contain the private key v. CC The transaction signature is required from PF2. Additionally, PF2 must provide H(STDR). Including this hash value is one way PF2 determines that it is responding to the exact sales transaction it should be responding to. Note that if any character in the STDR changes, it will produce a completely different hash value.

[0145] The transaction may include at least one output that returns the y-value to bank 704. A second OP_RETURN output can be used to store the required metadata. The metadata may include <2FAB-ID> to indicate that the transaction is a 2FAB transaction, and include... <txct-id>To indicate that this transaction is specifically a 2FAB confirmation transaction. This transaction will be committed to the blockchain.

[0146] When Tx rt is successfully mined, bank 704 (whose wallet software continuously scans the blockchain 150 for Tx ct ) will eventually notice the existence of Tx ct on the blockchain 150. Bank 704 will specifically look for transactions containing an output targeted at the bank's public key P Bank (optionally tagged with <2FAB-ID <2FA-ct-ID>). If it finds such a transaction, it will accept the transaction as valid and will proceed to process it.

[0147] Bank 704 undertakes any other non-2FA verification processes it needs to do, adjusts the user's credit card balance accordingly, and then sends a signed authorization to business 703 that the sale transaction has been approved by bank 704. The authorization can be in the form of a blockchain transaction. Business 703 then provides the goods or services to the user.

[0148] In the example of Figure 8 there is a delay associated with the time it takes to confirm a transaction on the blockchain 150. For a proof-of-work blockchain, the average time to mine (i.e. include in the blockchain 150) a transaction is ten minutes. The combination of the request transaction Tx rt and the confirmation transaction Tx ct that is being mined means that: from the initial interaction where PF1 formulates the sale details, it takes approximately 20 minutes for the customer to be entitled to the goods or services. This can be impractical in some situations.

[0149] The nodes of the blockchain network 106 store the unconfirmed transactions they receive in a database known as the unconfirmed transaction mempool (often simply referred to as the mempool). Not all received transactions are added to the mempool. If a transaction double spends an input that already exists in another transaction in the mempool, it is discarded. If a transaction is not a standard transaction, it is also discarded. Once a node receives a new block, either by being relayed to it by another node or by mining it itself, the unconfirmed transaction mempool is updated to remove all transactions included in the block. When a transaction is created, it is relayed through a small number of nodes to the blockchain network 106. The nodes that receive the new transaction check that it is valid and not a double spend of an already existing transaction in the mempool. If the transaction passes the checks, it is relayed to other nodes in the network, otherwise it is discarded. The mempool essentially acts as a temporary store for transactions waiting to be confirmed in the blockchain. It is maintained by the nodes of the blockchain network 106 that are used to check the validity of transactions, including formatting and double spending. Each node keeps a copy of the mempool, passes new valid transactions to other nodes, and accepts valid transactions from other nodes into its version of the mempool.

[0150] In view of this verification process being performed by each node on the transactions in their respective mempool, a transaction existing in multiple mempools is considered to be an imperfect but sufficiently legitimate transaction. The legitimacy of transactions in the mempool is particularly applicable to proof-of-work blockchains, where the first (valid) transaction broadcast is to include the transaction in the next block. In view of the very fast - almost instantaneous - uploading, verifying and broadcasting of transactions across nodes, if the intended recipient of a payment is willing to accept a valid transaction in the mempool (albeit not mined) with a sufficient level of credit, this greatly reduces the time between the sending of the transaction from the payer and the transaction being "seen and accepted" by the recipient. The mempool not only stores valid transactions that spend the UTXO of a mined transaction, but it also stores and accepts as valid transactions that spend the output of a transaction that already exists in the mempool but has not yet been mined. This enables the creation of a chain of transactions in the mempool, where each transaction spends the output of a previous transaction, and only the first transaction is a transaction that spends the output of a mined transaction. Currently, this chain can be up to 25 transactions long.

[0151] Figure 9 A sequence diagram showing a modified 2FA protocol utilising the mempool is shown. In this example, WF2 scans the mempool 901 (and the blockchain 150) and alerts PF2 when a confirmation request for PF2 appears. If PF2 is willing to provide a second authentication factor, then PF2 signs a confirmation transaction Tx ct spending the transaction Tx ct in the mempool. The transaction Tx rt The output is output-2FA. PF2 commits the transaction to the in-memory pool. The bank's wallet software scans the in-memory pool for such 2FA-confirmed transactions; if it's a sales transaction, the confirmation transaction Tx is executed. ct If the memory mining pool does exist, then bank 704 notifies enterprise 703 to continue the sales transaction.

[0152] Figure 10 The chain of unconfirmed transactions in memory mining pool 901 is shown. Figure 11 This illustrates a double-spending attempt on a request transaction in memory mining pool 901. The primary concern is the threat of double-spending in accepting transactions as valid (for the MFA protocol or in general) within memory mining pools. Double-spending occurs when a transaction, such as "TransDS," is double-spent with a transaction such as Tx. ct Another transaction consumes the same output, causing Tx ct It is considered "invalid" and removed from the node's memory pool 901, never to be mined or included in a block. However, in practice, it has been proven that implementing double-spending is difficult or impractical. That being said, even if a double-spending were successful, it would not trouble the MFA protocol. The second factor required for a sales transaction is the use of v CC Signed Tx ct If a bank 704 error is seen in the memory mining pool, it indicates the use of v. CC Signature transactions Tx ct Even if the transaction is never confirmed to a block (due to double-spending or other reasons), PF2 has already signed the transaction Tx. ct It remains true. This serves as sufficient confirmation of the second factor. In this understanding, memory mining pool 901 will act as the communication medium for requesting and confirming transactions, such as... Figure 12 As shown. For convenience, in the event of a double-spending transaction and the transaction is never mined, Mining Bank 704 can save the transaction value (Tx) in its records. ct A copy. This can be used for auditing or disputes. However, in most cases, Tx will not be able to process the request within approximately ten minutes of each submission. rt and Tx ct It will be mined into the blockchain.

[0153] Some parties (such as customers and businesses) may require or desire a certain degree of privacy when conducting sales transactions. In the implementations described above, certain measures are taken to protect customer privacy; for example, details of the sales transaction (STDR) do not necessarily need to be included in the transaction, but can be provided using a hashed and / or encrypted version of the sales transaction (STDR). Given that Blockchain 150 is public and immutable, these measures are desirable. The locking script for output-2FA can be configured by requiring the hash H (STDR) to appear in the spending transaction (Tx). ct The input script contains a double hash (H) 2 (STDR). If a malicious actor can determine the original STDR, then if the STDRs are identical, the malicious actor will be able to identify all other sales transactions represented on Blockchain 150. To prevent this, it is prudent to make each STDR unique. In some examples, the STDR consists of one or more of the following: a fee list (details about the purchased goods), credit card details, and a business ID (information used to identify the business, such as name, address, registration number, etc.).

[0154] If a customer repeatedly purchases the same item from the same store using the same credit card, there is a risk of the STDR being identical each time. To distinguish each sales transaction, the STDR can contain some unique data. In some cases, the expense list for the sales transaction will include a unique identifier, often called an "expense list number." This addresses, but only partially, the need for a unique STDR. If the number simply increments by a fixed value each time a new sales transaction is created, then interested parties can easily computationally identify each new sales transaction that "purchases the same item from the same business using the same card." This would be ideal if the number is a random number chosen from a sufficiently large set, with a low probability of repetition. The datetime value of the transaction can also be used as a way to generate a unique STDR hash. However, this faces the same challenge that the datetime increments in a predictable manner. For this reason, if someone knows at least one STDR, then that person can iterate over the datetime and calculate and identify the hash of the sales transaction that "purchases the same item from the same business using the same card." A random number (2FAB_Rand) as the ID of the sales transaction is the preferred option. As mentioned earlier, it can be a random number created by Enterprise 703 or generated by Individual PF1. Alternatively, it can be a random number jointly generated from inputs from the initial interaction between Enterprise 703 and PF1. The generation and verification process of 2FAB_Rand can be incorporated into the interaction between PF1 and Enterprise 703, such as... Figure 9 As shown.

[0155] Consider PF1 and the random value of the firm as k PF1 and k Bus ,in

[0156] 0 <k PF1 ,k Bus

[0157] Where q is a large prime number.

[0158] Therefore, the value 2FAB_Rand could be:​

[0159] 2FAB_Rand=(k PF1 +k Bus )modq

[0160] Revised STDR (STDR) R The value will now be changed to:

[0161] STDR R =STDR||2FAB_Sand

[0162] In this context, || represents cascading.

[0163] The 2FAB_Rand value is expected to be stored in the PF1 wallet. In some cases, the 2FAB_Rand value can be included as metadata in, for example, a 2FAB-rt transaction encrypted with the value S.

[0164] Besides concerns about the uniqueness of STDR, there are also concerns about P CC The uniqueness of the public key. Recall that when a credit card holder was granted a credit card, they registered their public key P with the bank using 704. CC If every 2FA transaction sends the same value P CC So, even if an interested (potentially malicious) party doesn't know exactly what was purchased, if they can obtain information about P... CC By deanonymizing the cardholder, every purchase made by PF1 can be easily tracked. This is because PF1 communicates with the bank's 704 account and registers a new PF before each sales transaction. CC The value is impractical; we can explore utilizing the uniqueness of P. CC Other options for the value. For example, the 2FAB_Rand value described earlier can be used to generate a new public key. Assume all parties agree on the elliptic curve and a set of parameters (e.g., the secp256k1 elliptic curve), which includes:

[0165] • The base point on the Gq-order elliptic curve: q × G = 0; and

[0166] ·q-large prime number, then P CC The public key can be revised as follows:

[0167]

[0168] For request transaction Tx rt The output-2FA is revised to address the public key P. CC Customers PF1 / PF2 are responsible for retaining knowledge of 2FAB_Rand so that this value can be compared with v. CC Pairing to create a transaction Tx that will be successfully committed and confirmed. ct Required signature. Enterprise 703 is responsible for transmitting the value 2FAB_RandG to Bank 704.

[0169] This disclosure describes an authentication protocol (e.g., an MFA protocol) that uses blockchain transactions as a second authentication factor. A request for the second authentication factor is indicated in a blockchain transaction, and confirmation of knowledge of the second authentication factor is expected to be accomplished by the intended recipient submitting a confirmation transaction that consumes the output of the requesting transaction.

[0170] The use of blockchain introduces its own complexities, primarily the lengthy (approximately 10 minutes) wait time for transactions to be confirmed and added to a block. The protocol addresses this by allowing unconfirmed transactions in the in-memory pool to be considered legitimate for its purposes. This applies to both requesting transactions and confirming transactions that consume the output of unconfirmed requesting transactions. This acceptance of unconfirmed transactions makes the authentication process almost instantaneous. Importantly, in this scenario, the blockchain acts as the communication medium for the conversion between request and confirmation, given that it is almost certain that both transactions will eventually be confirmed on the blockchain.

[0171] Another concern with using blockchain is privacy. Customers may be reluctant to allow third parties to identify their purchases. The MFA protocol mitigates these concerns by including the use of a random number generated for each unique event (sales transaction). This unique random value is used to spoof the public key being sent the 2FA request, as well as a representation to spoof the details of the event.

[0172] Beyond mitigating the inherent limitations of Blockchain 150, the MFA protocol offers advantages over existing solutions. The fact that Blockchain 150 is a decentralized system means it doesn't rely on availability for a single point of failure. Furthermore, the transparency and immutability of Blockchain 150 mean there will be evidence of 2FA requests and sent confirmations. In any investigation related to MFA confirmation or lack thereof, audits involving regulators, governments, or legal entities can easily be aided; banks cannot deny sending the request transaction, and PF2 / PF1 cannot deny signing the confirmation transaction. Malicious actors cannot secretly provide 2FA confirmations without the knowledge of PF2 / PF1. This would be readily apparent if a bank or enterprise processed a sales transaction without a confirmation transaction signed by PF1 / PF2.

[0173] Although the agreement has been described in the context of sales transactions using fiat currency, it can be applied to manage other "transactions" that require MFA certification, such as secure access to folders or physical buildings.

[0174] In this consideration:

[0175] - Sales transactions are replaced by generic events;

[0176] -Businesses are now described as gatekeepers or access holders; and

[0177] - Banks are now described as trusted third parties to certificate authorities and are considered any entity or system responsible for registering PF1 public keys, etc.

[0178] in conclusion

[0179] It should be understood that the above embodiments are described by way of example only. More generally, methods, apparatus, or procedures according to any one or more of the following statements may be provided.

[0180] Statement 1. A method for providing credentials to enable a second party to verify the identity of a first party, wherein the first party is associated with a first public key, wherein the first public key is registered with a third party, and wherein the method comprises:

[0181] Provide one or more first credentials to the second party;

[0182] Obtain a request transaction, which is a blockchain transaction, comprising a) an input containing a signature generated based on the corresponding private key of the third party, and b) an output locked to the second public key of the first party, wherein the second public key is based on the first public key;

[0183] A confirmation transaction is generated, which is a blockchain transaction and includes inputs referencing the output of the request transaction, and a signature generated based on a private key corresponding to the second public key of the first party; and

[0184] This prompts the confirmation transaction to be transmitted to one or more nodes in the blockchain network so that it can be included in the blockchain.

[0185] Examples of one or more primary credentials include: username, password, biometric identifier, phone number, address, code received in SMS text (from a third party), payment card (or its information), bank details, easy-to-remember words, etc.

[0186] Statement 2. The method as described in Statement 1, wherein obtaining includes obtaining the requested transaction from the blockchain.

[0187] Statement 3. The method as described in Statement 1, wherein obtaining includes obtaining the requested transaction from the corresponding memory pool of one or more nodes of the blockchain network, wherein each corresponding memory pool includes a set of corresponding unconfirmed blockchain transactions.

[0188] Statement 4. The method described in any of the foregoing statements, wherein the provision of one or more first credentials is in response to receiving an identity challenge from the second party.

[0189] Statement 5. The method described in any of the foregoing statements, wherein the prompting includes transmitting the transaction to one or more nodes of the blockchain network.

[0190] Statement 6. The methods described in any of the foregoing statements include:

[0191] Received from or sent to the second party: at least one of a message and / or a hash of the message; and

[0192] Determine whether the request transaction includes at least one of the message, the hash of the message, and / or the multiple hash of the message, and wherein the condition for generating the confirmation transaction is that the request transaction includes at least one of the message, the hash of the message, and / or the preimage of the multiple hash of the message.

[0193] Statement 7. The method as described in Statement 6, wherein the output of the request transaction includes a challenge requiring knowledge of the message and / or the hash of the message in order to be unlocked, and wherein the input of the confirmation transaction includes the message, the hash of the message, and / or the preimage of the multiple hash of the message.

[0194] Statement 8. The method as described in Statement 6 or Statement 7, wherein the message includes a first pseudo-random number.

[0195] Statement 9. The method as described in any one of Statements 1 to 8, wherein the second public key is generated by combining the first public key with a second pseudo-random number.

[0196] Statement 10. The method as described in any one of Statements 1 to 8, wherein the second public key is the first public key.

[0197] Statement 11. The method as described in Statement 8 or Statement 9, wherein the first random number and / or the second pseudo-random number is based on a third pseudo-random number generated by the first party and a fourth pseudo-random number generated by the second party.

[0198] Statement 12. The method as described in Statement 9 or Statement 11, wherein the second pseudo-random number is the first pseudo-random number.

[0199] Statement 13. As described in any of the foregoing statements, wherein the third party is the second party.

[0200] Statement 14. A method for verifying the identity of a first party, wherein the first party is associated with a first public key, wherein the first public key is registered with a third party, and wherein the method comprises:

[0201] Receive a request to verify the identity of the first party;

[0202] Generate a request transaction, which is a blockchain transaction, comprising a) an input of a signature generated based on the corresponding private key of the third party and b) an output of a second public key locked in the first party, wherein the second public key is based on the first public key;

[0203] This causes the requested transaction to be transmitted to one or more nodes in the blockchain network so that it can be included in the blockchain; and

[0204] Determine whether a confirmation transaction has been transmitted to one or more nodes of the blockchain network for inclusion in the blockchain, the confirmation transaction being a blockchain transaction that includes inputs referencing the output of the request transaction and a signature generated based on a private key corresponding to a second public key of the first party.

[0205] The request can be a blockchain transaction.

[0206] Statement 15. The method as described in Statement 14, wherein determining whether a confirmation transaction has been transmitted to one or more nodes of the blockchain network for inclusion in the blockchain comprises:

[0207] Determine whether the confirmed transaction is included in the blockchain.

[0208] Statement 16. The method as described in Statement 15, wherein determining whether a confirmation transaction has been transmitted to one or more nodes of the blockchain network for inclusion in the blockchain comprises:

[0209] Determine whether the confirmed transaction is included in the corresponding memory pool of one or more nodes of the blockchain network, wherein each corresponding memory pool includes a set of corresponding unconfirmed blockchain transactions.

[0210] Statement 17. The method as described in any one of Statements 14 to 16, comprising:

[0211] The identity of the first party is verified based on whether the confirmed transaction has been transmitted to one or more nodes of the blockchain network.

[0212] Statement 18. The method as described in Statement 17, wherein the request is received from a second party, and wherein the method comprises:

[0213] Transmit to the second party an indication that the identity of the first party has been verified.

[0214] The instruction can be a blockchain transaction.

[0215] Statement 19. The method as described in Statement 18, wherein receiving the request comprises: receiving an indication that the first party has provided one or more first credentials to the second party.

[0216] Statement 20. The method as described in Statement 18 or Statement 19, wherein the request comprises at least one of a message or a hash of the message, and wherein the output of the request transaction comprises a challenge requesting to know the message and / or the hash of the message in order to be unlocked.

[0217] Statement 21. The method as described in Statement 20, wherein the message includes a first pseudo-random number.

[0218] Statement 22. The method of any one of Statements 14 to 21, wherein the second public key is generated by combining the first public key with a second pseudo-random number.

[0219] Statement 23. The method as described in Statement 21 or Statement 22, wherein the first random number and / or the second pseudo-random number is based on a third pseudo-random number generated by the first party and a fourth pseudo-random number generated by the second party.

[0220] Statement 24. The method as described in any one of Statements 14 to 21, wherein the second public key is the first public key.

[0221] Statement 25. The method as described in any one of Statements 14 to 24, wherein the output of the request transaction is locked to the second public key of the first party or the public key of the third party.

[0222] Statement 26. The method described in Statement 25 includes:

[0223] Generate a cancellation transaction, which is a blockchain transaction comprising input referencing the output of the request transaction and a signature generated based on a private key corresponding to the public key of the first party; and

[0224] This causes the cancellation transaction to be transmitted to one or more nodes in the blockchain network so that it can be included in the blockchain.

[0225] Statement 27. The method described in Statement 17 and any statement referenced therein, wherein the second party controls access to or ownership of the resource or service, and wherein access to or ownership of the resource or service is granted to the first party based on authentication of the first party.

[0226] Examples of resources or services include physical or digital goods, email accounts, social media or other online accounts, streaming services, digital tokens (such as tickets or votes), etc.

[0227] Statement 28. The method as described in any one of Statements 14 to 27, wherein the second party is the third party.

[0228] Statement 29. A computer device comprising:

[0229] Includes a memory with one or more storage units; and

[0230] A processing device comprising one or more processing units, wherein the memory stores code arranged for execution on the processing device, the code being configured to perform any one of claims 1 to 28 when executed on the processing device.

[0231] Statement 30. A computer program embedded in a computer-readable storage medium and configured to perform the method of any one of Statements 1 to 28 when running on a computer device as described in Statement 29.

[0232] Other variations will be apparent to those skilled in the art once the disclosure herein has been given. The scope of this disclosure is not limited to the disclosed embodiments, but only to the appended claims.

Claims

1. A method for providing credentials to enable a second party to verify the identity of a first party, wherein the first party is associated with a first public key, wherein the first public key is registered with a third party, and wherein the method is performed by the first party and includes: Provide one or more first credentials to the second party; Obtain a request transaction, which is a blockchain transaction that has been transmitted to one or more nodes of the blockchain network and includes a) an input containing a signature generated based on the corresponding private key of the third party, and b) an output locked to the second public key of the first party, wherein the second public key is based on the first public key; Generate a confirmation transaction, which is a blockchain transaction, and the confirmation transaction includes an input referencing the output of the request transaction and a signature generated based on a private key corresponding to the second public key of the first party. as well as This prompts the confirmation transaction to be transmitted to one or more nodes in the blockchain network so that it can be included in the blockchain.

2. The method as described in claim 1, wherein, The acquisition includes obtaining the requested transaction from the blockchain.

3. The method as described in claim 1, wherein, The acquisition includes obtaining the requested transaction from the corresponding memory pool of one or more nodes of the blockchain network, wherein each corresponding memory pool includes a set of corresponding unconfirmed blockchain transactions.

4. The method as described in any of the preceding claims, wherein, Providing one or more first credentials is in response to receiving an identity challenge from the second party.

5. The method as described in any one of the preceding claims, wherein, The prompting includes transmitting the transaction to one or more nodes in the blockchain network.

6. The method as described in any of the preceding claims, comprising: At least one of receiving or sending messages to the second party and / or the hash of the messages; as well as Determine whether the request transaction includes at least one of the message, the hash of the message, and / or the multiple hash of the message, and wherein the condition for generating the confirmation transaction is that the request transaction includes at least one of the message, the hash of the message, and / or the preimage of the multiple hash of the message.

7. The method of claim 6, wherein, The output of the request transaction includes a challenge requiring knowledge of the message and / or the hash of the message in order to be unlocked, and the input of the confirmation transaction includes the message, the hash of the message, and / or the preimage of the multiple hash of the message.

8. The method of claim 6 or 7, wherein, The message includes a first pseudo-random number.

9. The method according to any one of claims 1 to 8, wherein, The second public key is generated by combining the first public key with a second pseudo-random number.

10. The method according to any one of claims 1 to 8, wherein, The second public key is the first public key.

11. The method of claim 8, wherein, The first pseudo-random number is based on a third pseudo-random number generated by the first party and a fourth pseudo-random number generated by the second party.

12. The method of claim 9, wherein, The second pseudo-random number is based on a third pseudo-random number generated by the first party and a fourth pseudo-random number generated by the second party.

13. The method of claim 8, wherein, The second public key is generated by combining the first public key with a second pseudo-random number; wherein the second pseudo-random number is the first pseudo-random number.

14. The method as described in any of the preceding claims, wherein, The third party is the second party.

15. A method for verifying the identity of a first party, wherein, The first party is associated with a first public key, wherein the first public key is registered with a third party, and wherein the method is performed by the third party and includes: Receive a request to verify the identity of the first party; Generate a request transaction, which is a blockchain transaction, comprising a) an input containing a signature generated based on the corresponding private key of the third party, and b) an output locked in the second public key of the first party, wherein the second public key is based on the first public key; The request transaction is transmitted to one or more nodes in the blockchain network so that it can be included in the blockchain; and Determine whether a confirmation transaction has been transmitted to one or more nodes of the blockchain network for inclusion in the blockchain, the confirmation transaction being a blockchain transaction, the confirmation transaction including inputs referencing the output of the request transaction, and a signature generated based on a private key corresponding to a second public key of the first party.

16. The method of claim 15, wherein, The process of determining whether a confirmation transaction has been transmitted to one or more nodes of the blockchain network for inclusion in the blockchain includes: Determine whether the confirmed transaction is included in the blockchain.

17. The method of claim 16, wherein, The process of determining whether a confirmation transaction has been transmitted to one or more nodes of the blockchain network for inclusion in the blockchain includes: Determine whether the confirmed transaction is included in the corresponding memory pool of one or more nodes of the blockchain network, wherein each corresponding memory pool includes a set of corresponding unconfirmed blockchain transactions.

18. The method of any one of claims 15 to 17, comprising: The identity of the first party is verified based on whether the confirmed transaction has been transmitted to one or more nodes of the blockchain network.

19. The method of claim 18, wherein, Receiving the request from a second party, and wherein the method includes: Transmit to the second party an indication that the identity of the first party has been verified.

20. The method of claim 19, wherein, Receiving the request includes receiving an indication that the first party has provided one or more first credentials to the second party.

21. The method of claim 19 or 20, wherein, The request includes at least one of a message or a hash of the message, and the output of the request transaction includes a challenge to know the message and / or the hash of the message in order to be unlocked.

22. The method of claim 21, wherein, The message includes a first pseudo-random number.

23. The method according to any one of claims 15 to 22, wherein, The second public key is generated by combining the first public key with a second pseudo-random number.

24. The method of claim 22, wherein, The first pseudo-random number is based on a third pseudo-random number generated by the first party and a fourth pseudo-random number generated by the third party.

25. The method of claim 23, wherein, The second pseudo-random number is based on a third pseudo-random number generated by the first party and a fourth pseudo-random number generated by the third party.

26. The method according to any one of claims 15 to 22, wherein, The second public key is the first public key.

27. The method of any one of claims 15 to 26, wherein, The output of the request transaction is locked to the second public key of the first party or the public key of the third party.

28. The method of claim 27, comprising: Generate a cancellation transaction, which is a blockchain transaction and includes inputs that reference the output of the request transaction and a signature generated based on a private key corresponding to the public key of the first party. as well as This causes the cancellation transaction to be transmitted to one or more nodes in the blockchain network so that it can be included in the blockchain.

29. The method of claim 19, wherein, The second party controls access to or ownership of the resources or services, and the access to or ownership of the resources or services is granted to the first party based on the authentication of the first party.

30. The method of claim 19, wherein, The second party is the third party.

31. A computer device, comprising: A memory, comprising one or more storage units; and A processing apparatus, comprising one or more processing units, wherein the memory stores code arranged for execution on the processing apparatus, the code being configured to perform the method as claimed in any one of claims 1 to 30 when executed on the processing apparatus.

32. A computer program product embedded in a computer-readable storage medium and configured to perform the method of any one of claims 1 to 30 when running on a computer device as claimed in claim 31.

Images