Identity (ID)-Based Public Key Generation Protocol

Abstract

A computer-implemented method for generating an identity-based encryption key, comprising: obtaining a set of private key shares and a corresponding set of public key shares, where each private key share is generated based on the personal identifier, and at least one of the set of private key shares is generated by a respective one of a set of key-generating parties; generating an identity-based private key based on each of the one or more private key shares; generating a partial identity-based public key, where the partial identity-based public key is generated based on each of the corresponding sets of public key shares; sending the partial identity-based public key to at least one of the set of key-generating parties to generate the identity-based public key; and / or generating the identity-based public key, where the identity-based public key includes the personal identifier and the partial identity-based public key.

Description

Technical Field

[0001] The present disclosure relates to a method for generating a cryptographic key based on a user's identity (ID).

Background Art

[0002] A blockchain refers to a form of a distributed data structure in which a replicated copy of the blockchain is maintained at each of a plurality of nodes within a peer-to-peer (P2P) network. A blockchain includes a chain of data blocks, where each block includes one or more transactions. Each transaction may refer to a preceding transaction in a sequence that may span one or more blocks. Transactions can be submitted to the network to be included in new blocks by a process known as "mining", which involves each of a plurality of mining nodes competing to perform a "proof-of-work", i.e., solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in the block.

[0003] Conventionally, transactions in a blockchain have been used to transfer digital assets, i.e., data that functions as a store of value. However, a blockchain can also be utilized to overlay additional functionality on top of the blockchain. For example, a blockchain protocol may enable the storage of additional user data in the output of a transaction. In recent blockchains, the maximum data capacity storable within a single transaction has increased, allowing for more complex data to be incorporated. For example, this can be used to store electronic documents on a blockchain or even audio or video data.

[0004] Each node in the network can perform any one, two, or all of the three roles of forwarding, mining, and storage. Forwarding nodes propagate transactions throughout the nodes of the network. Mining nodes execute the mining of transactions into blocks. Storage nodes each store their own copy of the mined blocks of the blockchain. To record a transaction on the blockchain, a party sends the transaction to one of the nodes of the network to be propagated. A mining node that receives a transaction can compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor mined into blocks. Assuming that a transaction is validated and thereby accepted onto the blockchain, additional user data remains stored at each of the nodes in the P2P network as an immutable public record.

Summary of the Invention

[0005] Identity-based encryption (IBE) is a public-key cryptosystem that uses a user's identity, such as the user's email address, as the user's public key. The technical problem of IBE is to derive the corresponding secret key from the public key. To overcome this, typically a trusted third-party agency (TTP) is introduced to generate the user's secret key from a master secret key (known only to the TTP) and the user's identity. However, this solution causes the problem that the TTP has knowledge of the user's secret key and can thus decrypt messages encrypted with the user's public key.

[0006] According to one aspect disclosed herein, a computer-implemented method for generating an ID-based cryptographic key is provided, the method being executed by a first party having an identifier, the method comprising obtaining a set of secret key shares and a corresponding set of public key shares, wherein each secret key share is generated based on the identifier, and at least one of the set of secret key shares is generated by each one of a set of key generation parties, generating an ID-based secret key based on each of one or more of the secret key shares, generating a partial ID-based public key, wherein the partial ID-based public key is generated based on each of the corresponding set of public key shares, sending the partial ID-based public key to at least one of the set of key generation parties for generating an ID-based public key, and / or generating an ID-based public key, wherein the ID-based public key comprises the identifier and the partial ID-based public key.

[0007] According to another aspect disclosed herein, a computer-implemented method for generating an ID-based cryptographic key is provided, the first party having an identifier, the method being executed by a first key generation party, the method comprising sending a secret key share to the first party, wherein the secret key share is generated based on the identifier and has a corresponding public key share, obtaining a partial ID-based public key, wherein the partial ID-based public key is generated based on the corresponding public key share, generating and / or obtaining an ID-based public key, wherein the ID-based public key is generated based on the partial ID-based public key and the identifier, and generating a first blockchain transaction comprising a first output comprising the ID-based public key.

[0008] Instead of the TTP generating the user's private key, the user (the first party) here undertakes to generate its own private key, at least in part. The user receives one or more private key shares and uses them to generate the private key. Each key generation party, also known as the Private Key Generator (PKG), only has knowledge of the private key shares it generated itself, so a given PKG cannot obtain the user's complete private key. The private key shares can be combined to form the user's private key, or the user can additionally contribute private key shares to the private key. The PKG corresponding to the TTP becomes semi-trusted in the sense that only the user knows the user's private key unless the holders of the private key shares collude. If the user is also a holder of a private key share, it can completely dispense with trust in any third party, more precisely in the holders of the other private key shares.

[0009] One, some, or all of the PKGs generate an Identity-Based Public Key (i.e., an IBE key) and store the IBE key on the blockchain in a blockchain transaction (hereinafter referred to as a "Validity Check Transaction" (VCT)). The VCT can be viewed in the Unspent Transaction Output (UTXO) set of the blockchain, whereby a party can view the IBE key and check whether the IBE is still valid. Essentially, the UTXO set functions as a whitelist of valid keys. If the IBE key, or more precisely the corresponding private key, needs to be compromised or invalidated for some other reason, the user and / or the PKG can use the VCT to remove the IBE key from the UTXO set. When a party then wants to check whether the IBE key is valid, it will no longer find the IBE key in the UTXO set, from which it interprets that the IBE key is invalid. Similarly, the IBE can be updated by sending a new VCT to the blockchain using a previous VCT. Using the VCT output provides an efficient method for immediate key invalidation.

Brief Description of the Drawings

[0010] To aid understanding of embodiments of the present disclosure and to show how such embodiments may be implemented, reference is made, by way of example only, to the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8a

Figure 8b

Embodiments for Carrying Out the Invention

[0011] Overview of an Exemplary System FIG. 1 shows an exemplary system 100 for generally implementing a blockchain 150. System 100 includes a packet switching network 101, typically a wide area internetwork such as the Internet. The packet switching network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet switching network 101. Each node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each node 104 includes a processing device having one or more processors, such as one or more central processing units (CPUs), accelerator processors, application specific processors, and / or field programmable gate arrays (FPGAs). Each node also includes a memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may comprise one or more memory units using one or more memory media, such as magnetic media like a hard disk, electronic media such as a solid state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0012] The blockchain 150 includes a chain of data blocks 151, and each copy of the blockchain 150 is maintained at each of a plurality of nodes within the P2P network 160. Each block 151 within the chain includes one or more transactions 152, and 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 typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of digital assets belonging to a user 103, where the output is cryptographically locked (requiring the user's signature to be unlocked and thereby redeemed or used). Each input refers to an output of a previous transaction 152, thereby linking the transactions.

[0013] At least some of the nodes 104 assume the role of forwarding nodes 104F that forward and thereby propagate the transactions 152. At least some of the nodes 104 assume the role of miners 104M that mine the blocks 151. At least some of the nodes 104 assume the role of storage nodes 104S (sometimes referred to as "full copy" nodes), each of which stores a respective copy of the same blockchain 150 in its respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 that are waiting to be mined into a block 151. A given node 104 can be a forwarding node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0014] In a given current transaction 152j, the input (or each input) includes a pointer that references 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, the preceding transaction can be any transaction within the pool 154 or any block 151. The preceding transaction 152i needs to exist and be verified for validity for the current transaction to be valid, but the preceding transaction 152i does not necessarily need to exist when the current transaction 152j is created or when it is sent to the network 106. Thus, "preceding" as used herein refers to the one preceding in the logical sequence linked by the pointer and does not necessarily refer to the creation time or the sending time in the time sequence, and thus does not necessarily exclude the possibility that transactions 152i, 152j are created or sent in an arbitrary order (see the following explanation regarding orphan transactions). The preceding transaction 152i is also referred to as the antecedent transaction or the predecessor transaction.

[0015] The input of the current transaction 152j also includes the signature of user 103a whose output of the preceding transaction 152i is locked. Next, the output of the current transaction 152j can be cryptographically locked to the new user 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user 103b as defined in the output of the current transaction 152j. In some cases, transaction 152 can have multiple outputs to split the input amount among multiple users (one of whom can be the original user 103a to give change). In some cases, the transaction can 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.

[0016] The above can be referred to as an "output-based" transaction protocol and is also sometimes called an unspent transaction output (UTXO) type protocol (where outputs are called UTXOs here). Instead of being defined by any one number stored in the blockchain, a user's total balance requires a special "wallet" application 105 to reconcile the values of all of that user's UTXOs scattered throughout many different transactions 152 within the blockchain 151.

[0017] An alternative type of transaction protocol can be called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referring to the absolute account balance, rather than by referring to the UTXO of previous transactions in a series of past transactions. The current state of all accounts is stored and constantly updated by the miner, separate from the blockchain. In such a system, transactions are ordered using the transaction tally of the account (also called the "position") being executed. This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, any optional data fields in the transaction can also be signed. This data field can indicate the previous transaction, for example, if the previous transaction ID is included in the data field.

[0018] If user 103 wishes to establish a new transaction 152j using any type of transaction protocol, the user sends the new transaction from the user's computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is typically a server or data center but could in principle be another user terminal). This node 104 checks whether the transaction is valid according to the node protocol applied at each of the nodes 104. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 and together form the transaction model. The node protocol typically requires the node 104 to check that the cryptographic signature within the new transaction 152j matches the expected signature that depends on the previous transaction 152i within the ordered sequence of transactions 152. In the output-based case, this may include checking that the user's cryptographic signature included in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152i that the new transaction uses, which typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i that the input of the new transaction indicates. In some transaction protocols, the conditions may be at least partially defined by custom scripts included in the input and / or output. Alternatively, it may be fixed by the node protocol alone or by a combination of these. In any case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes of the nodes 104 within the P2P network 106. At least some of these nodes 104 also function as forwarding nodes 104F, apply the same test according to the same 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 node 104.

[0019] In the output-based model, the definition of whether a given output (e.g., UTXO) has been used is whether it has been validly redeemed by an input of another previous transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transition 152i that it attempts to use or redeem has not yet been used / redeemed by another valid transaction. Similarly, if not valid, transaction 152j is neither propagated nor recorded on the blockchain. This prevents double-spending where a user attempts to use the output of the same transaction multiple times. On the other hand, the account-based model prevents double-spending by maintaining account balances. Here too, since the transaction order is defined, the account balance is always in a single defined state.

