BioLockseed

Abstract

This provides a method for storing a biometric vault system on a blockchain. [Solution] The biometric vault system comprises one or more biometric vaults, each biometric vault locking its respective secret value, obtaining at least one biometric reading, identifying multiple biometric features from at least one biometric reading, generating one or more first biometric vaults, generating one or more blockchain transactions, and transmitting one or more blockchain transactions to the blockchain network. Each blockchain transaction includes its respective output which includes at least a portion of its respective second biometric vault, and each second biometric vault includes its respective first biometric vault.

Description

[Technical Field]

[0001] This disclosure relates to a method for storing a biometric vault system on a blockchain. [Background technology]

[0002] Public-key cryptography is a type of cryptographic system that uses a pair of keys: a private key known only to the owner of the private key, and a public key generated based on the corresponding private key, which can be distributed without compromising the security of the private key. Public-key cryptography allows a sender to encrypt a message using the recipient's public key (i.e., the public key corresponding to the private key known only to the recipient). Therefore, an encrypted message can only be decrypted using the recipient's private key.

[0003] Similarly, a sender may sign a message using their private key, for example, to prove that the message was sent by them and / or to indicate that the sender agrees to the message. The signer (i.e., the party generating the signature) uses their private key to create a digital signature based on the message. Anyone with the signer's corresponding public key can use the same message and the digital signature on the message to verify whether the signature was validly created, i.e., whether the signature was actually created using the signer's private key.

[0004] Private keys are typically generated using a "seed." A seed is confidential data known only to the owner(s) of the private key(s) that should be generated by that seed. One or more private keys are generated as a function of the seed. For example, a hash function can be applied to the seed to generate a private key, sometimes called a "master private key." In addition to the initial generation, the same private key can be regenerated, or reconstructed, using the same seed. For example, if a user loses their private key(s), they can reconstruct those keys as long as they know the seed(s).

[0005] One specific area that utilizes public-key cryptography is blockchain technology. In addition to encrypting messages (e.g., data stored in transaction output), public keys are also used to "lock," or assign, the output to the owner of the private key corresponding to a given public key. In this case, only the owner of the private key can "unlock" the output. Further details on the use of public-key cryptography in the context of blockchain are provided below. [Overview of the project]

[0006] One common standard for managing private keys for use on a blockchain is hierarchical deterministic (HD) key management. For example, in BIP (Bitcoin Improvement Proposal) 32, the hierarchical key tree is derived from a single entropy source using a deterministic public algorithm. The first step of the algorithm is to generate a seed. The seed is generated as a random bit string (256 bits preferred) from a pseudorandom number generator (PRNG). HD key management efficiently solves the bag-of-key problem. The remaining challenge is that users need to remember and / or write down the seed, store it securely, and communicate it when they need to rebuild or share their private key ("wallet," sometimes called a wallet of keys). Humans tend to fail at these tasks when the seed is a raw bit string.

[0007] This problem was solved in BIP39. A system was proposed that abstracts the entropy required for the master key into a mnemonic phrase. Mnemonic phrases are easy to manipulate and more user-friendly than raw seeds. The remaining challenge is that security and usability are conflicting objectives. Wallet security increases with increasing seed entropy. This, in turn, increases the number of random words in the mnemonic phrase to such an extent that it becomes increasingly difficult or impossible to remember. To balance this challenge, BIP39 specifies an "acceptable entropy size" in the range of 128 to 256 bits, and 2 11 A dictionary of individual words was proposed, and phrase lengths of up to 24 words were provided.

[0008] Therefore, the remaining challenge consists of simultaneously achieving the following: on the one hand, generating a user-friendly seed that does not need to be memorized and is easy to recall; and on the other hand, generating a seed with no limitations on the magnitude of entropy.

[0009] Therefore, it is desirable to overcome either of these challenges, or even more desirable to achieve the dual objective of overcoming both challenges simultaneously. Similar considerations may apply to other types of hierarchical domain wallets, or more generally, to any method for generating the seed from which the keys are derived.

[0010] According to one aspect disclosed herein, a computer implementation method for storing a biometric vault system on a blockchain, wherein the biometric vault system comprises one or more biometric vaults, each biometric vault locking its respective secret value, the method comprising the steps of obtaining at least one biometric reading, identifying a plurality of biometric features from at least one biometric reading, and generating one or more first biometric vaults, each first biometric vault corresponding to each target biometric feature of the plurality of biometric features, each comprising a plurality of binary data pairs, each data pair comprising a first binary value and a second binary value, and the first binary value A method is provided which includes the steps of: a step of generating one or more blockchain transactions, each blockchain transaction comprising an output comprising at least a portion of each second biometric vault, each second biometric vault comprising each first biometric vault; and a step of transmitting one or more blockchain transactions to a blockchain network.

[0011] Another embodiment disclosed herein provides a computer implementation method for unlocking one or more biometric vaults in a biometric vault system, the method comprising: obtaining at least one candidate biometric reading; identifying a plurality of biometric features from at least one biometric reading; generating a plurality of respective candidate binary representations of each of the plurality of biometric features; obtaining one or more second biometric vaults from a blockchain, each second biometric vault comprising each first biometric vault, each first biometric vault comprising a plurality of respective first binary values ​​paired with each second binary value; determining each first first binary value for each of the plurality of candidate binary representations corresponding to each of the plurality of first biometric vaults; obtaining a second binary value for a threshold number paired with each of the first binary representations of the first threshold number; and reconstructing a first-level secret value based on each of the second binary values ​​of the first threshold number.

[0012] A biometric vault system locks one or more secret values ​​(hereinafter referred to as “seeds”). Different first-level secret values ​​are “locked” in separate vaults of the system. Each vault contains first binary values ​​linked to second binary values. Some of the first binary values ​​are their respective binary representations generated based on the user’s biometric characteristics. In some examples, some of the first binary values ​​are simulated (i.e., fake) binary representations of biometric characteristics linked to simulated second binary values. Reconstructing a first-level secret value locked by a given vault requires a threshold number of “actual” second binary values. Each vault may be stored in the output of different blockchain transactions recorded on the blockchain, or, in some examples, a vault may be divided into vault slices, each slice stored in a different blockchain transaction.

[0013] When a user needs to recover their seed, they provide one or more other (live) biometric readings as needed. The vault is retrieved from a blockchain transaction. Once the user provides their readings, a set of candidate biometric representations is generated based on the user's biometric characteristics. Using these candidate biometric representations, first biometric representations matching the candidate representations are identified in each biometric vault, and second binary values ​​mapped to those first biometric representations are retrieved. Once a threshold number of first biometric representations are identified and a threshold number of second binary values ​​are retrieved, the first-level secret value (e.g., seed) can be reconstructed. If the vault system locks a second secret value, i.e., a "second-level" secret value, the above process may be performed for a threshold number of vaults. Once a threshold number of first-level secret values ​​are retrieved, they can be used to reconstruct the second-level secret value (e.g., seed).

[0014] The first-level secret values ​​and / or second-level secret values ​​may be used to derive each set of secret keys, for example, a hierarchical deterministic key structure.

[0015] A bio-locked seed (or more commonly, a bio-locked secret) can, in some examples, provide access to reproducible entropy of unlimited size. This is achieved by a system of bio-vaults, where expirable on-chain bio-vaults are distributed (e.g., randomly) among the outputs of blockchain transactions. Each vault locks a different secret value, which can then be used as a random partial clue to build or rebuild another seed of any size. Each secret value (or "clue") can only be unlocked by the intended user.

[0016] This method does not rely on error correction decoding and can reduce or eliminate reliance on the accuracy of manutsea recognition techniques by introducing redundancy into the vault system. System redundancy also reduces or eliminates reliance on accidents that physically lose some manutsea features. Furthermore, a shared wallet can be created if a vault system that unlocks the same high-entropy seed contains bio-vaults where some vaults are based on the bio-features of one user and other vaults within the same system are based on the bio-features of another user. [Brief explanation of the drawing]