[0020] In addition to validity verification, at least some of the nodes 104M also compete to first create a block of transactions in a process known as mining, which is supported by "proof of work". At the mining node 104M, new transactions are added to a pool of valid transactions that have not yet appeared in the block. The miner then competes to assemble a new valid block 151 of transactions 152 from the transaction pool 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with and hashed with the transaction pool 154, the output of the hash meets a predetermined condition. For example, the predetermined condition could be that the output of the hash has a specific predetermined number of leading zeros. The characteristic of the hash function is that it has an unpredictable output for its input. Therefore, this search can only be performed by brute force and consumes a significant amount of processing resources at each node 104M attempting to solve the puzzle.

[0021] The minor node 104M that first solves the puzzle publishes this to the network 106 and provides as proof thereof its solution that can later be easily checked by other nodes 104 within the network (it is easy to check that the output of the hash meets the conditions when the solution for the hash is given). The pool 154 of transactions for which the winner has solved the puzzle is then recorded as a new block 151 in the blockchain 150 based on at least some of the nodes 104 that function as storage nodes 104S having checked the solution published by the winner at each such node. The block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. The proof of work, since it requires a great deal of effort to create a new block 151, helps to reduce the risk of double spending, and blocks containing double spending are likely to be rejected by other nodes 104, so the mining nodes 104M are incentivized such that double spending is not included in those blocks. Once created, the block 151 cannot be modified since it is recognized and maintained at each of the storage nodes 104S within the P2P network 106 according to the same protocol. The block pointer 155 also assigns a sequential order to the block 151. The transactions 152 are recorded in the ordered blocks at each of the storage nodes 104S within the P2P network 106, which provides an immutable public ledger of the transactions.

[0022] Note that different miners 104M competing to solve the puzzle at any given time may do so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they started searching for a solution. Whichever miner solves each puzzle first defines which transactions 152 are included in the next new block 151n, and the current pool 154 of unmined transactions is updated. The miners 104M then continue to compete to create blocks from the newly defined unprocessed pool 154, and so on. There is also a protocol for resolving any "forks" that may occur if two miners 104M solve the puzzle within a very short time of each other and conflicting views of the blockchain are propagated. In short, whichever prong of the fork grows the longest becomes the final blockchain 150.

[0023] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a brand new amount of digital assets (as opposed to a normal transaction that transfers a certain amount of digital assets from one user to another). Thus, the winning node is said to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "coinbase" transaction. It automatically forms part of the new block 151n. This reward provides an incentive for miners 104M to participate in the proof-of-work competition. Often, normal (non-coinbase) transactions 152 also specify an additional transaction fee in one of their outputs to further reward the winning miner 104M that created the block 151n in which the transaction was included.

[0024] Due to the computing resources involved in mining, typically, each of at least the miner nodes 104M takes the form of a server including one or more physical server units or the form of an entire data center. Each forwarding node 104M and / or storage node 104S can also take the form of a server or a data center. However, in principle, any given node 104 can take the form of a networked user terminal or a group of user terminals together.

[0025] The memory of each node 104 stores software configured to execute on the processing device of the node 104 to perform its respective one or more roles and process the transaction 152 according to the node protocol. It will be understood that any action attributed to the node 104 herein can be performed by software executed on the processing device of each respective computer device. Also, the term "blockchain" as used herein is generally a generic term referring to this type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0026] Each of the computer devices 102 of the plurality of parties 103 that play the role of consumer users is also connected to the network 101. These function as payers and payees in a transaction, but do not necessarily participate in the mining or propagation of the transaction on behalf of other parties. They do not necessarily execute the mining protocol. 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. It will be understood that there are far more such parties 103 and their respective computer devices 102 that can exist and participate in the system, but for the sake of convenience, they are not shown. Each party 103 can be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice, and the second party 103b is referred to as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob can be replaced with "the first party" and "the second party", respectively.

[0027] The computer device 102 of each party 103 includes a respective processing device including one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 comprises a memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units using one or more memory media, such as magnetic media like hard disks, electronic media like SSDs, flash memories or EEPROMs, and / or optical media like optical disk drives. The memory on the computer device 102 of each party 103 stores software including respective instances of at least one client application 105 configured to execute on the processing device. It will be understood that any action attributed to a given party 103 herein may be performed using software executed on the processing device of the respective computer device 102. The computer device 102 of each party 103 comprises at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

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

[0029] The client application 105 has at least a "wallet" function. This has two main functions. One of these is to enable each user party 103 to create, sign, and send a transaction 152 that will be propagated across the network of nodes 104 and thereby included 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 involves reconciling the amounts defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 to which the party belongs.

[0030] Instances of the client application 105 on each computer device 102 are operably coupled to at least one of the forwarding nodes 104F of the P2P network 106. Thereby, the wallet function of the client 105 can send the transaction 152 to the network 106. The client 105 can also contact one, several, or all of the storage nodes 104 to query the blockchain 150 for any transaction where each party 103 is the recipient (or, in an embodiment, since the blockchain 150 is a public facility that provides trust in transactions through its partial public visibility, actually inspect other parties' transactions in the blockchain 150). The wallet function on each computer device 102 is configured to formulate and send the transaction 152 according to the transaction protocol. Each node 104 runs software configured to validate the transaction 152 according to the node protocol, and in the case of the forwarding node 104F, is configured to forward them to propagate the transaction 152 across the network 106. The transaction protocol and the node protocol correspond to each other, a given transaction protocol proceeds with a given node protocol, and together implement a given transaction model. The same transaction protocol is used for all transactions 152 within the blockchain 150 (although the transaction protocol may allow for different subtypes of transactions therein). The same node protocol is used by all nodes 104 within the network 106 (although this can handle different subtypes of transactions differently according to the rules defined for that subtype, and different nodes can assume different roles and thus implement different corresponding aspects of the protocol).

[0031] As described above, the blockchain 150 includes a chain of blocks 151, each block 151 including a set of one or more transactions 152 created by the proof-of-work process as described above. Each block 151 also includes a block pointer 155 that points to the previously created block 151 in the chain to define a sequential order to the block 151. The blockchain 150 also includes a pool 154 of valid transactions waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the genesis transaction) includes a pointer back to the previous transaction to define an order to the sequence of transactions (note: the sequence of transactions 152 can branch). The chain of blocks 151 goes all the way back to the genesis block (Gb) 153 that was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than a previous transaction.

[0032] When a given party 103, e.g., Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction according to the relevant transaction protocol (using the wallet function within Alice's client application 105). Then, Alice sends the transaction 152 from the client application 105 to one of the one or more forwarding nodes 104F to which Alice is connected. For example, this could be the forwarding node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives a new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for it to be "valid", examples of which will be described in more detail below. In some transaction protocols, the conditions for validity confirmation may be configurable for each transaction by the script included in the transaction 152. Alternatively, the conditions may simply be built-in features of the node protocol or defined by a combination of the script and the node protocol.

[0033] Conditioned upon passing a test for a newly received transaction 152j to be considered valid (i.e., conditioned upon it being "validated"), any storage node 104S that receives transaction 152j adds the newly validated transaction 152 to the pool 154 within the copy of the blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives transaction 152j propagates the validated transaction 152 forward to one or more other nodes 104 within the P2P network 106. Since each forwarding node 104F applies the same protocol, assuming transaction 152j is valid, this means it will be propagated throughout the entire P2P network 106 shortly.

[0034] When recognized in the pool 154 within the copy of the blockchain 150 maintained at one or more storage nodes 104, the miner node 104M begins to compete to solve the proof-of-work puzzle for the latest version of the pool 154 that includes the new transaction 152 (other miners 104M may be attempting to solve the puzzle based on an older view of the pool 154, but whoever reaches it first will define where the next new block 151 ends and where the new pool 154 starts, and ultimately someone will solve the puzzle for the part of the pool 154 that includes Alice's transaction 152j). When proof-of-work is performed on the pool 154 that includes the new transaction 152j, it invariably becomes part of one of the blocks 151 within the blockchain 150. Since each transaction 152 includes a pointer back to the previous transaction, the order of the transactions is also invariably recorded.

[0035] UTXO-based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain 150 (each block 151 contains one or more transactions 152). Hereinafter, it will be described with reference to an output-based or "UTXO" - based protocol. However, this is not limited to all possible embodiments.

[0036] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that contains one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not been redeemed yet). The UTXO specifies the amount of digital assets (a store of value). It may also include, among other information, the transaction ID of the original transaction. The transaction data structure may also include a header 201 that may contain indicators showing the sizes of the input field(s) 202 and the output field(s) 203. The header 201 may also include the ID of the transaction. In an embodiment, the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0037] Note that although each output in Figure 2 is shown as a UTXO, a transaction may additionally or alternatively include one or more unspendable transaction outputs.

[0038] Suppose Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is "Tx 1is labeled "」. This takes the amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx 0 " in Figure 2. Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily mean that Tx 0 is the first transaction in the blockchain 151 or that Tx 1 is the very next transaction in the pool 154. Tx 1 can refer to any preceding (i.e., earlier) transaction that still has an unused output 203 locked to Alice.

[0039] The preceding transaction Tx 0 may already be validity - confirmed and included in the blockchain 150 by the time Alice creates the new transaction Tx 1 , or at least by the time Alice sends it to the network 106. It may already be included in one of the blocks 151 at that time, or still be waiting in the pool 154, in which case it will soon be included in a new block 151. Alternatively, Tx 0 and Tx 1 can be created and sent together to the network 102, or if the node protocol allows buffering of "orphan" transactions, Tx 0 to Tx 1It can even be sent after. As used herein in the context of a transaction sequence, the terms "preceding" and "subsequent" refer to the order of transactions within the sequence defined by the transaction pointers specified within the transaction (such as which transaction refers to which other transaction). They can similarly be replaced with "preceding one" and "subsequent one", or "earlier" and "later", "parent" and "child", etc. This does not necessarily mean the order of their creation, transmission to the network 106, or arrival at any given node 104. Nevertheless, a subsequent transaction (later transaction or "child") that refers to a preceding transaction (earlier transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at node 104 before its parent is considered an orphan. It may be buffered for a specific time or discarded to wait for the parent, depending on the node protocol and / or miner behavior.

[0040] Preceding transaction Tx 0 One of one or more outputs 203 is a specific UTXO labeled herein as 0 including. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a lock script, and the lock script defines the conditions that the unlock script within the input 202 of a subsequent transaction must meet for the subsequent transaction to be validated and thus for the UTXO to be properly redeemed. Typically, the lock script locks that amount to a specific party (the beneficiary of the transaction in which it is included). That is, the lock script typically defines an unlock condition that includes the condition that the unlock script within the input of a subsequent transaction includes the cryptographic signature of the party to whom the preceding transaction is locked.

[0041] The lock script (commonly scriptPubKey) is a portion of code written in a domain-specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S). The lock script specifies what information is required to spend the transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the output of the transaction. The unlock script (commonly scriptSig) is a portion of code written in a domain-specific language that provides the information necessary to satisfy the lock script criteria. For example, it may include Bob's signature. The unlock script appears in the input 202 of the transaction.

[0042] That is, in the illustrated example, the UTXO 0 within the output 203 of Tx 0 requires Alice's signature Sig P 0 in order for the UTXO 0 to be spent (strictly speaking, for the subsequent transaction attempting to spend the UTXO A to be valid), and includes the lock script [Checksig P A . [Checksig P A includes the public key P A from Alice's public-private key pair. The input 202 of Tx 1 includes a pointer that refers to Tx 0 (e.g., in an embodiment, the transaction ID, TxID 0 which is the hash of the entire transaction Tx 1 ). The input 202 of Tx 1 includes an index within Tx 0 that identifies the UTXO 0 from among any of the other possible outputs of Tx 0 . The input 202 of Tx 1 includes the unlock script <Sig P A> Further includes. Which data (or "message") 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.

[0043] New transaction Tx 1 When the new transaction Tx arrives at 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 (this condition 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 unlock 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 Tx 0 to authenticate that the lock script within the input of Tx A contains Alice's signature that signed the expected part of the data. The expected part of the data itself ("message") also needs to be included in the Tx 1 instructions for performing this authentication. In an embodiment, the signed data includes the entire Tx 0 (that is, since a separate element specifying the signed part of the plaintext data already essentially exists, it does not need to be included). 0

[0044] ​​The details of authentication by public - private key cryptography are well known to those skilled in the art. Basically, when Alice signs a message by encrypting it with her private key, given Alice's public key and the plain - text message (the unencrypted message), another entity such as node 104 can verify that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the plain - text version of the message, such that any holder of the public key can verify the signature.

[0045] Tx 1 If the unlock script within 1 satisfies one or more conditions specified within the lock script of Tx 0 (i.e., in the illustrated example, if Alice's signature is provided within and authenticated for Tx 1 ), node 104 considers Tx 1 to be valid. If it is the mining node 104M, this means adding it to the pool 154 of transactions waiting for proof - of - work. If it is the forwarding node 104F, it forwards the transaction Tx 1 to one or more other nodes 104 within the network 106 so that the transaction Tx 1 is propagated throughout the network. When Tx 1 is verified and included in the blockchain 150, this defines the UTXO 0 from Tx 0 as spent. Note that Tx 1 can only be valid if it uses an unspent transaction output 203. If it attempts to use an output already used by another transaction 152, Tx 1 will be invalid even if all other conditions are met. Thus, node 104 also checks the previous transaction Tx 0It is necessary to check whether the referenced UTXO within is already spent (already forming a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose the order defined in the transaction 152. In practice, a given node 104 may maintain a separate database marking which UTXOs 203 within which transaction 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it has already formed a valid input to another valid transaction within the blockchain 150.

[0046] Note that in the UTXO-based transaction model, a given UTXO needs to be spent in its entirety. It is not possible to "leave some behind" a portion of the amount defined as spent in the UTXO and have another portion spent. However, the amount from a UTXO can be split among multiple outputs of the next transaction. For example, the amount defined in the UTXO 0 within 0 can be split among multiple UTXOs within 1 . Thus, if Alice does not want to give all of the amount defined in the UTXO 0 to Bob, Alice can use a remainder to give the remainder to herself in the second output of 1 or pay it to another party.

[0047] In practice, today, just the reward for the generation transaction is typically not sufficient to motivate mining, so Alice usually also needs to include a fee for the winning miner. If Alice does not include a fee for the miner, 0is likely to be rejected by the minor node 104M and thus, even if technically valid, it still will not be propagated and will not be included in the blockchain 150 (the minor protocol does not force the miner 104M to accept the transaction 152 if it does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, the 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 winning miner 104. For example, if a pointer to UTXO 0 is the only input to Tx 1 and Tx 1 is the only output UTXO 1 having. If the amount of the digital asset specified by UTXO 0 is greater than the amount specified by UTXO 1 , the difference is automatically given to the winning miner 104M. However, alternatively or additionally, it is not necessarily excluded that the mining fee can be explicitly specified in one of its own UTXOs 203 of the transaction 152.

[0048] Note also that if the total amount specified by all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another basis for invalidity in most transaction models. Thus, such a transaction is neither propagated nor mined in the block 151.

[0049] The digital assets of Alice and Bob are composed of unspent UTXOs locked to them in any transaction 152 anywhere within the blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. Nowhere within the blockchain 150 is the number that defines the total balance of a given party 103 stored. The role of the wallet function in the client application 105 is to collate together the values of all the various UTXOs locked to each party and not yet used in another previous transaction. This can be done by querying a copy of the blockchain 150 stored on any of the storage nodes 104S, for example, the storage node 104S closest or best connected to the computer device 102 of each party.

[0050] Note that the script code is often represented schematically (i.e., not in exact language). For example, [Checksig P A is written as [Checksig P Amay mean OP_DUP OP_HASH160 <H(Pa)> OP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to specific opcodes of the script language. OP_CHECKSIG (also called "Checksig") is a script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, the presence (occurrence) of the signature ("sig") is removed from the script, but additional requirements such as a hash puzzle remain for the transaction verified by the "sig" input. As another example, OP_RETURN is a script language opcode for creating an unusable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata on the blockchain 150. For example, the metadata may include a document that is desired to be stored on the blockchain.

[0051] Signature P A is a digital signature. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a portion of specific data. In an embodiment, for a given transaction, the signature signs a portion of the transaction input and all or a portion of the transaction output. The specific portion of the signed output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature to select which outputs are signed (and thus is fixed at the time of signing).

[0052] The locking script may sometimes be called the "scriptPubKey" to indicate the fact that each transaction contains the public key of the party being locked. The unlocking script may sometimes be called the "scriptSig" to indicate the fact that it supplies the corresponding signature. However, more generally, it is not essential in all applications of the blockchain 150 that the condition for the repayment of the UTXO includes the authentication of the signature. More generally, a scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0053] Optional side channel Figure 3 shows a further system 100 for implementing the blockchain 150. System 100 is substantially the same as that described in connection with FIG. 1, except that it includes additional communication capabilities. The client applications on the respective computer devices 102a, 120b of Alice and Bob each include additional communication capabilities. That is, this enables Alice 103a to establish a separate side channel 301 with Bob 103b (at the instruction of either party or a third party). The side channel 301 enables the exchange of data separate from the P2P network. Such communication may sometimes be called "off-chain". For example, this can be used to exchange the transaction 152 between Alice and Bob without the transaction being (yet) published on the P2P network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Alternatively or additionally, the side channel 301 can be used to exchange any other transaction-related data such as keys, negotiated amounts or conditions, data content, etc.

[0054] The side channel 301 can be established via the same packet - switched network 101 as the P2P overlay network 106. Alternatively or additionally, the side channel 301 can 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 a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, the side channel 301 referred to anywhere in this specification can include any one or more links via one or more networking technologies or communication media that are "off - chain", i.e., separate from the P2P overlay network 106, for exchanging data. When two or more links are used, the bundle or set of off - chain links as a whole can be referred to as the side channel 301. Thus, it should be noted that when it is said that Alice and Bob exchange information or a particular portion of data on the side channel 301, this does not necessarily mean that all of these portions of data must be sent over exactly the same link or the same type of network.

[0055] Node software Figure 4 shows an example of node software 400 executed on each node 104 of the P2P network 106 in an example of a UTXO or output - based model. The node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application - level decision engine 404, and a set of one or more blockchain - related functional modules 405. At any given node 104, these can include any one, two, or all three of a mining module 405M, a forwarding module 405F, and a storage module 405S (depending on one or more roles of the node). The protocol engine 401 is configured to recognize different fields of the transaction 152 and process them according to the node protocol. Another preceding transaction 152m - 1 (Tx m-1) A transaction 152m (Tx m ) having an input that indicates an output (e.g., UTXO) is received, and the protocol engine 401 identifies the unlock script within Tx m and passes it to the script engine 402. The protocol engine 401 also identifies and retrieves Tx m based on the pointer within the input of Tx m-1 . It can retrieve Tx m-1 from the respective node's own pool 154 of transactions pending if Tx m-1 is not yet on the blockchain 150, or from a copy of the block 151 within the blockchain 150 stored at the respective node or another node 104 if Tx m-1 is already on the blockchain 150. In any case, the script engine 401 identifies the lock script in the indicated output of Tx m-1 and passes this to the script engine 402.

[0056] Thus, the script engine 402 has the lock script of Tx m-1 and the unlock script from the corresponding input of Tx m . For example, Tx 1 and Tx 2 are shown in FIG. 4, and the same applies to any pair of transactions such as Tx 0 and Tx 1 . The script engine 402 executes the two scripts together as described above, which includes placing data on and retrieving data from the stack 403 according to the stack - based scripting language (e.g., Script) being used.

[0057] By executing the scripts together, the script engine 402 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether it "unlocks" the output containing the lock script. The script engine 402 returns the result of this determination to the protocol engine 401. If the script engine 402 determines that the unlock script meets one or more criteria specified by the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0058] In the output-based model, the result "true" from the script engine 402 is one of the conditions for the validity of the transaction. Typically, the total amount of digital assets specified in the output(s) of Tx m does not exceed the total amount indicated by the input(s), and there are also one or more additional protocol-level conditions evaluated by the protocol engine 401 that must be satisfied as well, such as the indicated output of Tx m-1 not yet being used by another valid transaction. The protocol engine 401 evaluates the result from the script engine 402 together with one or more protocol-level conditions and validates the transaction Tx m only if they are all true. The protocol engine 401 outputs an indication of whether the transaction is valid to the application-level decision engine 404. Only if Tx m is actually validated, the decision engine 404 may choose to control one or both of the mining module 405M and the forwarding module 405F to execute their respective blockchain-related functions with respect to Tx m . This may involve the mining module 405M adding Tx m to each pool 154 of the node for mining block 151, and / or the forwarding module 405F forwarding Tx mmay include forwarding to another node 104 within the P2P network 106. However, in an embodiment, the decision engine 404 does not select to forward or mine an invalid transaction, which, conversely, does not necessarily mean that there is an obligation to trigger the mining or forwarding of a valid transaction simply because it is valid. Optionally, in an embodiment, the decision engine 404 can apply one or more additional conditions before triggering one or both functions. For example, if the node is a mining node 104M, the decision engine may choose to mine a transaction only if the transaction is valid and there is sufficient mining fee remaining.

[0059] The terms "true" and "false" as used herein are not necessarily limited to returning results in the form of only a single binary digit (bit), although it is noted that this is certainly one possible implementation. More generally, "true" can refer to any state indicating a successful or positive result, and "false" can refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model (not shown in FIG. 4), a "true" result can be indicated by a combination of an implicit (protocol-level) validity check of the signature by node 104 and an additional positive output of the smart contract (if both individual results are true, the overall result is considered to indicate true).

[0060] Preliminary Matters Public Key Encryption Public Key Cryptography (PKC) utilizes an encryption method that provides confidentiality and a digital signature method that provides authenticity and non-repudiation.

[0061] Public-key encryption enables secure communication between any pair of players within a large group (especially when there is no private channel for key exchange). Each player has a pair of keys, a secret private key used for decryption and a corresponding public key that is made public and used to encrypt messages sent to that player. In the case of a player named Alice, Alice's private key is sk Alice and Alice's public key can be given by PK Alice . Any player who wants to send a confidential message m to Alice uses Alice's public key PK Alice to encrypt the message and create a ciphertext c. The ciphertext must be such that it can only be decrypted to plaintext using sk Alice . c = E(m, PK Alice ) m = D(c, sk Alice )

[0062] To implement such a system, encryption should involve the use of a trapdoor one-way function. A one-way function is a function that is easy to compute in one direction x → f(x), but the inverse f(x) → x is infeasible, i.e., it is easy to find f(x) if x is known, but it is computationally infeasible to find x even if f(x) is known. On the other hand, in a trapdoor one-way function, it is easy to find x with only the knowledge of additional information (the trapdoor), so f(x, trapdoor) → x is feasible. In general, infeasibility is based on well-studied mathematical problems that are considered computationally difficult.

[0063] Before public-key encryption, symmetric-key encryption was used to provide secure communication. In symmetric-key encryption, the parties communicating share a single secret key that is used for both encrypting and decrypting messages. Public-key encryption is also known as asymmetric-key encryption. Public-key encryption schemes generally include the following: · Key generation - Alice generates a secret key sk from a random pool. Alice - Alice derives her public key PK from the secret key and publishes it to all parties. - Alice derives her public key PK from the secret key and publishes it to all parties. Alice - Alice derives her public key PK from the secret key and publishes it to all parties. · Encryption - Any party member encrypts a message m using PK. Alice - Any party member encrypts a message m using PK. c = E(m, PK Alice ) · Decryption - To decrypt the message, Alice uses her secret key sk Alice , m = D(c, sk Alice )

[0064] For a public key encryption scheme to be secure, it must meet more requirements than a symmetric key encryption system. These requirements include that it should be computationally infeasible to derive sk from PK, and that even if an attacker could compute c for any m, it should be computationally infeasible to know m for a given c. Alice from sk Alice For a public key encryption scheme to be secure, it must meet more requirements than a symmetric key encryption system. These requirements include that it should be computationally infeasible to derive sk from PK, and that even if an attacker could compute c for any m, it should be computationally infeasible to know m for a given c.

[0065] Due to these additional requirements, designing a secure and practical public key encryption scheme is much more difficult than symmetric key encryption. Generally, public key encryption keys are several times larger than symmetric keys to achieve the same level of security. In addition, encryption and decryption algorithms are slower than those of symmetric encryption systems. In practical systems, symmetric key encryption is used to encrypt data, and public key encryption is used first to exchange the symmetric keys used.

[0066] Digital Signature A digital signature scheme can be constructed using a one-way function with a trapdoor. In a digital signature setting, each player has their own secret key used for signing and the corresponding public key used for verification. The digital signature scheme includes the following: · Key Generation - Alice generates the secret key sk from the random pool Alice . - Alice derives her public key PK from the secret key Alice and publishes it to all parties. · Signing - Alice signs the message m using her secret key sk Alice to obtain the signature s s = Sign(m, sk Alice ). · Verification of signature - Any party can verify the signature by performing the following: Verify(m, s, PK Alice ).

[0067] Note that the above system provides authenticity, non-repudiation, and integrity. This is because no one other than the owner of the secret key can select a message, sign it, and produce a signature linked to the corresponding public key. Since the validity check fails if m or s is changed, the system provides integrity.

[0068] Public Key Infrastructure (PKI) PKC has greatly solved the problem of secret sharing in symmetric key settings. However, the problem remains of how to ensure that Alice's public key belongs to Alice. If it is carelessly destroyed or any malicious player can replace Alice's public key with their own public key, any malicious player can decrypt all messages addressed to Alice that are encrypted with the malicious player's public key. Furthermore, generally, PK Alice is a string that appears random with at least 500 bits, so there is no easy way for any other player to distinguish between Alice's actual key and the malicious player's key.

[0069] This problem can be partially avoided using digital certificates and PKI. Digital certificates mainly contain messages that include Alice's public key and Alice's identifier. The hash of these fields is signed by a Certificate Authority (CA). The CA is a trusted third - party organization, and its public key is known to all party members and is fully trusted. Therefore, any party member can easily verify that the certificate is actually signed by the CA. The CA is responsible for ensuring that Alice's public key actually belongs to Alice. If Alice can prove her public key using a certificate from a known CA, Alice can use her public key to receive encrypted messages or even issue certificates to other players.

[0070] In the case of an actual system, there is a single Certificate Authority that all members of the group can know the public key of. This CA can provide certificates to other CAs, and these other CAs can issue certificates to other players. As an example, web browsers have pre - installed certificates from a number of CAs. Any of these certificates can function as a root of trust for any https server. If the certificate provided by the server does not have a valid root of trust for the CA, the browser can warn the user that it cannot verify that the certificate belongs to the visited https server.

[0071] The known standard for certificates is called X.509. It includes the following fields: · Version · Validity period (when it becomes valid and when it expires) · Certificate issuer · Public key type, length, and value · Usage (for example, can this certificate be used to sign other certificates) · Hash type and value, etc. · Subject

[0072] Identity (ID)-Based Encryption (IBE) ID-based encryption itself was proposed in the early 1980s. The IBE scheme is a public-key encryption scheme in which the encryption key is an arbitrary string such as an email address or a mobile phone number. In such a system, to send an encrypted message to Alice, it is sufficient to know Alice's email address. There is no need for prior communication with Alice to obtain a certificate authority or Alice's public key.

[0073] A typical IBE system generally still has to have a trusted third-party institution, commonly called a "private key generation authority" (PKG). The IBE scheme utilizes the following algorithms: · Master key generation - The PKG generates a master secret key sk master from a random pool. - The PKG derives its own public key PK master from the secret key and publishes PK master to all parties. · User key generation - Alice selects her public key (e.g., Alice's email address, mobile phone number, etc.) ID Alice and requests a secret key (i.e., a decryption key) from the PKG. - The PKG generates Alice's secret key sk master from the master secret key sk Alice and Alice's public key ID Alice and sends sk Alice to Alice through a secure channel. · Encryption - Any party wishing to communicate securely with Alice regarding message m can use the following to use Alice's public key ID Alice : c = E(m, ID Alice ) · Decryption - Alice decrypts the message using her secret key sk Alice . m = D(c, skAlice )

[0074] In IBE, the PKG knows all the secret keys of all users. In certain applications, this may be acceptable. For example, a company can use IBE to ensure the confidentiality of its employees, and by controlling the employees' secret keys, it will hope to be able to access, delegate or revoke access to the employees' encrypted data.

[0075] It is also possible to design an IBE with two or more PKGs. As long as all PKGs do not collude to reveal Alice's secret key, Alice is the only one who owns her decryption key. The system requires at least one honest PKG.

[0076] In a secure communication application, IBE is used to exchange the keys of a symmetric encryption system. It has been proposed to use IBE in applications that require high-speed call setup, such as those used by emergency services.

[0077] As shown by the above IBE algorithm, the secret key sk Alice is calculated by the PKG, which is a trusted third-party institution, and passed to the user. There is no guarantee that the PKG will not use the secret key later. Even assuming that the PKG is completely trusted, from the attacker's perspective, the PKG still functions as a single point of failure on the security chain. Therefore, if key escrow can be removed from IBE, the security vulnerability of such an IBE system can be reduced without losing benefits.

[0078] Bilinear mapping G 1 and G 2 be two groups of order q for some large prime q. The Boneh-Franklin IBE scheme (BF-IBE) is a bilinear mapping e: G 1 × G 1 → G 2is used. The mapping must satisfy the following properties: 1. Bilinearity: For all P, Q ∈ G 1 and all [Number] for e(aP, bQ) = e(P, Q) ab If so, the mapping e: G 1 × G 1 → G 2 is bilinear. 2. Non-degeneracy: The mapping does not send all pairs in G 1 × G 1 to the identity in G 2 . Since G 1 , G 2 is a group of prime order, note that this means that if P is a generator of G 1 , then e(P, P) is a generator of G 2 . 3. Computability: There exists an efficient algorithm to compute e(P, Q) for any P, Q ∈ G 1 .

[0079] For any bilinear mapping satisfying the above properties, the discrete logarithm problem in G 1 is no harder than the discrete logarithm problem in G 2 . In BF-IBE, G 1 is a subgroup of the additive group of points on the elliptic curve E / F p . The group G 2 is a subgroup of the multiplicative group of the finite field [Number] .

[0080] Boneh-Franklin IBE Below, the BF-IBE scheme where a single trusted third party (TTP) functions as the PKG will be described. Assume the following parameters are used by the PKG: 1. A pair (G 1 , G 2 ) 2. A bilinear pairing e: G 1 × G 1 → G 2 3. A generating point P ∈ G 1 4. Four hash functions:

Number

[0081] {0, 1} * represents binary sequences of arbitrary length, and {0, 1} n represents binary sequences of length n, and

Number

Number

Number

Number

[0082] · Setup [Algorithm 1A] The PKG runs this algorithm once:

Number

[0083] · Key Generation [Algorithm 2A] The user's identity ID A Once given, the PKG executes this algorithm using the secret key s. 1. Calculate Q 1 which is a point in G A =H 1 (ID A ). 2. Calculate D A =s·Q A and return it. 3. The PKG sends D A to the user over a secure channel. 4. The user's public key is ID A . 5. The user's secret key is D A .

[0084] · Encryption [Algorithm 3A] Given a message m ∈ {0, 1} n to be encrypted, along with the identity ID A and the PKG's public key P pub , anyone can perform the following: 1. Calculate Q A =H 1 (ID A ). 2. Select an n-bit random number σ. 3. Calculate r = H 3 (σ, m). 4. Calculate the ciphertext c as the following triplet (U, V, W):

Number

[0085] · Decryption [Algorithm 4A] To decrypt the ciphertext c = (U, V, W), the user uses the user's secret key D A , and the following algorithm: [Number]

[0086] Updating the user's secret key means that the user's public key should also be updated. Since the public key is expected to be a constant string ID (email, mobile number), for each user, key update can be achieved by having the public key as the concatenation of an identifier constant string and a variable string. The variable string can represent a validity period, for example, a timestamp.

[0087] Multi-PKG Boneh-Franklin IBE The above IBE scheme can be generalized to have two or more PKGs, reducing the dependence on individual PKGs as the required trust is distributed across several PKGs. Also, since the user (i.e., the owner of the identity) is also included as part of the PKG group, the key escrow problem is removed.

[0088] Assume the following parameters are used by the PKG: 1. A pair of groups (G 1 , G 2 ) 2. A bilinear pairing e: G 1 × G 1 → G 2 3. A generating point P ∈ G 1 4. Four hash functions [Number]

[0089] · Setup [Algorithm 1B] Each PKG independently executes this algorithm once: [Number]

[0090] · Key generation [Algorithm 2B] The user's identity ID A Once given, each PKG independently executes this algorithm using its partial secret key s i : 1. Calculate Q 1 which is a point in G A = H 1 (ID A ). 2. Return D iA = s i· Q A to the owner of ID A over a secure channel.

[0091] Once the user receives D iA from each PKG, the user executes the following algorithm: [Number]

[0092] · Encryption [Algorithm 3B] Given the identity ID A and the public key (X A , Y A ), the partial public key can be verified by checking this equation before encrypting the message: [Number]

[0093] This equation checks the dependency between the user's public key and the PKG's public key, i.e., it verifies which PKG parameters are being used by Alice. However, it does not verify that both ID A and (X A , Y A ) belong to Alice.

[0094] To encrypt message m using a complete ID-based public key (ID A , X A , Y A ), both ID A and Y A need to execute the following algorithm: 1. Q A = H 1 (ID A ) is calculated. 2. Select an n-bit random number σ. 3. r = H 3 (σ, m) is calculated. 4. The ciphertext c = (U, V, W) is calculated as the following triplet:

Number

[0095] Normally, in PKI, the user's public key is signed by the CA. In this case, the verification of the user's public key is essentially the verification of the digital signature signed by the CA. In this case, the verification is two bilinear pairings and one equality check. Furthermore, since the user can generate their own secret value, as a trade-off, in addition to their identity ID A , the public key (X A , Y A ) must be introduced. Depending on the different scenarios, this trade-off can be significant as it solves the key escrow problem, i.e., the trust problem.

[0096] X A and

Number

Number

[0097] When having a user as the PKG, a secure system only needs to have Alice and a single PKG. That is, one key share is generated by the PKG and the other key share is generated by the user.

[0098] · Decryption [Algorithm 4B] To decrypt the ciphertext c = (U, V, W), the secret key s A needs to execute the following algorithm:

Number

[0099] Identity (ID)-Based Public Key Generation Protocol Embodiments of the present disclosure provide an ID-based public key generation protocol, or equivalently, an ID-based encryption key generation protocol. Specifically, the ID-based public key / encryption key is generated for a user based on the user's personal identifier, so that the key is associated with the user's identity. The personal identifier may include one or more of a name and / or address, an email address, a phone number, a passport number, a driver's license number, a national insurance number, a social media profile, a date of birth, etc. The personal identifier may also be an attribute such as being a member of a specific group such as a police officer, or working in a specific department such as HR, or working on a specific project, or having a security clearance. In the example of being a member of a group, note that any member of the group may be able to decrypt a message encrypted with the ID-based public key, unless other identifiers or attributes are also used. For example, each member of the same group may be given access to the secret key corresponding to the ID-based public key.

[0100] FIG. 5 shows an exemplary system 500 for implementing an embodiment of the present disclosure. The exemplary system includes a user (Alice) 103a, a key generator 501, and a network of P2P blockchain nodes 106. In some embodiments, the system 500 may include multiple key generators 501. Preferably, one, some, or all of the key generators 501 are configured to perform an identity verification check on Alice 103a, which means that the key generator 501 can verify the identifier as belonging to Alice 103a. For example, the key generator may perform an identity check as part of a KYC (know your customer) protocol.

[0101] The computer device of Alice 103a and the blockchain node 104 have been described above with reference to FIGS. 1 to 4, and thus will not be described in further detail here. Each key generator 501, also referred to as a private key generation authority (PKG), comprises a respective computer device. The computer device of each PKG 501 comprises a respective processing device having one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer device of each PKG 501 further comprises a memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units using one or more memory media, such as magnetic media like hard disks, electronic media like SSDs, flash memories or EEPROMs, and / or optical media like optical disk drives. The memory on the computer device of each PKG 501 stores software comprising respective instances of at least one client application configured to execute on the processing device. It will be understood that any action attributed to a given PKG 501 herein may be performed using software executed on the processing device of the respective computer device. The computer device of a given PKG 501 may comprise at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. Additionally, or alternatively, the computer device of a given PKG 501 may comprise a server comprising one or more physical server units, or even an entire data center. The computer device of a given PKG 501 may also comprise one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0102] In some examples, one, some, or all of the PKGs may be the mining node 104M, in which case the computer devices of those PKGs are the computer devices of the mining node 104M as described above.

[0103] In the example shown in FIG. 5, Alice 103a sends the identifier ID A to PKG501. Alice 103a may send the identifier directly to PKG501 via a wired or wireless connection, for example, via a secure channel 301 as described with reference to FIG. 3. Alternatively, Alice 103a may send the identifier ID A to PKG501 via, for example, a blockchain transaction payable to the address of PKG501. For example, Alice 103a may generate a blockchain transaction having an output (usable or unusable) that includes the identifier ID A . If the identifier ID A is already known to PKG501, Alice 103a does not need to send the identifier. For example, Alice's identifier ID A may be publicly known.

[0104] PKG501 generates a secret key share D A based on the identifier ID iA , that is, the secret key share D iA is a function of the identifier ID A . PKG501 can send the secret key share D iA to Alice via, for example, a secure channel, for example, via a blockchain transaction payable to the address of Alice 103a, or via an alternative method. The secret key share D iA may be sent in an encrypted form. For example, Alice 103a may have, for example, a public key (the "first public key") known to PKG501. Alice may have a first public key for use as the basis for an address on the blockchain network. The first public key may be a certified public key and may be certified, for example, by PKG501 or by a separate certificate authority.

[0105] In some examples, Alice 103a may also use the same protocol as PKG 501 to generate her own respective secret key share D iA Here, the same protocol means the same algorithm that includes one or more different variables to generate different secret key shares.

[0106] As an example, PKG 501 and Alice 103a may each generate their respective secret key shares using the algorithms described above, particularly Algorithm 1B and Algorithm 2B.

[0107] When Alice 103a obtains a set of secret key shares D iA (e.g., receives and optionally generates it), Alice 103a generates an ID-based secret key s A . The ID-based secret key s A is generated based on the set of secret key shares D iA , that is, the ID-based secret key s A is a function of the set of secret key shares D iA . Alice 103a may generate the ID-based secret key s A using the key generation algorithm described above, namely Algorithm 2B.

[0108] Alice 103a may also generate a partial ID-based public key (X A , Y A ). This key is partial in the sense that it does not decrypt messages encrypted using the partial ID-based public key (X A ), Y A ). Alice may generate the partial ID-based public key using the key generation described above, namely Algorithm 2B. The partial ID-based public key (X A , Y A ) is a public key share P A corresponding to the set of secret key shares D A iA i ​​is generated based on a set (i.e., is a function of) thereof. Here, each public key share P i is such that the public key share P i is generated based on the respective secret key share D iA , i.e., the public key share P i is a function of the secret key share D iA , corresponding to each secret key share D iA .

[0109] Alice 103a may send the partial ID-based public key (X A , Y A ) to PKG501, for example, via a secure channel, via a blockchain transaction payable to the address of PKG501, or via an alternative means. In that case, PKG501 generates the (complete) ID-based public key PK A . The ID-based public key PK A is based on (i.e., is a function of) the identifier ID A and the partial ID-based public key (X A , Y A ). Additionally or alternatively, Alice 103a herself may generate the ID-based public key PK A . Preferably, PKG501 can perform an identity verification check on Alice 103a and Alice's identifier ID A , and assuming that the identity verification check is successful, it is preferable for PKG501 to generate the ID-based public key PK A .

[0110] Once the ID-based public key PK A is generated, Alice 103a and / or PKG501 use the ID-based public key PK AGenerate a blockchain transaction that includes an output that includes A . The output may be a spendable output, such as a pay-to-public-key-hash (P2PKH) output, or an unspendable output, such as an OP_RETURN output. Preferably, PKG501 generates the blockchain transaction such that other parties can rely on the identity verification check of PKG when using

[0111] The blockchain transaction (hereinafter referred to as the "validity check transaction") Tx VCT is sent to one or more nodes of the blockchain network 106 for inclusion in the blockchain 150. Preferably, PKG501 sends the validity check transaction Tx VCT to the blockchain network 106. Alternatively, Alice 103a may send the validity check transaction Tx VCT to the blockchain network 106. The party that generates and sends the validity check transaction Tx VCT may or may not be the same party that sends the validity check transaction Tx VCT to the blockchain network 106. For example, Alice 103a may generate Tx VCT and then transfer it to PKG501 for transmission to the blockchain network 501.

[0112] In an example where PKG501 generates the ID-based public key PK A , PKG501 may send the ID-based public key PK A and / or the validity check transaction Tx VCT directly to Alice 103a, for example, over a secure channel. The ID-based public key PK A may be sent in an encrypted form, for example, encrypted using Alice's first public key.

[0113] Alice 103a can obtain an ID-based public key PK, for example, from a PKG 501 or from a blockchain 150, for use as an encryption key, for example. A The use of the ID-based public key PK A will be described later. The PKG 501 can send a transaction identifier TxID VCT of a validity check transaction Tx VCT to Alice 103a so that Alice can easily identify the validity check transaction Tx VCT on the blockchain 150.

[0114] Alice 103a and / or the PKG 501 can generate a blockchain transaction (hereinafter referred to as a parameter transaction) Tx par . The Tx par includes parameters used to generate the ID-based public key PK A , for example, parameters of algorithms 1B and 2B. The private key and the secret key are not included in the parameter transaction Tx par . The parameter transaction Tx par is sent to the blockchain network 106 by Alice 103a and / or the PKG 501. The parameter transaction Tx par may or may not be the same transaction as the validity check transaction Tx VCT , and the party that generates the parameter transaction Tx par may or may not be the same as the party that generates the validity check transaction Tx VCT . The parameters enable a third party to verify the ID-based public key PK A and encrypt a message using the ID-based public key PK A . The parameters also enable Alice 103a to AEnables decrypting a message encrypted using it. The parameters can be made public without using the blockchain 150. For example, the parameters may be made public on a (hosted) website by Alice 103a and / or the PKG 501. Instead of making the parameters public, they may be sent to the parties upon request.

[0115] Parameter transaction Tx par And validity check transaction Tx VCT If they are different transactions, the parameter transaction Tx par For example, may be that Alice 103a or a third party, the validity check transaction Tx VCT The ID-based public key PK stored in A So as to be able to identify, the validity check transaction Tx VCT The transaction identifier TxID of VCT May include.

[0116] In the example where the PKG 501 is the mining node 104M, the parameter transaction Tx par May be a generation transaction (also known in the art as a coinbase transaction). The generation transaction was described above. In these examples, sending the parameter transaction Tx par To the blockchain network 106, the parameter transaction Tx parIt means mining a new block 151 that includes. Only the mining node 104M can generate a generated transaction as part of the block mining process. To mine a block, proof of work is required, which is essentially a computationally expensive process. Therefore, it is assumed that the mining node 104M that puts in the proof of work required to mine a block with a generated transaction including parameters will not include inaccurate parameters because this is a costly process for the mining node.

[0117] Validity check transaction Tx VCT may include a spendable output locked to the public key or public key address of Alice 103a, for example, Alice's first public key. For example, the output may be a P2PKH output. For the P2PKH output to be unlocked by the input of the spend transaction, the input of the spend transaction must include, although not necessarily in this order, the public key hashed to the P2PKH within the P2PKH output and the signature generated using that public key. The output may impose one or more additional requirements on the input of the spend transaction.

[0118] Alternatively, the validity check transaction Tx VCT may include a spendable output locked to the public key or public key address of PKG501. For example, the output may be a P2PKH output payable to the public key of PKG501.

[0119] As another alternative, the validity check transaction Tx VCTmay include an output that is locked with the public key of Alice 103a and the public key of PKG 501. Depending on the output script, the output may be unlocked if the input of the spending transaction includes Alice's public key and / or signature, or if the input of the spending transaction includes the public key of PKG 501, or if the input of the spending transaction includes two public keys (one from Alice 103a and one from PKG 501) and / or two signatures (one from Alice 103a and one from PKG 501). For example, the output may be an m-of-n multi-sig output that is unlocked if the input of the spending transaction includes m signatures corresponding to n public keys in a multi-sig output.

[0120] In some examples, the spendable output of the validity check transaction Tx VCT may include the ID-based public key PK A Alternatively, the validity check transaction Tx VCT may include two outputs, one being a spendable output and the other being an unspendable output that includes the ID-based public key PK A

[0121] If the spendable output of the validity check transaction Tx VCT is locked to Alice 103a (i.e., more precisely, Alice's public key or public key address), Alice 103a may generate a revocation transaction Tx VCT to spend that output of the validity check transaction Tx rev When sent to the blockchain, the revocation transaction Tx rev removes the output of the validity check transaction Tx A that includes the ID-based public key PK from the unspent transaction output (UTXO) set of the blockchain 150. Similarly, for the validity check transaction Tx VCT VCTIf the available output of VCT is locked to PKG501 (or more precisely, the public key or public key address of PKG501), PKG501 may generate a revocation transaction Tx rev that invalidates the use of that output of

[0122] As described above, Alice's ID-based public key PK A can be used to encrypt a message. In that sense, the ID-based public key PK A is used as an ID-based encryption key. Although these terms are synonymous, for consistency, the key is referred to as the ID-based public key PK A throughout the following.

[0123] In some examples, Alice 103a herself may use the ID-based public key PK A to encrypt a message. For example, Alice 103a may use the encryption algorithm described above, i.e., Algorithm 3B, to encrypt the message. Alice 103a may store the encrypted message, send the encrypted message to one or more different parties (which may include PKG501), broadcast the encrypted message over a network (e.g., over a private network), publish the encrypted message on a public website, for example, or include the encrypted message in the blockchain network 106 for transmission to one or more nodes of the blockchain network. For example, Alice 103a may generate a blockchain transaction that includes an output that includes the encrypted message. The encrypted message may form part of a lock script, for example, it may impose requirements on the input of the spend transaction in order to include the decrypted message. Of course, only a party having access to the ID-based private key s A can decrypt the encrypted message, which is preferably only Alice 103a.

[0124] In other examples, a party other than Alice 203a may encrypt a message using the ID-based public key PK A . For example, the party may obtain the ID-based public key PK VCT from a validity check transaction Tx A . Alice may obtain the encrypted message directly from, for example, the party performing the encryption, from a blockchain transaction, or by other means. Then, Alice 103a may use the ID-based private key s A to decrypt the encrypted message and reveal the message. Alice may use the decryption algorithm described above, i.e., Algorithm 4B, to decrypt the encrypted message. As described above, the encrypted message may form part of the lock script of a blockchain transaction, and Alice 103a may include the decrypted message in the unlock script of the use transaction to unlock the lock script.

[0125] FIG. 6 shows another exemplary system 600 for implementing an embodiment of the present disclosure. The system 600 of FIG. 6 is similar to the system 500 of FIG. 5, but an additional PKG is added. In the example of FIG. 6, a first PKG 501a and a second PKG 501b are present. In general, the system may comprise any number of PKGs 501. Both the first PKG 501a and the second PKG 501b may be configured to perform the actions previously associated with the PKG 501 of FIG. 5.

[0126] The first PKG 501a and / or the second PKG 501b may obtain the identifier ID A from Alice 103a. In some examples, one PKG (e.g., PKG 501a) obtains the identifier ID A and may send the identifier ID A to one or more different PKGs (e.g., PKG 501b). The first PKG 501a and the second PKG 501b each generate their respective private key shares D A based on the identifier ID iAGenerate, where the first PKG501a generates the first secret key share D 1A Generate, and the second PKG501b generates the second secret key share D 2A Generate. Each PKG uses the same algorithm to generate its respective secret key share D iA except by using different variables (e.g., secrets and / or random numbers). Each PKG iA sends its respective secret key share D iA to Alice 103a, and Alice 101a may or may not generate its respective secret key share D iA Each PKG501 may send its respective secret key share D iA to Alice 103a using the same communication method. For example, both the first PKG501a and the second PKG501b may send their respective secret key shares D 1A over a secure channel or via different communication methods. For example, the first PKG501a may include the secret key share D 2A in a blockchain transaction, and the second PKG may send its secret key share D

[0127] Alice 103a uses the first secret key share D 1A and the second secret key share D 2A to generate the ID-based secret key s A where the ID-based secret key s A is a function of each of the secret key shares D iA .

[0128] Alice 103a also generates the partial ID-based public key (X A , Y A ), that is, the partial ID-based public key (X A , Y A ). The partial ID-based public key (X A , Y A ) corresponds to the public key share P iA of the set of secret key shares D iGenerated based on the set (i.e., it is that function). The first PKG501a and the second PKG501b each, for example, on a secure channel or using their respective blockchain transactions, send their respective public key shares P i to Alice 103a. Alice 103a may send the partial ID-based public key (X A , Y A ) to both the first PKG501a and the second PKG501b, or Alice may send the partial ID-based public key (X A , Y A ) to one of the PKGs (e.g., PKG501a), and then that PKG may forward it to the other PKG (e.g., PKG501b). The partial ID-based public key (X A , Y A ) may be sent in encrypted form, for example, encrypted using Alice's first public key.

[0129] One, some, or all of the PKGs generate the complete ID-based public key PK A based on the identifier ID A and the partial ID-based public key (X A , Y A ). Preferably, only one PKG (e.g., PKG501a) generates the validity check transaction Tx A containing the ID-based public key PK VCT , and then sends that transaction Tx VCT to the blockchain network 106. However, it is not excluded that two or more PKG501s may each generate a respective validity check transaction Tx A containing the ID-based public key PK VCT . One, some, or all of the PKGs may generate a parameter transaction Tx A containing the (public) parameters used to generate the ID-based public key PK par . Preferably, the PKG that generates the validity check transaction Tx VCT also generates the parameter transaction Txpar is generated, which may or may not be the same blockchain transaction even if it is the same blockchain transaction.

[0130] Embodiments of the present disclosure provide an implementation of an identity-based encryption (IBE) system that uses a blockchain 150 and its UTXO set to enable key revocation key validity checks. The blockchain 150 is utilized to provide authenticity and integrity when reading IBE keys and parameters. The IBE system is preferably implemented by a reputable mining node 104M. Each mining node 104M can create a publicly known identity that is cryptographically protected, for example, as an ECDSA public key and backed up by a reputation system based on proof of work. Assuming that each mining node 104M does not want to risk its reputation by cheating the system, the reputable mining node 104M is trusted to perform checks on the user's identity and generate valid IBE keys. Further, the UTXO set can function as a whitelist in a PKI setting, whereby the IBE key is valid when referenced by a transaction output in the UTXO.

[0131] The following presents another exemplary embodiment of the present disclosure. Without loss of generality, assume that there are three mining nodes 104M providing an IBE key generation service. Assume that Alice 103a wishes for her identity Alice@Blockland.com to be verified and used as her IBE public key.

[0132] Alice requests a private key and contacts all three mining nodes M 1 , M 2 , and M 3 . Each mining node M iVerifies Alice's identity independently. When Alice 103a is convinced that it is actually the owner of Alice@Blockland.com, it follows these steps: 1. Each mining node executes the key generation algorithm (Algorithm 2B) for ID A = Alice@Blockland.com and sends D iA to Alice 103a. 2. Alice 103a generates its partial public key (X A , Y A ). 3. When receiving (X A , Y A ) from Alice 103a, each mining node verifies the following equation.

Equation

[0133] Once the coinbase transaction is mined, Alice's IBE public key can be used. Note that the information within the transaction generated in Step 7 must be included only once in the coinbase transaction mined by any of the mining nodes. Once mined, other miners do not need to include the same information in further transactions.

[0134] Key revocation can be achieved by using a validity check transaction, i.e., removing it from the UTXO set. This results in immediate key revocation and can be done by the user, key generator, trusted third - party institution, or a combination thereof. Also, another party, e.g., Bob 103b, can easily check whether Alice's IBE key is valid by simply checking Alice's details in the UTXO set. Note that two or more mining nodes 104M can each generate their own validity check transactions. This allows for configurable revocation rules. For example, if there are three validity check transactions, one rule could stipulate that for the IBE key to be considered revoked, only one of the three validity check transactions needs to be used. Another rule could stipulate that all three validity check transactions must be used for the IBE key to be considered revoked.

[0135] As an alternative to step 5, instead of OP_RETURN, OP_PUSHDATA and OP_DROP can be used to insert Alice's IBE key PK A into the lock script of the transaction. This ensures that PK A is always within the UTXO and that no pruning occurs as can happen with OP_RETURN outputs.

[0136] The key generation service can be provided by a mining node as described above. It can also be provided by a non-miner. The non-mining node can execute a smart contract that generates a private key for a subscriber, e.g., Alice 103a. The key generation public parameters can be published on the blockchain and can benefit from the immutability of the blockchain. Note that Alice 103a must inform Bob 103b which key generation service provider she is using.

[0137] As the number of blockchain users increases, it becomes necessary to efficiently store information about the blockchain and avoid time delays. It is possible to insert the information of multiple users into a single coinbase transaction created in step 7. In this case, the public parameters in step 7.a need to be inserted only once initially, followed by the IBE public key and the validity check transaction identifier for each user (steps 7.b and 7.c). The same public parameters can be used for each user. The number of public keys that can be added to a single coinbase transaction is limited only by the size of the transaction or any other size limit imposed by the blockchain protocol.

[0138] It is possible to activate a set of IBE keys at a later date using the transaction sequence field of a transaction. This can be particularly useful when there is a separate server responsible for key generation that goes offline to shorten its public time. In this case, the server generates a set of keys and inserts them into a time-locked transaction so that they can be automatically activated later by a mining node. Using the same technique, it is also possible to provide automatic key updates by creating a time-locked transaction that uses a validity check output in a usage transaction containing updated IBE keys.

[0139] Alice's identifier can be in the following format: [Number]

[0140] identifier_string can be an email, mobile number, passport number, or social platform account, etc. functional_string can be one or any combination of the following: · Expiration date: After this date, this ID A should not be used, and a new ID with a new expiration date A should be used. The key generator service provider has to generate and send the secret key for the new ID A . This will ensure the update of the IBE key. The update period can be set monthly, daily, etc., depending on the requirements of the use case. · Activation start date: This can be used to ensure that the secret key generation authority does not disclose the secret key before that date. In this case, the key generator service provider is used to implement the time lock. The date can optionally be the blockchain height. · Attribute: The service provider sends the private key only when this attribute or a set of them is satisfied. This can be used to implement attribute-based access control and location encryption. For example, Bob 103b can send a decryptable message if Alice 103a has a security clearance. The key generator service provider publishes the decryption key to Alice 103a only if Alice 103a can satisfy this requirement.

[0141] Use Case Figure 7 shows a first use case (UC1). Alice 103a contacts the private key generation authority PKG1 501a to generate a private key corresponding to her email address. PKG1 501a verifies that the email address belongs to Alice 103a and sends the private key skAlice to Alice using a secure channel. This use case can be executed on the blockchain by inserting Alice's request and PKG1's response after OP_RETURN in two blockchain transactions. Alice 103a can insert the public encryption key (PKAlice) into the request to PKG1 501a to protect the channel, but can skip it if such a channel already exists. PKG1 501a executes the verification and key generation steps and sends Alice's private key encrypted using PKAlice in the response transaction. Two exemplary transactions are shown below. [Table 1] [Table 2]

[0142] Note that the above transactions are simplified to convey the concept. More detailed transactions may include ephemeral encryption keys and initialization vectors, as well as additional outputs for any modifications.

[0143] The second use case (UC2) is shown by the following transaction. Alice 103a adds her own private key so that Alice's key remains secure even if the partial private key generated by PKG1 is leaked. When Alice publishes (X A , Y A ) on the blockchain, there are at least two possible ways. The first way is a single transaction where Alice 103a pays herself.

Table 3

[0144] The second way is in the form of two transactions (request and response) between Alice 103a and PKG1 501a.

Table 4

Table 5

[0145] Figures 8a and 8b illustrate a third exemplary use case (UC3). Bob 103b wishes to send Alice 103a a message that Alice 103a can only read within a time frame (not before t1 and not after t2). Such a service may be provided by another key generator PKG2 501b other than PKG1 501a. Bob 103b generates a new IBE public key for Alice 103a that uses the IBE public key of Alice generated based on Alice@Blockland.com (which was verified and generated by PKG1 in UC1), and inserts an expiration period and a random nonce. Bob uses the newly generated IBE public key Alice@Blockland.com_PKG1_t1_t2_nonce together with the public key parameters of PKG2 to encrypt message M1 and outputs C1. Bob sends the ciphertext and the IBE public key that Bob used for encryption to Alice 103a. PKG2 501b can be a service provider on the blockchain, such as a mining node 104M or a non-mining node. Bob 103b can retrieve the public key parameters from PKG2 501b. When Bob 103b generates a new IBE public key, he retrieves PK Alice and the public parameters of PKG1 from the blockchain 150. Bob needs to confirm that PKG1 is a secret key generation authority and a reliable identity verification service provider.

[0146] Alice 103a contacts PKG2 501b to obtain a secret key for unlocking Bob's encrypted message C1. PKG2 501b checks that PKG1 501a is a trusted service provider and checks that the requested time is between t1 and t2. If all checks pass, PKG2 501b generates a secret key for Alice 103a corresponding to the encryption key generated and used by Bob 103b. The new secret key can be encrypted with C2 using Alice's existing (i.e., generated based on Alice@Blockland.com) IBE key. Note that in this use case, PKG2 103b provides a time check service and depends on PKG1 501a to perform the email verification service already done in UC1. Similar to UC1, the communication between Alice 103a and PKG2 501b is performed on blockchain 150.

[0147] These use cases show how the IBE protocol can be used to enable Bob (the party performing the encryption) to set Bob's conditions so that Alice (the party performing the decryption) can decrypt the message. In UC1, Alice obtains an IBE key from PKG1. Bob uses PKG2, a different PKG, to check that Alice meets Bob's conditions.

[0148] Conclusion It will be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program according to any one or more of the following statements may be provided.

[0149] Statement 1. A computer-implemented method for generating an identity (ID)-based encryption key, the method being performed by a first party having an identifier and including: Obtaining a set of secret key shares and a corresponding set of public key shares, where each secret key share is generated based on an identifier, and at least one of the set of secret key shares is generated by each one of a set of key generation parties, Generating an ID-based secret key based on each of one or more secret key shares, and Generating a partial ID-based public key, where the partial ID-based public key is generated based on each of the corresponding set of public key shares, Transmitting the partial ID-based public key to at least one of the set of key generation parties to generate an ID-based public key, where the ID-based public key includes an identifier and the partial ID-based public key, and / or Generating an ID-based public key, where the ID-based public key includes an identifier and the partial ID-based public key.

[0150] A key share is a component of a secret key that can be used with a plurality of other key shares to generate a secret key.

[0151] Statement 2. The first output of the first blockchain transaction includes an ID-based public key, where the ID-based public key includes an identifier and a partial ID-based public key, and the method includes obtaining the ID-based public key from the first blockchain transaction, the method described in Statement 1.

[0152] Statement 3. The method described in Statement 2, where obtaining the ID-based public key from the first blockchain transaction includes the following: Obtaining a transaction identifier of the first blockchain transaction from at least one of one or more key generation parties, and Using the transaction identifier to obtain the first blockchain transaction from the blockchain in which the first blockchain transaction is recorded.

[0153] Statement 4. A method as described in any one of Statements 1 to 3, including the following: Obtaining an ID-based public key from at least one of a set of key generation parties.

[0154] Statement 5. A method as described in any one of Statements 1 to 4, including the following: Encrypting a first message using the ID-based public key to generate a first encrypted message, and Sending the first encrypted message to a second party and / or generating a second blockchain transaction including an output including the encrypted message.

[0155] Statement 6. A method as described in any one of Statements 1 to 5, including the following: Obtaining a second encrypted message encrypted using the ID-based public key, and Decrypting the second encrypted message using a private key to reveal the second message.

[0156] Statement 7. A method as described in any one of Statements 1 to 6, including sending an identifier to at least one of one or more key generation parties.

[0157] Statement 8. A method as described in Statement 7, wherein sending the identifier includes the following: Generating a third blockchain transaction including an output including the identifier, and Sending the third blockchain transaction to one or more nodes of a blockchain network for inclusion in the blockchain.

[0158] Statement 9. A method as described in Statement 2 or a statement subordinate thereto, wherein a first party has a first public key and a first blockchain transaction includes a second output locked to the first public key of the first party, the method including: a) Referencing the second output of the first blockchain transaction and b) generating a fourth blockchain transaction including an input including a signature generated based on the private key corresponding to the first public key of the first party, and sending the fourth blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0159] The first and second outputs of the first blockchain transaction may be the same output. That is, the ID-based public key may be included in a usable (e.g., P2PKH) output. For example, the output may include the public key using OP_PUSHDATA and OP_DROP.