[0017] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the accompanying drawings are referenced merely as examples. [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2]Here are some schematic examples of transactions that can be recorded on the blockchain. [Figure 3] This shows exemplary biological characteristics of fingerprints. [Figure 4] This indicates the maneuver position relative to other maneuvers and independent of the central reference frame. [Figure 5] This shows the orientation of the manute as a tangent to the ridge at the manute point of the fingerprint. [Figure 6] This illustrates a function transformation in maneuvers. [Figure 7] This demonstrates the extraction of Manutsha's invariants. [Figure 8] This illustrates a function transformation in maneuvers. [Figure 9] An illustrative transaction for recording a vault on the blockchain is shown in outline. [Figure 10] A schematic diagram of an exemplary transaction for recording a vault slice on the blockchain is shown. [Figure 11] This diagram schematically illustrates an exemplary transaction for different users to record a vault on the blockchain. [Figure 12] This diagram schematically illustrates exemplary transactions for different users to record vault slices on the blockchain. [Figure 13] Several embodiments schematically illustrate exemplary methods for a first user to record a vault system on a blockchain. [Figure 14] Several embodiments schematically illustrate exemplary methods for a first user to rebuild a seed. [Figure 15] This outlines exemplary methods for two users to record a shared vault system on a blockchain, using several embodiments. [Modes for carrying out the invention]

[0018] Overview of the Exemplary System Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may consist of a packet-switched network 101, which is typically a wide-area internet such as the internet. The packet-switched network 101 may include a number of blockchain nodes 104 that can be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0019] Each blockchain node 104 includes the computer equipment of its peers, and different nodes 104 belong to different peers. Each blockchain node 104 comprises processing equipment including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROM, and / or optical media such as optical disc drives.

[0020] Blockchain 150 contains a chain of data blocks 151, and each copy of blockchain 150 is maintained on each of the multiple blockchain nodes 104 within a decentralized or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean completely memorizing blockchain 150. Instead, blockchain 150 can be pruned, as long as each blockchain node 150 remembers the block header (described later) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 contains at least one input and at least one output. Each output specifies an amount representing the quantity of a digital asset as a property, an example being user 103, whose output is cryptographically locked (requiring the user's signature or other solution to be unlocked and thereby redeemed or used). Each input points to the output of the preceding transaction 152, thereby linking the transactions.

[0021] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain to define the order of block 151. Each transaction 152 (other than coinbase transactions) contains a pointer back to the previous transaction to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The chain of block 151 goes all the way back to the genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in chain 150 pointed to the genesis block 153, rather than a preceding transaction.

[0022] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in their respective memory. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. This term is not intended to be limited to any particular blockchain, protocol, or model as used herein. It refers to an ordered set of transactions that a node 104 has accepted as valid, to which the node 104 is obligated not to accept other transactions attempting to use the same output.

[0023] In a given current transaction 152j, its input (or each input) contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. A preceding transaction 152i must exist and be validated for the current transaction to be valid, but it does not necessarily have to exist when the current transaction 152j is created or sent to network 106. Thus, "preceding" as used herein refers to something preceding in a logical sequence linked by a pointer, and not necessarily to a time in a time sequence, and therefore does not necessarily exclude the creation or transmission of transactions 152i, 152j from being created or sent out of order (see the following explanation of orphan transactions). A preceding transaction 152i is also called an antecedent transaction or predecessor transaction.

[0024] The input to the current transaction 152j also includes input authorization, for example, the signature of user 103a, to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b, as defined in the output of the current transaction 152j. In some cases, transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to give the remainder (change)). In some cases, a transaction may also have multiple inputs to aggregate amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0025] According to output-based transaction protocols such as Bitcoin, when a party 103, such as an individual user or organization, wishes to compose a new transaction 152j (either manually or through an automated process adopted by the party), the composing party sends the new transaction from its computer terminal 102 to a recipient. The composing party or recipient then sends this transaction to one or more blockchain nodes 104 on the network 106 (which are currently typically servers or data centers, but may in principle be other user terminals). It is not excluded that the party 103 composing the new transaction 152j sends the transaction directly to one or more blockchain nodes 104 and, in some examples, does not send it to a recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applicable to each blockchain node 104. The blockchain node protocol typically asks the blockchain node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i assigned by the new transaction, which typically includes checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i. Alternatively, it may be fixed by the blockchain node protocol alone, or by a combination of these.In any case, if the new transaction 152j is valid, blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0026] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., used) is whether it has been validly redeemed by the input of another preceding transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Similarly, if it is not valid, transaction 152j will neither propagate nor be recorded in blockchain 150 (unless it is flagged as invalid and propagated for a warning). This prevents double spending, where a transactor attempts to allocate the output of the same transaction multiple times. Account-based models, on the other hand, prevent double spending by maintaining account balances. Again, since a transaction order is defined, account balances are always in a single, defined state.

[0027] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly known as mining, supported by "proof of work." At blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 recorded on blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transaction 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash has a specific predetermined number of leading zeros. Note that this is just one specific type of proof of work puzzle, and does not exclude other types. A property of a hash function is that it has an unpredictable output for its input. Therefore, this search can only be performed by brute force, which consumes a considerable amount of processing resources on each of the 104 blockchain nodes attempting to solve the puzzle.

[0028] The blockchain node 104 that first solves the puzzle publishes it to the network 106, providing its solution as a proof that can later be easily checked by other blockchain nodes 104 in the network (given a solution for a hash, it is easy to check that the output of the hash satisfies the conditions). This first blockchain node 104 propagates the block to the threshold consensus of other nodes that accept this block and enforces the protocol rules. The ordered set of transactions 154 is then recorded as a new block 151 in blockchain 150 by each of the blockchain nodes 104. The block pointer 155 is also assigned to a new block 151n that points to a previously created block 151n-1 in the chain. The considerable amount of effort required to create the proof of work solution, for example in the form of a hash, demonstrates the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, also known as double spending. Once created, block 151 is recognized and maintained at each of the blockchain nodes 104 within the blockchain network 106, and therefore cannot be modified. The block pointer 155 also assigns order to block 151. Transaction 152 is recorded in an ordered block at each blockchain node 104 within the network 106, thus providing an immutable public ledger of transactions.

[0029] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when they began searching for the solution or the order in which the transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to create a block from the newly defined ordered pool of unpublished transactions 154, and so on. There also exists a protocol for resolving any "forks" that may occur when two blockchain nodes 104 solve the puzzle to each other in a very short time, resulting in conflicting views of the blockchain propagating between the nodes 104. In short, whichever prong of the fork grows the longest will result in a deterministic blockchain 150. It should be noted that this does not affect the network's users or agents, as the same transactions will appear in both forks.

[0030] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional amount of accepted digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to inter-agent or inter-user transactions that transfer a certain amount of digital assets from one agent or user to another agent or user). This special type of transaction is usually called a "coinbase transaction," but is sometimes called an "initiation transaction" or "generation transaction." This typically forms the first transaction of a new block 151n. Proof of work indicates the intention of the node constructing the new block to follow protocol rules that will allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturity period, for example, 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created block 151n in which the transaction was published. This fee is usually called a "transaction fee" and is explained below.

[0031] Due to the resources involved in transaction validation and publication, typically, at least each of the blockchain nodes 104 takes the form of a server including one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0032] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform one or more of its respective roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributable to a blockchain node 104 may be performed by software running on the processing unit of the respective computer device. Node software may be implemented in one or more applications at the application layer, or at lower layers such as the operating system layer or protocol layer, or at any combination thereof.

[0033] The computer devices 102 of each of the multiple parties 103, who act as consumer users, are also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in transaction validation or block construction. Some of these users or agents 103 may act as senders and receivers of transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., copies obtained from blockchain node 104).

[0034] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) can be said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104, as they do not perform the role required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106 and may utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. There are many more such parties 103 and their respective computer devices 102 that could participate in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a is referred to herein as Alice, and the second party 103b as Bob; however, this is not restrictive, and it should be understood that any reference to Alice or Bob herein may be replaced with “the first party” and “the second party,” respectively.

[0035] Each computer device 102 of Party 103 comprises one or more processors, each processing unit including, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. This memory may comprise one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical disc drives. The memory on each computer device 102 of Party 103 stores software including each instance of at least one client application 105 configured to run on the processing unit. It will be understood herein that any action attributable to a given Party 103 may be performed using software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 includes at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0036] The client application 105 may first be provided to the computer equipment 102 of any given party 103 on one or more suitable computer-readable storage devices, for example, it may be downloaded from a server or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0037] The client application 105 has at least a “wallet” function, which has two main functions. One of these is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104, thereby propagating the transaction 152 throughout the network of blockchain nodes 104 and including it in the blockchain 150. The other is to report to each party the amount of digital assets that the party currently owns. In an output-based system, this second function includes matching the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to that party.