[0160] Statement 10. A method as described in any of Statements 1 to 9, wherein transmitting the partial ID-based public key to at least one of a set of key generation parties includes: generating a fifth blockchain transaction including an output including the partial ID-based public key, and sending the fifth blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0161] Statement 11. A method as described in any of Statements 1 to 10, wherein the identifier of the first party includes one or more of the name and / or address of the first party, the email address of the first party, the phone number, the passport number, the driver's license number, the social media profile, the date of birth, and the group member identifier.

[0162] Statement 12. A computer-implemented method for generating an identity (ID)-based cryptographic key, wherein a first party has an identifier, the method being executed by a first key generation party and including the following: Sending a secret key share to the first party, where the secret key share is generated based on the identifier and has a corresponding public key share, Obtaining a partial ID-based public key, where the partial ID-based public key is generated based on the corresponding public key share, Generating and / or obtaining an ID-based public key, where the ID-based public key is generated based on the partial ID-based public key and the identifier, and Generating a first blockchain transaction including a first output including the ID-based public key.

[0163] In an example, the method includes generating a secret key share and a corresponding public key share.

[0164] The method according to statement 12, including sending the first blockchain transaction to one or more nodes of a blockchain network for inclusion in the blockchain.

[0165] The method according to statement 12, including sending the first blockchain transaction to the first party.

[0166] The method according to any one of statements 12 to 14, wherein the first output of the first blockchain transaction is an unusable output.

[0167] The method according to any one of statements 13 to 15, including obtaining an identifier from the first party.

[0168] Statement 17. The method according to Statement 16, wherein the blockchain includes a third blockchain transaction generated by a first party and including an identifier, and obtaining the identifier from the first party includes obtaining the identifier from the third blockchain transaction.

[0169] Statement 18. The method according to any one of Statements 12 to 17, wherein a first key generation party has a first public key, and the first blockchain transaction includes a second output locked to the first public key of the first key generation party.

[0170] The first and second outputs may be the same output. Alternatively, the first and second outputs may be different outputs.

[0171] Statement 19. The method according to Statement 18, including: a) referring to the second output of the first blockchain transaction, and b) generating a fourth blockchain transaction including an input including a signature generated based on the private key corresponding to the public key of the first key generation party, and sending the fourth blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0172] Statement 20. The method according to any one of Statements 12 to 19, wherein a first party has a first public key, and the first blockchain transaction includes a second output locked to the first public key of the first party.

[0173] Statement 21. The method according to any one of Statements 12 to 20, wherein the blockchain includes a fifth blockchain transaction including a partial ID-based public key, and obtaining the partial ID-based public key includes obtaining the partial ID-based public key from the fifth blockchain transaction.