[0038] Various client functions may be described as being integrated into a given client application 105, but are not necessarily limited to this. Instead, it should be noted that any client function described herein may be implemented, for example, in a set of two or more separate applications that interface via an API or where one is a plug-in to the other. More generally, client functions may be implemented in the application layer, a lower layer such as the operating system, or any combination thereof. The following description will focus on client application 105, but will not be limited to it.

[0039] Each computer device 102 instance of a client application or software 105 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact blockchain node 104 to query blockchain 150 for any transaction in which each party 103 is the recipient (or, in embodiments, actually inspect the transactions of other parties in blockchain 150, since blockchain 150 is a public facility that provides trust in transactions through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and forward transaction 152 to propagate them throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol follows (goes with) a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all 152 transactions in blockchain 150. The same node protocol is used by all 104 nodes in network 106.

[0040] When a given party 103, for example Alice, wishes to send a new transaction 152j to be included in blockchain 150, Alice formulates the new transaction according to the relevant transaction protocol (using the wallet function in Alice's client application 105). Alice then sends transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this could be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which are described in more detail below. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in transaction 152. Alternatively, the conditions may simply be built-in features of the node protocol or may be defined by a combination of the script and the node protocol.

[0041] Provided that the newly received transaction 152j passes the tests required to be considered valid (i.e., is "validated"), any blockchain node 104 receiving transaction 152j adds the new validated transaction 152 to the ordered set 154 of transactions maintained at that blockchain node 104. Furthermore, any blockchain node 104 receiving transaction 152j propagates the validated transaction 152 forward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, assuming transaction 152j is valid, this means it will propagate immediately throughout the network 106.

[0042] Once a pending transaction is approved in an ordered pool 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle against the latest version of each pool 154 containing the new transaction 152. (It should be noted that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but the first node to solve it defines the set of transactions included in the latest block 151. Ultimately, blockchain node 104 will have solved the puzzle for the portion of the ordered pool 154 containing Alice's transaction 152j.) Once proof-of-work is performed against the pool 154 containing the new transaction 152j, it universally becomes part of one of the blocks 151 within blockchain 150. The order of transactions is also immutably recorded, as each transaction 152 contains a pointer back to the previous transaction.

[0043] Different blockchain nodes 104 may initially receive different instances of a given transaction, and therefore have conflicting views on which instance is "valid" until one instance is published in a new block 151 (at which point all blockchain nodes 104 agree that the published instance is the only valid instance). If a blockchain node 104 accepts one instance as valid and then discovers that another instance is recorded in blockchain 150, that blockchain node 104 must accept this and discard the first instance it accepted (i.e., the one not published in block 151) (i.e., treat it as invalid).

[0044] Alternative types of transaction protocols that operate on several blockchain networks can be called “account-based” protocols as part of an account-based transaction model. In the account-based model, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by the nodes of that network, separately from the blockchain. In such a system, transactions are ordered using the account’s running transaction tally (also called “position”). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field in the transaction can also be signed. This data field may point to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0045] UTXO-based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following discussion will refer to output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it can be equally implemented on other exemplary blockchain networks.

[0046] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure containing one or more inputs 202 and one or more outputs 203. Each output 203 may contain an unused transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents the number of tokens set on the distributed ledger. The UTXO may also contain the transaction ID of the underlying transaction, among other information. The transaction data structure may also include a header 201 which may contain indicators showing the size of the input field(s) 202 and the output field(s) 203. The header 201 may also contain the ID of the transaction. 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 raw transaction 152 submitted to node 104.

[0047] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". This takes the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, or that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., earlier) transaction that still has the unused output 203 locked in Alice.

[0048] The preceding transaction Tx0 may already be validated and included in block 151 of blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice sends it to network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in ordered set 154, in which case it will immediately be included in the new block 151. Alternatively, Tx0 and Tx1 could be created and sent together to network 106, or even sent after Tx1 if the node protocol allows buffering of “orphan” transactions. As used herein in the context of transaction sequences, the terms “predecessor” and “successor” refer to the order of transactions in a sequence defined by transaction pointers specified within the transactions (such as which transaction points to which other transactions). They can similarly be replaced with “predecessor” and “successor,” or “first” and “later,” “parent” and “child,” etc. This does not necessarily imply any order of their creation, transmission to network 106, or arrival at any given blockchain node 104. Nevertheless, a subsequent transaction (later transaction, or "child") pointing to a preceding transaction (earlier transaction, or "parent") will not be validated unless the parent transaction is validated. A child arriving at blockchain node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for its parent or discarded, depending on the node protocol and / or node behavior.

[0049] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO labeled herein as UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a lock script, the lock script defining the conditions that the unlock script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the lock script locks that amount to a specific party (the beneficiary of the transaction in which it is contained). That is, the lock script typically defines unlock conditions that include the condition that the unlock script in the input of the subsequent transaction contains the cryptographic signature of the party to which the preceding transaction is locked.

[0050] The lock script (commonly known as scriptPubKey) is a piece of code written in a proprietary language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to use transaction output 203, for example, the need for Alice's signature. The unlock script appears in the transaction output. The unlock script (commonly known as scriptSig) is a piece of code written in a proprietary language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. The unlock script appears in transaction input 202.

[0051] In other words, in the illustrated example, the UTXO0 in output 203 of Tx0 is redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be valid) by Alice's signature Sig P A Lock script that requires [Checksig P A ] includes. [Checksig P A ] is the public key P of Alice's public key-private key pair. Aincludes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer indicating Tx1 (e.g., in an embodiment, its transaction ID, TxID0, which is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 within Tx0 to identify UTXO0 from among any other possible outputs of Tx0. The input 202 of Tx1 includes an unlock script <Sig P A > that includes an Alice's cryptographic signature created by applying Alice's private key of the key pair to a predetermined portion of the data (which may also be called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

[0052] When a new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This includes executing the lock script and the unlock script together to check whether the unlock script meets the conditions defined by the lock script (which conditions may include one or more criteria). In an embodiment, this includes concatenating the two scripts: <Sig P A > <P A > || [Checksig P A Here, "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function composed of the lock script (in this example, a stack-based language). Equally, the scripts can be executed one after another using a common stack instead of concatenating the scripts. In any case, when executed together, the scripts use the public key P of Alice as included in the lock script within the output of Tx0 A ​The unlock script in the input of Tx1 authenticates that it contains Alice's signature, which signs the expected portion of the data. The expected portion of the data itself ("the message") must also be included in order to perform this authentication. In this embodiment, the signed data includes the entirety of Tx1 (i.e., a separate element specifying the signed portion of the data in plaintext does not need to be included, as it already essentially exists).

[0053] The details of authentication using public-secret cryptography are well known to those skilled in the art. Essentially, if Alice signs a message using her private key, another entity, such as node 104, given Alice's public key and the plaintext message, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging the message with this as the signature, so that any holder of the public key can authenticate the signature. Therefore, any reference herein to signing a particular portion of data or part of a transaction, etc., may in embodiments mean signing a hash of that portion of data or part of a transaction.

[0054] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), blockchain node 104 considers Tx1 to be valid. This means that blockchain node 104 will add Tx1 to the ordered pool 154 of pending transactions. Blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in network 106 so that transaction Tx1 is propagated throughout network 106. Once Tx1 is validated and included in blockchain 150, this defines the UTXO0 from Tx0 as used. Note that Tx1 can only be valid if it uses unused transaction output 203. If Tx1 attempts to use output that has already been used by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been used (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transaction 152. In practice, a given blockchain node 104 could maintain a separate database marking which UTXO 203 in which transaction 152 has been used, but ultimately, what defines whether a UTXO has been used is whether it has already formed a valid input to another valid transaction in blockchain 150.

[0055] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all inputs 202, this constitutes another ground for invalidity in most transaction models. Therefore, such a transaction would neither propagate nor be included in block 151.

[0056] In a UTXO-based transaction model, it should be noted that a given UTXO must be used as a whole. A portion of the amount defined as used in a UTXO cannot be "left behind," even if another portion has been used. However, amounts from a UTXO can be split across multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 within Tx0 can be split across multiple UTXOs within Tx1. Therefore, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to either give the remainder to herself in the second output of Tx1 or pay it to another party.

[0057] In practice, Alice would also typically need to include a fee to the Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and, therefore, not propagated and not included in blockchain 150, even if technically valid (the node protocol does not force blockchain node 104 to accept transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount indicated by the input(s) 202 of a given transaction 152 and the total amount specified by the output(s) 203 is automatically given to the blockchain node 104 publishing the transaction. For example, suppose a pointer to UTXO0 is the sole input to Tx1, and Tx1 has a sole output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by node 104, which wins the proof-of-work competition to generate the block containing UTXO1. However, this does not necessarily preclude the possibility that a transaction fee may be explicitly specified in one of the UTXO203 of transaction 152.

[0058] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 somewhere within blockchain 150. Therefore, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout blockchain 150. Nowhere within blockchain 150 is a number that defines the total balance of a given party 103. The role of the wallet function in the client application 105 is to match all the values ​​of the various UTXOs locked to each party and not yet used in another previous transaction. This can be done by querying a copy of blockchain 150 stored in one of the Bitcoin nodes 104.

[0059] It should be noted that script code is often expressed conceptually (i.e., without using the exact language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For example, OP_RETURN is a scripting language opcode that creates an unusable output of a transaction, which can store data within the transaction and thereby immutably record the data within the blockchain, when preceded by OP_FALSE at the beginning of the lock script. For example, the data may include documents that are desired to be stored on the blockchain.

[0060] Typically, the input to a transaction is the public key P AThis includes a corresponding digital signature. In embodiments, this is based on ECDSA using elliptic curve secp256k1. The digital signature signs a specific portion of the data. In some embodiments, for a given transaction, the signature signs a portion of the transaction input and some or all of the transaction output. The specific portion of the signed output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code typically included at the end of the signature to select which output is signed (and thus fixed at signing).

[0061] A lock script is sometimes referred to as a "scriptPubKey," typically because it contains the public keys of the parties whose transactions are being locked. An unlock script is sometimes referred to as a "scriptSig," typically because it supplies the corresponding signature. However, more generally, it is not mandatory in all blockchain applications for a UTXO to be redeemed to include the authentication of a signature. More generally, a scripting language can be used to define any one or more conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0062] As shown in Figure 1, the client applications on Alice's and Bob's computer devices 102a and 120b, respectively, may each include additional communication capabilities. This additional capability allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables the exchange of data separately from the blockchain network. Such communication is sometimes called “off-chain” communication. For example, this could be used to exchange transaction 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing onto chain 150 until one of the parties chooses to broadcast the transaction to network 106. Sharing a transaction in this manner is sometimes called sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, or data content.

[0063] Side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, side channel 301 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even via a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, wherever referred to herein, side channel 107 may include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. If two or more links are used, the bundle or collection of off-chain links as a whole may be referred to as side channel 107. Therefore, when it is said that Alice and Bob are exchanging certain parts of information or data etc. over side channel 107, it should be noted that this does not necessarily mean that all of these parts of data must be transmitted over the exact same link or network of the same type.

[0064] BIP PREPARATIVES Below, we describe some properties of the BIP protocol as examples of algorithms for generating and deriving keys. In some embodiments, the currently disclosed schemes may be applied as improvements to the BIP protocol, but more generally, it will be understood that the disclosed schemes may be applicable to any type of algorithm for generating a seed from which a key is derived.

[0065] Seed generation In BIP32, the seed S is generated from the PRNG as a raw bit string. The bit size of such a seed is equal to the size of the entropy the seed provides to derive the master key. The recommended size is 256 bits. Users are required to write down the raw seed S, store it securely, and communicate it when they need to recover or share their wallet. Humans tend to fail at these tasks when directly manipulating binary strings.

[0066] In BIP39, a raw bit string is initially generated from the PRNG, and the specified range for the "allowable entropy size" is 128 to 256 bits. Therefore, 2048 = 2 11 A dictionary containing n words is proposed, where each word corresponds to a different 11-bit binary value. Next, the initial entropy is converted into a mnemonic phrase consisting of up to 24 words. Below, in order to distinguish the initially generated raw seed from the mnemonic phrase, they are referred to as S and S, respectively. W This is shown by S to S W To convert it, first split S into 11-bit substrings. A checksum is appended to the last substring to make it 11 bits long. Each substring is replaced with the corresponding word from the dictionary, and S is presented as a sequence of these words. W The relationship between the length and the bit size of S is shown in the table below. [Table 1]

[0067] Communicating random sequences of words is more user-friendly than communicating binary strings. The remaining challenge is that security and usability are conflicting objectives. Wallet security increases with increasing seed entropy. This increases the length of mnemonic phrases to such an extent that memorization becomes increasingly difficult or impossible. To balance this challenge, BIP39 imposes an upper limit on the permissible entropy.

[0068] The role of the seed in key tree derivation The generated seed S is the master private key sk master This provides the entropy required to derive the formula. This derivation follows Algorithm 1, as described in BIP32.

[0069] Algorithm 1. Master Key Derivation • Calculate I = HMAC_SHA512 (Key = "Bitcon seed", Data = S). • Split I into two 32-byte sequences: I L and I R . · parse256(I L ) is used to interpret the left 32-byte sequence as a 256-bit number (starting from the most significant byte). This value is the master secret key sk master That is the case. · parse256(I R ) is used to interpret the rightmost 32-byte sequence as a 256-bit number. This is the master chaincode c master That is the case. · sk master If = 0 or ≥ n, then sk master This is invalid, and a new seed S is generated.

[0070] Next, the master private key sk, which has entropy embedded in it from seed S, master and chaincode c master Use this to derive the rest of the key tree. In Algorithm 2, sk master and c master The first parent key sk parent and chaincode c parent Therefore, in the key derivation chain, the parent gives birth to a child, and then the child becomes a parent. The child's private key sk child,i and chaincode c child,i This is derived as follows:

[0071] Algorithm 2. Key tree derivation: strengthened child keys and unstrengthened child keys • Key index i ≥ 2 31 If so, the child is an enhanced key, which is derived from:

number

number

[0072] BioLockseed Embodiments of the present invention enable the storage of a seed or some other secret value on a blockchain in a biometric vault system. The biometric vault in the system is locked based on the user's biometric characteristics, for example, based on the user's fingerprint(s), and therefore can only be unlocked based on them. That is, for example, biometric information is extracted from the fingerprint during a live read and used to lock the seed in the vault system. Thus, the vault system is uniquely linked to the user's biometric data. The vault system can then be unlocked later based on another read, for example, by scanning the user's fingerprint. As will be discussed later, the vault system can also be generated based on multiple biometric readings of the same or different types and / or the same or different users, for example.

[0073] For the sake of brevity, embodiments of the present invention will be described with reference to Alice 103a, as described above. That is, embodiments of the present invention may be performed by Alice 103a. It should be noted that this does not mean that embodiments are only executable by users such as Alice 103a. Rather, embodiments of the present invention may be performed by a computing device configured to perform some or all of the actions attributed to Alice 103a above. Similarly, embodiments may be performed by a user operating a computing device running a client application configured to perform some or all of the actions attributed to Bob 103b above. It is also not excluded that embodiments may be performed by parties other than users, such as a server comprising one or more physical server units, or even a party operating an entire data center.

[0074] Generally, the method includes the steps of obtaining at least one biometric reading and generating a vault system based on the biometric features identified in at least one biometric reading. In some examples, two or more biometric readings, each containing its own respective biometric features, may be used to generate the vault system. A biometric reading refers to the observation, i.e., measurement, recording, etc., of each biometric feature. For example, biometric features may include fingerprints, irises, finger vein patterns containing at least one finger vein, wrist vein patterns containing at least one wrist vein, and facial patterns. In a specific example, fingerprints can be "read" using, for example, a fingerprint scanner embedded in a mobile device. Similarly, irises can be read using an iris scanner, or more generally, an eye scanner.

[0075] Consider a case where a vault system is generated and, therefore unlocked based on, a single biometric reading, such as a fingerprint (note that the term “fingerprint” is used herein to include a thumbprint). Note that this is not limiting, and this instruction generally applies when multiple biometric readings are used.

[0076] The Alice 103a allows you to scan your own fingerprints using, for example, your mobile phone or laptop. The Alice 103a, or more precisely, the Alice device, identifies multiple biometric features within the fingerprint.

[0077] Figure 3 shows exemplary biofeatures that may be present in a fingerprint, such as ridges, dots, borders, and islands. An alignment reference frame overlaid on the fingerprint is also shown. In this example, the sections are concentric circles, and each concentric circle contains one or more features.

[0078] It should be noted that identifying biological features does not necessarily mean identifying every single feature in a reading, but it is not excluded. For example, in some cases only specific types of biological features are identified. The types of features to be identified can be adapted without loss of generality.

[0079] Using the identified biometric features, Alice 103a generates one or more first biometric vaults. Each first biometric is used to lock its respective first-level secret value. Further as described later, in some embodiments, the first-level secret value may be used, for example, as a seed for deriving a secret key. In other embodiments, a first-level secret value may be used together with other first-level secret values ​​to generate a second secret value, and this second secret value may be used to derive a secret key.

[0080] Each first biometric vault corresponds to a specific biometric feature, such as a loop in a fingerprint. The corresponding biometric feature is referred to below as the target feature of the first biometric vault. In some examples, a first biometric vault may be generated for each biometric feature, or for a specific type of biometric feature, such as only loops.

[0081] Each first biometric vault contains multiple binary data pairs. Each binary data pair contains a first binary value and a second binary value. At least some of the first binary values ​​are generated based on the target biofeature and some or all of the other identified biofeature features. More specifically, at least some of the first binary values ​​are the respective binary representations of the target feature for each of the other identified features (hereinafter referred to as the "first binary representation"). For example, the binary representation of the target feature for the first other feature, the binary representation of the target feature for the second other feature, and so on.

[0082] These first binary representations are relative and unaligned representations of the manutshas (relative to each other). As will be discussed later, for each vault, it is preferable that the data pairs within each vault are generated after first applying a random function transformation to the manutshas.

[0083] Therefore, at least some of the second binary values ​​are paired with their respective first binary representations. These second binary values, paired with their respective first binary representations, can be used to reconstruct the first-level secret value locked by the first biometric vault. Reconstructing the first-level secret value requires at least a threshold number of second binary values. In some examples, all of these second binary values ​​are required.

[0084] As will be described in more detail later, some of the first binary values ​​may be binary representations of simulated biofeatures. Biofeatures are features that do not actually exist in the biofeatures; that is, they are artificially generated and do not exist as part of the user's actual biometric characteristics. These particular binary representations are referred to below as "simulated binary representations" to distinguish them from the first binary representations generated based on biofeatures that actually exist in the biometric readings. Each simulated biometric representation takes the same format as the first biofeatures, so they are indistinguishable when stored in the vault. Furthermore, each simulated biometric representation is paired with a simulated second binary value. The simulated second binary value cannot be used to reconstruct the first-level secret value. In addition, if a simulated second binary value is used when attempting to reconstruct the first-level secret value, the attempt will not yield the first-level secret value; that is, an incorrect value will be derived. Note that simulated biofeatures are not required in all cases.

[0085] In these cases, all vaults contain such simulated binary representations, preferably with at least 30 actual binary representations and 300 simulated binary representations in a ratio of 1:10 within the vault. The simulated binary representations are based on the relative positions of functionally transformed actual biofeatures to the simulated features (simulated features are added iteratively such that the minimum distance between biofeatures (either actual or simulated) exceeds a physical threshold for recognizing them as different features). The actual binary representations are based on the relative positions of functionally transformed actual biofeatures to other actual features.

[0086] Alice 103a generates one or more blockchain transactions. Each blockchain transaction is used to store its respective vault on blockchain 150, or each slice (i.e., partition) of the vault on the blockchain. In some cases, Alice 103a includes each first biometric vault within a blockchain transaction and sends the blockchain transaction(s) to blockchain network 106. In other cases, Alice 103a divides one or more first biometric vaults into two or more slices, and then includes each slice in a different blockchain transaction. These transactions are then sent to blockchain network 106.

[0087] In other embodiments, Alice 103a generates a second biometric vault for each first biometric vault. Each second biometric vault contains each first biometric vault. As described later, each second biometric vault may contain further information. A second biometric vault, or a slice of a second biometric vault, is included in a different transaction before being sent to the blockchain network 106.

[0088] In some cases, each first or second biometric vault is encrypted before being included in its respective transaction. If the first or second biometric vault is divided into slices, those slices may also be encrypted.

[0089] For each first biometric vault, each first binary representation may be generated based on each first vector, where each first vector is generated based on each other identified biometric feature. The first vector describes the target biometric feature for another identified feature. For example, the first vector may describe the relative position, relative angle, and / or relative orientation of the target feature for another identified feature. In some cases, each second binary representation of the relative position, relative angle, and / or relative orientation of the target feature for another identified feature is generated, and each second binary representation(s) is used to generate each first binary representation. For example, the second binary representations may be concatenated or otherwise combined.

[0090] The first binary representation can be generated using an alignment-free binarization technique. Such a technique does not consider the alignment of each manutsier with respect to a central reference frame. Instead, it considers manutsier features relative to other manutsier features, as shown in Figure 4. Figure 4(LHS) shows a manutsier feature surrounded by other manutsier features, and Figure 4(RHS) shows the position of the manutsier relative to other manutsier features.

[0091] Maneusha M i And so, Manusha M j In relation to (N M -1) pair polarity vectors

number

number

number

number

number

number

number

number

number

[0092] The first binary representation above is the first vector v ij It is generated based on the following. In some embodiments, the first binary representation is generated based on a transformed version of the first vector. In these embodiments, each transformation is applied to the first vector to generate the transformed first vector. The transformations are applied to remove correlations between biofeatures, i.e., between the target biofeatures and each other identified features. For example, each transformed first vector may contain transformed values ​​of the relative position, relative angle, and / or relative orientation of the target feature with respect to each other identified feature.

[0093] The transformed first vector can be generated by applying their respective coordinate and rotation-invariant properties to the values ​​of the (untransformed) first vector. These properties are specific to each target biological feature of each first biometric vault. Additionally or alternatively, the values ​​of the first vector may be transformed using pseudo-randomly generated transformed values.

[0094] More specifically, the function transformation is B i Prevents correlation between them, binary structure

number

Number

[0095] Coordinate-invariant and rotation-invariant properties

Number

Number

Number

Number

[0096] As described above, each first biometric vault may contain one or more binary representations of simulated biofeatures. Each simulated feature may be assigned a second vector having the same format as the first vector. The second vectors are assigned such that they minimize the distance from each actual feature. Preferably, there are more simulated features than actual identified features (recall that identified features do not necessarily include all features present in the read).

[0097]

number

[0098] Next, the generation of the second binary value is described. Preferably, the first level secret value is a pseudorandom value. The first level secret value is divided into at least a first threshold number of elements. Preferably, the first level secret value is divided into a number of elements exceeding the first threshold number. Each element of the first level secret value is used as a coefficient of the first polynomial function. For a first binary representation of an actual biofeature, the second binary value paired with a given first binary representation is generated by evaluating the first polynomial function using that first binary representation. Then, if at least a threshold number of second binary values ​​paired with the first binary representation are available, the first level secret value can be reconstructed using polynomial interpolation.

[0099] More specifically, Alice103a is a random string S i Generate and then S i =s i,n-1 ||…||s i,0 n of length l such that <N M It can be divided into individual segments. Then, S i polynomial p i (x=s i,n-1 xn-1 +···+s i,0 x 0 Encode it.

number

[0100] In an example where the vault system comprises multiple first biometric vaults, each locking its own first-level secret value, those first-level secret values ​​(e.g., some or all of them) can be used to unlock a second secret value. The second secret value is preferably a pseudo-random value. The second secret value is divided into at least a second threshold number of elements. Preferably, the second secret value is divided into more than a second threshold number of elements. Each element of the second secret value is used as a coefficient of a second polynomial function. The second polynomial value is evaluated using each first-level secret value to produce its respective result. The respective result is then stored in each second biometric vault, each containing its respective first biometric vault with its respective first-level secret value. Thus, using at least a second threshold number of first-level secret values ​​and their respective results, it is possible to reconstruct the second secret value through polynomial interpolation.

[0101] Alice103a can generate a random string S, where S is a binary string. i The number L is sufficient to recover S. Then S = ( L Divide S into (L+1) segments such that s||...||0s, and each S i In this case, the polynomial p(x) = L sx L +…+0sx 0 Evaluate.

number

number

[0102] The techniques described herein achieve the dual objectives mentioned above: the generated seeds are not stored, making them user-friendly to reproduce, and there are no limitations on the size of the seed entropy.

[0103] Each vault in the vault system is biometrically locked and can only be unlocked by an intended user. Each vault encrypts a different set of binarized biometric features. Such sets may include both true and simulated features. Preferably, the number of simulated features is significantly larger, and there are more true features than are sufficient to unlock the corresponding vault. In response to a live read from the user, if a sufficient number of biometric features in the vault match, the corresponding vault is unlocked.

[0104] Unlocking the vault means that a random binary string (the first-level secret value) is recovered through polynomial interpolation. This string can be used as a partial clue to generate (or regenerate) the seed (the second-level secret value).

[0105] The vault system contains more vaults than are needed to (re)generate the seed. If a sufficient number of vaults are unlocked in response to live biometric reads from users, the seed is recovered by polynomial interpolation. The cues and seed are generated as PRNG byte sequences, and the seed can be of arbitrary length. Vaults within the system can be randomly distributed among the OP_RETURN outputs of blockchain transactions. This technique also provides efficient vault expiration and replacement.

[0106] In some embodiments, Alice 103a may generate a master private key and derive one or more auxiliary keys from that master private key. For example, Alice may generate an HD wallet. In some cases, Alice 103a may generate a master private key and auxiliary key(s) for each of the first and second vaults.

[0107] Each second biometric vault can be encrypted with one of the auxiliary keys; for example, each second biometric vault can be encrypted using a different auxiliary key, one from each HD wallet.

[0108] Similarly, each transformation value used to transform multiple first vectors associated with each target feature could be one of the auxiliary keys, for example, a different auxiliary key for each respective transformation value. That is, when generating each first biometric vault, each auxiliary key from each HD wallet could be used as a transformation value.

[0109] Furthermore, each blockchain transaction(s) used to record each second vault on the blockchain may have available output locked to the respective public key corresponding to the respective auxiliary key. For example, each transaction containing each second biometric vault may be locked to the public key corresponding to one HD wallet, and different transactions containing different second biometric vaults may be locked to the public keys corresponding to different HD wallets. If the second biometric vault is divided into slices, with one slice per transaction, those transactions may be locked to the same public key or to different public keys.

[0110] As a specific example, the first biovault

number

number

number

[0111] The BioVault system has a maximum capacity of N M Individual Vaults i (1≦i≦N) M ). Complete the following steps to enable the system to be statically illustrated.

number

[0112] Once the vault system is generated, the vault is distributed among the OP_RETURN outputs of blockchain transactions. Templates for these transactions are then introduced. Once the vault system is registered on-chain, it can be used at any time. In response to a live read from a user, the corresponding transaction is accessed, the vault is then unlocked off-chain, and an arbitrary high-entropy PRNG seed S is reconstructed (interpolated). The seed S is a concatenation of the parameters of a polynomial p. A biometric master key for a new biometric wallet is derived from S and then discarded. This can be reconstructed at any time in response to another live biometric read from the same user.

[0113] Transaction templates are constructed as follows: The template includes one P2PKH output and one OP_RETURN output. Vault i,sk When it is generated, the OP_RETURN output is, here, the encrypted Vault i,sk Record it. • P2PKH output is Vault i,sk Used for expiration. While this output is unused, Vault i,sk It is active and used when generating / rebuilding seeds for biometric wallets. • When P2PKH output is used, Vault i,sk It will become inactive. • A new vault can be registered as part of the vault system.

[0114] While processing live biometric reads from users offline, the biometric algorithm in the background partially constructs transaction TxIDs, excluding OP_RETURN data. i (1≦i≦N M ) generates. Observed manutsha features are transformed and binarized, Vault i,sk Once generated, the partially constructed transaction is populated offline. Figure 9 shows an exemplary transaction. The transaction is then broadcast to the blockchain network 106. The order in which they are recorded on-chain does not affect the functionality of the vault system.

[0115] Each registration / revocation transaction TxID i This is a supplementary wallet. iIt can be generated using the following: Public and private keys (hardened and unhardened keys) from different levels and branches of the auxiliary wallet's key tree are used when generating a transaction. Note that even if the auxiliary wallet is compromised or a single vault is compromised, the bioLockseed will not be compromised, and the bioVault system will continue to function due to the redundancy and resilience of its structure.

[0116] Those skilled in the art will be familiar with the structure of HD wallets. i Keys at different levels and different branches

number

number

number

[0117] Vault i Before binarizing, Manufacturer M i from

number

[0118] As mentioned, each second biometric vault can be divided into slices. i This can be represented by a unit vault slice.

number

[0119] Next, as shown in Figure 9, Vault i Instead of one transaction per vault, the vault can handle up to one transaction per transaction.

number

number

[0120] Figures 11 and 12 illustrate similar transactions when some of the vaults in the vault system are generated based on Alice's biometric characteristics, and some of the vaults in the system are generated based on the characteristics of a different user, e.g., Carl 103c.

[0121] Figure 13 outlines how Alice 103a records a second-level secret on-chain. Figure 15 shows a similar method, except that at least a portion of the vaults in the system are generated by Carl 103c. In both cases, each user provides their respective live biometric reads used to generate their respective sets of biometric vaults. The biometric vaults are recorded on the blockchain. In the example in Figure 15, reads from both Alice 103a and Carl 103c are required to reconstruct the shared second-level secret.

[0122] Alice 103a may later repeat some of the same steps described above to unlock one or more vaults, for example, to reconstruct one or more first-level secret values ​​and optionally second secret values. This process is shown in Figure 14. Alice 103a may scan Alice's fingerprint, in response to which multiple biometric features are identified and from which a first binary representation of each candidate is generated. First binary representations that match the candidate representations are then identified and stored in the first vault. Second binary values ​​paired with those first binary representations are used to reconstruct the first-level secret values ​​using polynomial interpolation. The process may be repeated for multiple first vaults to reconstruct the second secret values.

[0123] In some embodiments, Alice 103a provides two or more biometric readings. Some biometric vaults may be generated based on one reading, and some biometric vaults may be generated based on other readings. In some examples, the readings are of the same biometric characteristic, for example, two or more fingerprints. In other examples, different biometric characteristics, for example, a fingerprint and an iris, or a fingerprint and a facial pattern, may be used.

[0124] In some embodiments, both Alice 103a and another user, for example Bob 103b, provide one or more of their respective biometric readings. This can be used to generate a shared vault system, for example, some vaults are generated using Alice's readings, and some vaults are generated using Bob's readings. In these examples, both Alice 103a and Bob 103b need to provide their respective readings to reconstruct a second secret value.

[0125] Note that in some cases, a given reading may consist of several instances of the same reading. For example, Alice's same fingerprint may be scanned multiple times to improve the accuracy of the reading.

[0126] conclusion Other variations or uses of the disclosed techniques may become apparent to those skilled in the art once the disclosures herein are given. The scope of this disclosure is not limited by the embodiments described herein, but is limited only by the appended claims.

[0127] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any above references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104 described above.

[0128] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions and not all of them. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (it should be recalled that these entities are not considered nodes of the preferred Bitcoin network 106).

[0129] In an unfavorable embodiment of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150, and not all of them. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or propagate those blocks 151 to other nodes.

[0130] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0131] It will be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs may be provided by any one or more of the following statements.

[0132] Statement 1. A computer implementation method for storing a biometric vault system on a blockchain, wherein the biometric vault system comprises one or more biometric vaults, each biometric vault locking its respective secret value, and the method comprises the steps of obtaining at least one biometric reading, identifying a plurality of biometric features from at least one biometric reading, and generating one or more first biometric vaults, each first biometric vault corresponding to each target biometric feature of the plurality of biometric features, each containing a plurality of binary data pairs, each data pair containing a first binary value and a second binary value, and the first binary value A method comprising the steps of: generating one or more blockchain transactions, each blockchain transaction comprising an output comprising at least a portion of each second biometric vault, each second biometric vault comprising each first biometric vault; and sending one or more blockchain transactions to a blockchain network.

[0133] Statement 2. The method described in Statement 1, wherein at least a portion of each second biometric vault is encrypted with its respective encryption key.

[0134] Statement 3. The method according to Statement 1 or Statement 2, wherein at least a portion of each second biometric vault is a complete second biometric vault.

[0135] In other words, the complete second biometric vault is stored within a single output of the transaction.

[0136] Statement 4. The method according to any preceding statement, comprising the step of determining a plurality of respective first vectors for each first biometric vault and each target biofeedback, wherein each first vector defines a target biofeedback for each other identified biofeedback, and each respective first binary representation is generated based on each respective first vector.

[0137] Statement 5. The method according to Statement 4, wherein each first vector includes the respective values ​​for one, some, or all of the relative distance, relative angle, and / or relative orientation of the target biofeed to each other identified biofeed.

[0138] Statement 6. The method according to Statement 5, wherein each first binary representation is based on the respective second binary representation of one, some, or all of the relative distance, relative angle, and / or relative orientation of the target biofeed to each other identified biofeed.

[0139] Statement 7. For each target biofeedback feature, the method comprises the step of applying a respective first transformation to each value of each respective first vector, wherein each first transformation is configured to remove the correlation between the target biofeedback feature and each other identified biofeedback feature, and each first binary representation is based on the respective transformed values, the method of Statement 4 or any statement subordinate thereto.

[0140] Statement 8. The method according to Statement 7, wherein for each target biofeedback feature, the respective first transformation is configured to eliminate the correlation described above by transforming the distance and / or angle of each target biofeedback feature to each other identified biofeedback feature.

[0141] Statement 9. The method described in Statement 8, wherein the relative distance between each target biological feature is transformed as a function of their respective coordinates and rotation-invariant properties.

[0142] Statement 10. The method according to Statement 8 or Statement 9, wherein the relative angles of each target biological feature are transformed as a function of each pseudo-randomly generated transformed value.

[0143] Statement 11. For each first biometric vault, at least some of the first binary values ​​are the respective simulated binary representations of the respective simulated biofeatures, where the simulated biofeatures are features not present in the biometric readings, and each second binary value paired with each simulated binary representation is the respective simulated binary value, as described in any preceding statement.

[0144] Simulated binary values ​​do not reveal the information needed to reconstruct the first-level secret value. Furthermore, using simulated binary values ​​to attempt to reconstruct the first-level secret value will result in an inaccurate first-level secret value.

[0145] Statement 12. The method according to Statement 11, comprising the step of determining, for each first biometric vault, each second vector for each of the respective simulated biofeatures, such that the respective minimum distance between each of the respective first vectors and each of the respective second vectors exceeds a predetermined threshold, wherein each second binary representation is generated based on each second vector.

[0146] Statement 13. The method described in Statement 11 or Statement 12, wherein for each first biometric vault, the total number of simulated biofeatures is greater than the total number of biofeatures.

[0147] Statement 14. For each first biometric vault, the first-level secret value is a pseudo-randomly generated value as described in any preceding statement.

[0148] Statement 15. The method according to any preceding statement, comprising the step of, for each first biometric vault, dividing each first-level secret value into at least a first threshold number of elements, wherein each first-level secret value is encoded into each first polynomial function, the coefficients of each first polynomial function are each element of the threshold number of elements, and each second binary value paired with each first binary representation is generated by evaluating the first polynomial function using each first binary representation.

[0149] The first-level secret value can be reconstructed via polynomial interpolation using a second binary value of a threshold number paired with the first binary representation.

[0150] Statement 16. The method according to any preceding statement, comprising the step of generating a plurality of first biometric vaults.

[0151] Statement 17. The method of Statement 16, as dependent on Statement 7, wherein a different first transformation is applied to generate at least one of a plurality of biometric vaults.

[0152] Statement 18. A method according to Statement 16 or any statement subordinate thereto, wherein a second threshold number of first-level secret values ​​is required to generate a second-level secret value.

[0153] The second-level secret value can be reconstructed via polynomial interpolation using the first-level secret value of a threshold number.

[0154] Statement 19. The second-level secret value is a pseudo-randomly generated value, as described in Statement 18.

[0155] Statement 20. The method according to Statement 18 or Statement 19, comprising the step of dividing each second-level secret value into at least a second threshold number of elements, wherein the second-level secret value is encoded into a second polynomial function, the coefficients of the second polynomial function are the elements of each of the second threshold number of elements, and the second-level secret value can be reconstructed by evaluating the second polynomial function in each of the first-level secret values.

[0156] Statement 21. A method of any preceding statement, comprising the step of generating one or more secret keys based on a first-level secret value.

[0157] One or more secret keys can form part of a hierarchical deterministic key structure.

[0158] Statement 22. A method of statement 18 or any statement subordinate thereto, comprising the step of generating one or more secret keys based on a second-level secret value.

[0159] One or more secret keys can form part of a hierarchical deterministic key structure.

[0160] Statement 23. The method of any preceding statement, wherein each of one or more blockchain transactions includes its respective first available output, and the method includes the step of revoking at least a portion of each second biometric vault contained within each blockchain transaction by using its respective available output.

[0161] Statement 24. The method of any preceding statement, comprising the steps of obtaining a master private key for each first biometric vault and generating one or more auxiliary private keys based on each master private key.

[0162] Statement 25. The method of Statement 24, when dependent on Statement 2, wherein the first of one or more auxiliary keys is used as the respective encryption key.

[0163] Statement 26.1 The second of the three auxiliary keys is a conversion value, in the manner of Statement 23 or Statement 24 when it is dependent on Statement 10.

[0164] Statement 27. Each available output is locked to the respective public key corresponding to each of the auxiliary keys of one or more auxiliary keys, as described in any of statements 24 through 26, which are dependent on statement 23.

[0165] Statement 28. The method described in any of statements 24 to 27, wherein each master private key and each one or more auxiliary keys form part of each hierarchical deterministic key structure.

[0166] Statement 29. The method according to Statement 26, comprising the steps of generating a second value based on each of the transformed values, and evaluating a third polynomial function in the second value to generate a third value, wherein the coefficients of the second polynomial function are generated in a pseudo-random manner, and each second biometric vault contains the second polynomial evaluated in the respective first-level secret value and the third value.

[0167] Statement 30. At least one biometric reading is Fingerprint reading value, Iris readings, Finger vein pattern readings, Wrist vein pattern readings, Skin structure patterns, and / or Face patterns A method of any preceding statement that includes at least one of the following.

[0168] Statement 31. A computer implementation method for unlocking one or more biometric vaults of a biometric vault system, wherein the biometric vault system is generated in accordance with any of the methods described in Statements 1 to 30, the method comprising: obtaining at least one candidate biometric reading; identifying a plurality of biometric features from at least one biometric reading; generating a plurality of respective candidate binary representations of each of the plurality of biometric features; obtaining one or more second biometric vaults from a blockchain, each second biometric vault comprising each first biometric vault, each first biometric vault comprising a plurality of respective first binary values ​​paired with each second binary value; determining, for each first biometric vault, each first binary value of at least a threshold number corresponding to each of the plurality of candidate binary representations; obtaining a second binary value of a threshold number paired with each of the first binary representations of the first threshold number; and reconstructing a first-level secret value based on each of the second binary values ​​of the first threshold number.

[0169] Statement 32. The method according to Statement 1, comprising the steps of performing the above determination, acquisition, and reconstruction for at least a first biometric vault with a different second threshold number in order to reconstruct a first-level secret value for a second threshold number, and reconstructing a second-level secret value based on the first-level secret value for a second threshold number.

[0170] Statement 33. The method according to Statement 31 or Statement 32, comprising the steps of generating one or more secret keys based on a first-level secret value and / or generating one or more secret keys based on a second-level secret value.

[0171] In some embodiments, one of the generated private keys can be a master private key, and the method can include generating one or more private keys of a hierarchical deterministic key structure.

[0172] The method can include using at least one of the generated private keys to generate a signature based on a message.

[0173] The message can include at least a portion of a blockchain transaction.

[0174] The method can include generating respective public keys corresponding to each of the generated private keys and using each public key to encrypt data within a blockchain transaction.

[0175] In some embodiments, the step of obtaining one or more biometric readings can include obtaining a plurality of biometric readings.

[0176] In some embodiments, each of the plurality of biometric readings can be a biometric reading from the same user. In other embodiments, at least two of the plurality of biometric readings can be respective biometric readings from different respective users.

[0177] When biometric readings from two users are used to generate a seed (shared seed), the shared seed can be used to generate one or more shared private keys, such as a shared HD key structure. A seed generated based on biometric readings (plural) from one user can be used to generate the master private key of an HD key structure, and a seed generated based on biometric readings (plural) from different users can be used to generate a chain code for the keys of an HD key structure.

[0178] Statement 34. Computer equipment comprising memory having one or more memory units and a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code is configured to perform the method described in any of statements 1 to 33 when it is on the processing unit.

[0179] Statement 35. A computer program embodied on computer-readable storage, configured to perform any method described in any of statements 1 to 33 when executed on one or more processors.

Claims

1. A computer implementation method for storing a biometric vault system on a blockchain, wherein the biometric vault system comprises one or more biometric vaults, each biometric vault locks its respective secret value, and the method is The steps include obtaining at least one biometric reading, The steps include identifying multiple biological features from at least one biometric reading, A step of generating one or more first biometric vaults, each first biometric vault corresponding to each target biofeature of the plurality of biofeatures, each comprising a plurality of binary data pairs, each data pair comprising a first binary value and a second binary value, at least some of the first binary values ​​being first binary representations of the target biofeatures for each other biofeatures of the identified biofeatures, and at least a first threshold number of the second binary values ​​paired with each of the first binary representations are required to reconstruct each first level secret value, A step of generating one or more blockchain transactions, wherein each blockchain transaction includes an output that includes at least a portion of a second biometric vault, each second biometric vault includes a first biometric vault, and each of the one or more blockchain transactions includes its available output. The steps include sending one or more blockchain transactions to the blockchain network, The steps include revoking at least a portion of each second biometric vault contained within each blockchain transaction by using the respective available outputs, A method that includes this.

2. The method according to claim 1, wherein at least a portion of each of the second biometric vaults is encrypted with the respective encryption key.

3. The method according to claim 1 or 2, wherein at least a portion of each of the second biometric vaults is a complete second biometric vault.

4. The method according to any one of claims 1 to 3, comprising the step of determining a plurality of respective first vectors for each first biometric vault and each target biofeedback, wherein each first vector defines the target biofeedback for each other identified biofeedback, and each respective first binary representation is generated based on the respective first vector.

5. The method according to claim 4, wherein each first vector comprises values ​​for one, some, or all of the relative distance, relative angle, and / or relative orientation of the target biofeed to each of the other identified biofeeds.

6. The method according to claim 5, wherein each first binary representation is based on each second binary representation of one, some, or all of the respective values ​​of the relative distance, relative angle, and / or relative orientation of the target biofeed to each of the other identified biofeeds.

7. For each target biological characteristic, the above method is: A step of applying a first transformation to each value of each of the first vectors, wherein each first transformation is configured to remove the correlation between the target biofeature and each of the other identified biofeature, and each first binary representation is based on the transformed values, step The method according to claim 4, including the method described in claim 4.

8. The method according to claim 7, wherein, for each target biological feature, the respective first transformation is configured to eliminate the correlation by transforming the distance and / or angle of the respective target biological feature to the respective other identified biological feature.

9. The method according to claim 8, wherein the relative distance between each of the target biological features is transformed as a function of their respective coordinates and rotation-invariant properties.

10. The method according to claim 8 or 9, wherein the relative angles of each of the target biological features are transformed as a function of the respective pseudo-randomly generated transformation values.

11. The method according to any one of claims 1 to 10, wherein for each first biometric vault, at least some of the first binary values ​​are the respective simulated binary representations of the respective simulated biological features, the simulated biological features being features not present in the biometric readings, and the respective second binary values ​​paired with the respective simulated binary representations are the respective simulated binary values.

12. The method according to claim 11, comprising the step of determining, for each first biometric vault, a second vector for each of the respective simulated biological features, such that the minimum distance between each of the respective first vectors and each of the respective second vectors exceeds a predetermined threshold, wherein each of the respective second binary representations is generated based on the respective second vectors.

13. The method according to claim 11 or 12, wherein, for each first biometric vault, the total number of simulated biological features is greater than the total number of biological features.

14. The method according to any one of claims 1 to 13, wherein for each first biometric vault, the first level secret value is a pseudo-randomly generated value.

15. For each first biometric vault, A step of dividing each of the first level secret values ​​into at least the first threshold number of elements, wherein each first level secret value is encoded into a first polynomial function, the coefficients of each of the first polynomial functions are the elements of the first threshold number, and each of the second binary values ​​paired with each of the first binary representations is generated by evaluating the first polynomial function using each of the first binary representations. The method according to any one of claims 1 to 14, including the method described in any one of claims 1 to 14.

16. The method according to any one of claims 1 to 15, comprising the step of generating a plurality of first biometric vaults.

17. The method according to claim 16, as dependent on claim 7, wherein a different first transformation is applied to generate at least one of the plurality of biometric vaults.

18. The method according to claim 16, wherein a second threshold number of the first-level secret values ​​is required to generate a second-level secret value.

19. The method according to claim 18, wherein the second-level secret value is a pseudo-randomly generated value.

20. A step of dividing each of the aforementioned second-level secret values ​​into at least the elements of the second threshold number, wherein the second-level secret values ​​are encoded into a second polynomial function, the coefficients of the second polynomial function are the elements of the elements of the second threshold number, and the second-level secret values ​​can be reconstructed by evaluating the second polynomial function in each of the respective first-level secret values. The method according to claim 18 or 19, including the method described in claim 18 or 19.

21. The method according to any one of claims 1 to 20, comprising the step of generating one or more secret keys based on the first-level secret value.

22. The method according to claim 18, comprising the step of generating one or more secret keys based on the second-level secret value.

23. For each first biometric vault, Steps to obtain each master private key, The steps include generating one or more auxiliary secret keys based on each of the aforementioned master secret keys, and The method according to any one of claims 1 to 22, including the method described in any one of claims 1 to 22.

24. The method according to claim 23, as dependent on claim 2, wherein the first auxiliary key among the one or more auxiliary keys is used as the respective encryption key.

25. The method according to claim 23, as opposed to claim 10, wherein the second auxiliary key among the one or more auxiliary keys is the conversion value.

26. The method according to any one of claims 23 to 25, wherein each available output is locked to the respective public key corresponding to each of the one or more auxiliary keys.

27. The method according to any one of claims 23 to 26, wherein each of the master secret keys and each of the one or more auxiliary keys forms part of the respective hierarchical deterministic key structure.

28. A step of generating a second value based on each of the aforementioned converted values, A step of evaluating a third polynomial function in the second value in order to generate a third value, wherein the coefficients of the second polynomial function are generated in a pseudo-random manner. Includes, Each second biometric vault includes the second polynomial function evaluated with the respective first-level secret values ​​and the third value, The method according to claim 25.

29. The at least one biometric reading is, Fingerprint reading value, Iris readings, Finger vein pattern readings, Wrist vein pattern readings, Skin structure patterns, and / or Face patterns The method according to any one of claims 1 to 29, comprising at least one of the following.

30. A computer implementation method for unlocking one or more biometric vaults in a biometric vault system, wherein the biometric vault system is generated according to the method described in any one of claims 1 to 29, and the method is A step of obtaining at least one candidate biometric reading, The steps include identifying multiple biological features from at least one biometric reading, The steps include generating multiple candidate binary representations for each of the multiple biological features, A step of obtaining one or more second biometric vaults from the blockchain, each second biometric vault comprising each first biometric vault comprising a plurality of each first binary value paired with each second binary value, For each first biometric vault, The steps include determining a first binary value for each of the plurality of candidate binary representations, each of which has at least a threshold number of corresponding values, A step of obtaining the second binary value of a threshold number that is paired with each of the first binary representations of the first threshold number, A step of reconstructing a first-level secret value based on each of the second binary values ​​of the first threshold number. Computer implementation methods including

31. The steps include performing the determination, acquisition, and reconstruction for at least a first biometric vault with a different second threshold number in order to reconstruct the first level secret value of the second threshold number, The steps include: reconstructing the second level secret value based on the first level secret value of the second threshold number; The method according to claim 1, including the method described in claim 1.

32. The method according to claim 30 or 31, comprising the steps of generating one or more secret keys based on the first level secret value and / or generating one or more secret keys based on the second level secret value.

33. Computer equipment, A memory comprising one or more memory units, A processing apparatus comprising one or more processing units The memory stores code configured to be executed on the processing unit, and the code is configured to perform the method according to any one of claims 1 to 32 when it is on the processing unit. Computer equipment.

34. A computer program implemented on computer-readable storage, configured to perform the method described in any one of claims 1 to 32 when executed on one or more processors.

Images