[0174] Statement 22. A method as described in any of Statements 12 to 21, including the following: Generating a sixth blockchain transaction that includes an output including a private key share, wherein transmitting the private key share to the first party includes transmitting the sixth blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0175] Statement 23. The method according to Statement 22, wherein the private key share is transmitted in an encrypted form.

[0176] Statement 24. A method as described in any of Statements 12 to 23, including the following: Generating a seventh blockchain transaction that includes an output including a set of parameters used to generate an ID-based public key, and Transmitting the seventh blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0177] The seventh blockchain transaction may include an identifier of the first blockchain transaction.

[0178] Statement 25. The method according to Statement 24, wherein the partial ID-based public key is generated based on a plurality of public key shares, each public key share is generated by one of a set of key generation parties, and the seventh blockchain transaction includes a set of parameters used by each respective key generation party to generate the ID-based public key.

[0179] Statement 26. The method according to Statement 24 or Statement 25, wherein the first key generation party is a mining node of the blockchain network and the seventh blockchain transaction is a generation transaction.

[0180] By using a generation (i.e., coinbase) transaction to record the identifier of the first blockchain transaction and the parameters used to generate the ID-based key, the trust in the PoW indicated by the mining node can be delegated to the trust in the generated cryptographic key, so the mining node can be regarded as a trusted certification authority.

[0181] Statement 27. A computer device comprising: A memory comprising one or more memory units, and A processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, and the code, when on the processing device, is configured to execute the method described in any of Statements 1 to 26.

[0182] Statement 28. A computer program embodied on a computer-readable storage and configured to execute the method described in any of Statements 1 to 26 when executed on the computer device of Statement 27.

[0183] According to another aspect of the teachings disclosed herein, a method may be provided that includes actions of a first party and a key generation party.

[0184] According to another aspect of the teachings disclosed herein, a system may be provided that includes computer devices of a first party and a key generation party.

[0185] Other variations may become apparent to those skilled in the art given the disclosure herein. The scope of this disclosure is not limited by the disclosed embodiments, but only by the appended claims.

Claims

1. 1. A computer-implemented method for generating an identity (ID)-based encryption key, the method being performed by a first party computing device having a personal identifier, the method comprising: obtaining, by the computer device, a set of private key shares and a corresponding set of public key shares, each private key share generated based on the individual identifier, at least one of the set of private key shares generated by a respective one of a set of key generation parties; generating, by said computing device, an identity-based private key based on each of one or more of said private key shares; generating, by the computing device, a partial identity-based public key, the partial identity-based public key being generated based on each of the set of corresponding public key shares; sending, by the computing device, the partial identity-based public key to at least one of the set of key-generation parties for generating an identity-based public key, the identity-based public key including the personal identifier and the partial identity-based public key; and / or generating, by the computing device, the identity-based public key, the identity-based public key including the personal identifier and the partial identity-based public key; A method comprising:

2. A first output of a first blockchain transaction includes the identity-based public key, the identity-based public key including the individual identifier and the partial identity-based public key; and The method comprises: obtaining the identity-based public key from the first blockchain transaction; The method of claim 1.

3. The step of obtaining the identity-based public key from the first blockchain transaction includes: obtaining a transaction identifier for the first blockchain transaction from at least one of the one or more key generating parties; and retrieving the first blockchain transaction from a blockchain on which the first blockchain transaction is recorded using the transaction identifier; The method of claim 2 , comprising:

4. The method comprises: obtaining, by the computing device, the identity-based public key from at least one of the set of key-generation parties; The method according to any one of claims 1 to 3, comprising:

5. The method comprises: encrypting, by the computing device, a first message using the identity-based public key to generate a first encrypted message; sending, by the computing device, the first encrypted message to a second party and / or generating a second blockchain transaction including an output that includes the first encrypted message; The method of any one of claims 1 to 4, comprising:

6. The method comprises: obtaining, by the computing device, a second encrypted message encrypted using the identity-based public key; and decrypting, by the computing device, the second encrypted message using the private key to reveal a second message; The method of any one of claims 1 to 5, comprising:

7. The method comprises: transmitting, by the computing device, the personal identifier to at least one of the one or more key-generation parties; The method of any one of claims 1 to 6, comprising:

8. The step of transmitting the personal identifier comprises: generating a third blockchain transaction including an output that includes the individual identifier; and transmitting the third blockchain transaction to one or more nodes of a blockchain network for inclusion in the blockchain; The method of claim 7, comprising:

9. the first party has a first public key, the first blockchain transaction includes a second output locked to the first public key of the first party, and the method further comprises: generating, by the computer device, a fourth blockchain transaction that a) references the second output of the first blockchain transaction, and b) includes an input that includes a signature generated based on a private key corresponding to the first public key of the first party; and transmitting, by the computer device, the fourth blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain; The method of claim 2 , comprising:

10. The step of transmitting the partial ID-based public key to the at least one of the set of key-generation parties comprises: generating a fifth blockchain transaction including an output that includes the partial identity-based public key; and transmitting the fifth blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain; 10. The method of claim 1 , comprising:

11. the first party's identifier comprises one or more of the first party's name and / or address, the first party's email address, a phone number, a passport number, a driver's license number, a social media profile, a date of birth, and a group member identifier; 11. The method according to any one of claims 1 to 10.

12. 1. A computer-implemented method for generating an identity (ID)-based encryption key, the method being performed by a computing device that is a first key-generating party, the first party having a personal identifier, the method comprising: transmitting, by the computing device, a private key share to the first party, the private key share being generated based on the personal identifier and having a corresponding public key share; obtaining, by the computing device, a partial identity-based public key, the partial identity-based public key being generated based on the corresponding public key shares; generating and / or obtaining, by the computing device, an identity-based public key, the identity-based public key being generated based on the partial identity-based public key and the personal identifier; and generating, by the computing device, a first blockchain transaction including a first output that includes the identity-based public key; A method comprising:

13. The method according to claim 1, transmitting, by the computer device, the first blockchain transaction to one or more nodes of a blockchain network for inclusion in a blockchain; The method of claim 12, comprising:

14. The method according to claim 1, transmitting, by the computer device, the first blockchain transaction to the first party; The method of claim 12, comprising:

15. the first output of the first blockchain transaction is an unusable output; 15. The method according to any one of claims 12 to 14.

16. The method according to claim 1, obtaining, by the computing device, the personal identifier from the first party; 16. The method of any one of claims 13 to 15, comprising:

17. The blockchain includes a third blockchain transaction generated by the first party and including the personal identifier; and The step of obtaining the personal identifier from the first party includes obtaining the personal identifier from the third blockchain transaction.

17. The method of claim 16.

18. the first key generation party has a first public key; and the first blockchain transaction includes a second output locked to the first public key of the first key generating party; 18. The method according to any one of claims 12 to 17.

19. The method according to claim 1, generating, by the computer device, a fourth blockchain transaction that a) references the second output of the first blockchain transaction, and b) includes an input that includes a signature generated based on a private key corresponding to the public key of the first key generation party; and transmitting, by the computer device, the fourth blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain; 20. The method of claim 18, comprising:

20. the first party has a first public key; and the first blockchain transaction includes a second output locked to the first public key of the first party; 20. The method according to any one of claims 12 to 19.

21. the blockchain includes a fifth blockchain transaction that includes the partial identity-based public key; The step of obtaining the partial identity-based public key includes obtaining the partial identity-based public key from the fifth blockchain transaction.

21. The method according to any one of claims 12 to 20.

22. The method according to claim 21, generating, by the computing device, a sixth blockchain transaction including an output including the private key share; the step of transmitting the private key share to the first party comprises transmitting the sixth blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

22. The method according to any one of claims 12 to 21.

23. The private key shares are transmitted in encrypted form.

23. The method of claim 22.

24. The method according to claim 2, generating, by the computing device, a seventh blockchain transaction including an output that includes the set of parameters used to generate the identity-based public key; and transmitting, by the computer device, the seventh blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain; 24. The method of any one of claims 12 to 23, comprising:

25. The partial ID-based public key is generated based on a plurality of public key shares; Each public key share is generated by a respective one of the set of key generation parties, and the seventh blockchain transaction includes the set of parameters used by each respective key generating party to generate the identity-based public key; 25. The method of claim 24.

26. The first key-generating party is a mining node of the blockchain network; and The seventh blockchain transaction is a creation transaction.

26. The method of claim 24 or 25.

27. 1. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units, the memory storing code configured to be executed on the processing unit; The code, when executed on the processing device, is configured to perform the method of any one of claims 1 to 26. Computer equipment.

28. stored on a computer readable storage device; and 27. A method for executing a method according to any one of claims 1 to 26, comprising: Computer program.

Images