Identity-based public key generation protocol

Abstract

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

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a method of generating an encryption key based on a user identity. BACKGROUND

[0002] A blockchain refers to a form of distributed data structure in which a duplicate is maintained amongst a plurality of nodes in a peer-to-peer (P2P) network. The blockchain includes a chain of blocks, with each block including one or more transactions. Each transaction can reference a previous transaction in the sequence, which can extend over one or more blocks. Transactions can be included in a new block by being submitted to the network for inclusion via a process known as "mining", which involves each of a plurality of mining nodes competing to perform a proof-of-work, i.e. to solve a cryptographic puzzle based on a pool of unspent transactions waiting to be included in a block.

[0003] Transactions in a blockchain are typically used to transfer a digital asset, i.e. data used as a means of value storage. However, additional functionality can be implemented on a blockchain to sit on top of the blockchain. For example, a blockchain protocol can allow additional user data to be stored in a transaction output. Modern blockchains have an increasing maximum data capacity that can be stored in a single transaction, enabling more complex data to be incorporated. For example, this can be used to store electronic documents, or even audio or video data in a blockchain.

[0004] Each node in the network can have any one, two or all of the following three roles: forwarding, mining and storage. Forwarding nodes propagate transactions amongst the network nodes. Mining nodes mine transactions into blocks. Storage nodes each store their own copy of the mined blocks in the blockchain. To get a transaction recorded in the blockchain, a party sends the transaction to one of the nodes in the network for propagation. Mining nodes that receive the transaction can compete to mine the transaction into a new block. Each node is configured to obey the same node protocol, which will include one or more conditions for validating a transaction as valid. Invalid transactions will not be propagated or mined into a block. Assuming a transaction has been validated as valid, and thus accepted on the blockchain, the additional user data will therefore continue to be stored at each of the nodes in the P2P network as an unalterable public record. SUMMARY

[0005] Identity-based encryption (IBE) is a type of public key encryption system that uses a user's identity (e.g. their email address) as their public key. A technical challenge with IBE is deriving a corresponding private key from the public key. To overcome this, a trusted third party (TTP) is typically introduced to generate a user's private key from a master private key (known only to the TTP) and the user's identity. However, a problem with this scheme is that the TTP knows the user's private key and is therefore able to decrypt messages that have been encrypted using the user's public key.

[0006] According to an aspect disclosed herein, there is provided a computer- implemented method for generating an identity-based encryption key, the method being performed by a first party having a personal identifier and comprising: obtaining a set of private key shares and a set of corresponding public key shares, wherein each private key share is generated based on the personal identifier, at least one of the set of private key shares being 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 partially identity-based public key, wherein the partially identity-based public key is generated based on each of the set of corresponding public key shares; transmitting the partially 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, wherein the identity-based public key comprises the personal identifier and the partially identity-based public key.

[0007] According to another aspect disclosed herein, there is provided a computer- implemented method for generating an identity-based encryption key, wherein a first party has a personal identifier, the method being performed by a first key generating party and comprising: transmitting a private key share to the first party, wherein the private key share is generated based on the personal identifier and has a corresponding public key share; obtaining a partially identity-based public key, wherein the partially identity-based public key is generated based on the corresponding public key share; generating and / or obtaining the identity-based public key, wherein the identity-based public key is generated based on the partially identity-based public key and the personal identifier; generating a first blockchain transaction comprising a first output, the first output comprising the identity-based public key.

[0008] The generation of one's own private key is now at least partially in the hands of the user (first party) and not in the hands of the TTP that generates the user's private key. The user receives one or more private key shares and uses these to generate the private key. Each key generating party, also referred to as a private key generator (PKG), only knows the private key share that it generated itself and thus 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 a private key share to the private key. The PKG (equivalent to the TTP) becomes less fully trusted because the user alone knows the user's private key if the private key share holders do not collude. If the user is also a private key share holder, one can completely dispense with trust in any third party, or more precisely, trust in other private key share holders.

[0009] One, some or all of the PKGs generate identity-based public keys (i.e. IBE keys) and store the IBE keys on the blockchain in a blockchain transaction, hereafter referred to as a "validity check transaction" (VCT). The VCT is visible in the set of unspent transaction outputs (UTXOs) of the blockchain, allowing interested parties to view the IBE keys and check whether the IBE is still valid. In essence, the set of UTXOs acts as a whitelist of valid keys. If an IBE key (or more accurately, the corresponding private key) is compromised or needs to be revoked for other reasons, then a user and / or PKG can spend the VCT to remove the IBE key from the set of UTXOs. Then, when an interested party wishes to check whether an IBE key is valid, then the IBE key is no longer seen in the set of UTXOs and this is interpreted as the IBE key being invalid. Similarly, an IBE can be updated by sending a new VCT to the blockchain spending a previous VCT. Spending a VCT output provides an efficient way to immediately revoke a key. BRIEF DESCRIPTION OF DRAWINGS

[0010] To assist in the understanding of embodiments of the present disclosure and how such embodiments can be implemented in practice, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0011] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

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

[0013] Figure 3 is a schematic block diagram of another system for implementing a blockchain;

[0014] Figure 4 is a schematic block diagram of node software for processing transactions according to a node protocol based on an output-based model;

[0015] Figure 5 is a schematic block diagram of an example system for generating public keys based on an identifier of a party;

[0016] Figure 6 is a schematic block diagram of another example system for generating public keys based on an identifier of a party;

[0017] Figure 7 is a sequence diagram of an example method of requesting an identity-based public key from a key generation party;

[0018] Figure 8a is a sequence diagram of an example method of sending a message encrypted using an identity-based public key;

[0019] Figure 8bis a sequence diagram of an exemplary method of decrypting a message that has been encrypted using identity-based public key encryption. DETAILED DESCRIPTION

[0020] Exemplary System Overview

[0021] Figure 1 An exemplary system 100 for implementing a blockchain 150 is generally shown. The system 100 includes a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a computer device of a peer, different nodes 104 belonging to different peers. Each node 104 includes a processing apparatus including one or more processors, such as one or more central processing units (CPUs), accelerator processors, special-purpose application processors, and / or field-programmable gate arrays (FPGAs). Each node also includes a memory, i.e., a computer-readable memory in the form of a non-transitory computer-readable medium. The memory can include one or more memory units in the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROM), and / or optical media such as optical disk drives.

[0022] The blockchain 150 includes a series of data blocks 151, with a respective copy of the blockchain 150 being maintained at each of a plurality of nodes in a P2P network 160. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses one particular transaction protocol throughout. In one common transaction protocol, each transaction 152 has a data structure that includes at least one input and at least one output. Each output specifies an amount representing a value of a digital asset belonging to the user 103 whose signature is required to unlock the output, thereby to redeem or spend. Each input points to an output of a previous transaction 152, thereby linking the transactions.

[0023] At least some of the nodes 104 play the role of forwarding nodes 104F, which forward and thus propagate transactions 152. At least some of the nodes 104 play the role of miners 104M that mine blocks 151. At least some of the nodes 104 play the role of storage nodes 104S (sometimes also called “full copy” nodes), each of which stores a respective copy of the same blockchain 150 in a respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 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.

[0024] In a given current transaction 152j, the input (or each input) includes a pointer that references an output of a previous transaction 152i in the sequence of transactions, specifying that the output is to be redeemed or “spent” in the current transaction 152j. In general, the current transaction can be any transaction in the pool 154 or any block 151. Although to ensure that the current transaction is valid, the previous transaction 152i will need to exist and be validated, the previous transaction 152i need not exist at the time the current transaction 152j is created or even sent to the network 106. Thus, “previous” refers to a predecessor in the logical sequence linked by the pointers, not necessarily the time of creation or sending in the temporal sequence, and thus does not necessarily exclude the possibility of out-of-order creation or sending of transactions 152i, 152j (see discussion below regarding orphan transactions). The previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0025] The input of the current transaction 152j also includes a signature of the user 103a to which the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, a transaction 152 can have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for a change). In some cases, a transaction can also have multiple inputs to aggregate amounts from multiple outputs of one or more previous transactions and redistribute to one or more outputs of the current transaction.

[0026] The above can be referred to as an“output-based” transaction protocol, sometimes also referred to as an unspent transaction output (UTXO) protocol (where the outputs are referred to as UTXOs). A user’s total balance is not defined by any one number stored in the blockchain; instead, a user needs a special“wallet” application 105 to collate all the UTXO values for that user, which are scattered across many different transactions 152 of the blockchain 151.

[0027] As part of an account-based transaction model, another type of transaction protocol can be referred to as an“account-based” protocol. In the account-based case, each transaction does not define the amount of the transfer by reference to the UTXO of a previous transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored separately by the miners into the blockchain and is constantly updated. In such systems, transactions are ordered using the running transaction record of the account (also referred to as the“position”). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field can also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0028] Regardless of the type of transaction protocol employed, when a user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal 102 to one of the nodes 104 of the P2P network 106 (now typically a server or data centre, but in principle could 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 will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the overall transaction model. The node protocol typically requires the node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the case of an output-based model, this can include checking that the user cryptographic signature contained in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i that the new transaction spends, where the condition 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 points to. In some transaction protocols, the condition can be defined at least in part by a custom script contained in the input and / or output. Alternatively, this can be determined solely by the node protocol, or can be determined by a combination thereof. Regardless of which approach is taken, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of nodes 104.

[0029] In an output-based model, the definition of whether a given output (e.g. UTXO) is spent is that, according to the node protocol, it is validly redeemed by an input of another subsequent transaction 152j. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it seeks to spend or redeem has not already been spent / redeemed by another valid transaction. Again, if invalid, the transaction 152j will not propagate or be recorded in the blockchain. This prevents double spending, i.e. spending the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by maintaining an account balance. Because there is again a defined order of transactions, the account balance has a single defined state at any time.

[0030] In addition to verification, at least some of the nodes 104M compete to create the transaction blocks in a process known as mining, which is based on a "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 in the pool 154 by trying to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with the pool 154 and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition can be that the output of the hash has a certain predefined number of leading zeros. The hash function has the property that its output is unpredictable with respect to its input. Thus, this search can only be performed by brute force, consuming a large amount of processing resources at each node 104M trying to solve the puzzle.

[0031] The first miner node 104M to solve the puzzle announces the solution of the puzzle on the network 106, providing the solution as proof, and then other nodes 104 in the network can easily check the solution (once the solution of the hash is given, it can be directly checked whether the solution makes the output of the hash satisfy the condition). Based on the announced solution of the winner having been checked at each such node, the pool of transactions 154 for which the winner has solved the puzzle is then recorded in the blockchain 150 as a new block 151 by at least some of the nodes 104 acting as storage nodes 104S. The block pointer 155 is also assigned to the new block 151n pointing to a previously created block 151n-1 in the blockchain. The proof of work helps to reduce the risk of double spending, because creating a new block 151 requires a lot of work, and since any block containing a double spend is likely to be rejected by other nodes 104, mining nodes 104M are incentivized not to allow double spending in their blocks. Once created, a block 151 cannot be modified, because it is identified and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes an order to the blocks 151. Since the transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0032] It should be noted that different miners 104M competing to solve a given puzzle can do so based on different snapshots of the pool of unmined transactions 154 at any given time, depending on when they start searching for a solution. The person who solves the respective puzzle first defines the transactions 152 included in the new block 151n and updates the current pool of unmined transactions 154. The miners 104M then continue to compete to create blocks from the newly defined pool of uncompleted transactions 154, and so on. In addition, there are protocols for resolving any "forks" that can occur, where two miners 104M solve the puzzle within a short time of each other, propagating conflicting views of the blockchain. In short, the fork direction that is longest becomes the final blockchain 150.

[0033] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a new value of digital asset (as opposed to a normal transaction that transfers an amount of digital asset from one user to another). The winning node is thus said to have "mined" a quantity of digital asset. This special type of transaction is sometimes called a "generation" transaction, which automatically forms part of a new block 151n. This reward incentivizes the miners 104M to compete in the proof-of-work. Typically, the regular (non-generation) transactions 152 will also specify an additional transaction fee in one of their outputs to further reward the winning miner 104M that creates the block 151n in which they are included.

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

[0035] The memory of each node 104 stores software configured to run on the processing device of the node 104 to perform its respective role and process transactions 152 according to the node protocol. It will be appreciated that any action attributed herein to a node 104 can be performed by software running on the processing device of the respective computer device. Furthermore, the term "blockchain" used herein is a generic term for the general class of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0036] Each of the parties 103 in the role of consuming users has a computer device 102 connected to the network 101. They act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily run a mining protocol. Two such parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be appreciated that more such parties 103 and their respective computer devices 102 can exist and participate in the system, but are not illustrated for the sake of convenience. Each party 103 can be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limited to Alice or Bob and any reference herein to Alice or Bob can be replaced with “first party” and “second party” respectively.

[0037] The computer device 102 of each party 103 comprises a respective processing apparatus comprising one or more processors, for example one or more CPUs, graphics processing units (GPUs), other accelerator processors, application specific processors, and / or FPGAs. The computer device 102 of each party 103 also comprises a memory, i.e. a computer-readable storage in the form of a non-transitory computer-readable medium. This memory can comprise one or more memory units in the form of one or more memory media, for example magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROM, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software comprising at least one respective instance of a client application 105 arranged to run on the processing apparatus. It will be appreciated that any action attributed herein to a given party 103 can be performed by software running on the processing apparatus of the respective computer device 102. The computer device 102 of each party 103 comprises at least one user terminal, for example a desktop or laptop computer, a tablet computer, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 can also comprise one or more other network resources, such as cloud computing resources accessed through the user terminal.

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

[0039] The client application 105 includes at least a "wallet" functionality. This has two main functions. One of these functions is to enable the corresponding user party 103 to create, sign and send transactions 152 that are intended to propagate throughout the network of nodes 104 and thus be included in the blockchain 150. The other function is to report to the corresponding party the amount of digital assets it currently holds. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant party that are scattered throughout the blockchain 150.

[0040] The instance of the client application 105 on each computer device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact one, some or all of the storage nodes 104 to query the blockchain 150 for any transactions of which the corresponding party 103 is a recipient (or indeed inspect the transactions of other parties in the blockchain 150, as in embodiments the blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transactions 152 in accordance with a transaction protocol. Each node 104 runs software that is configured to validate transactions 152 as valid in accordance with a node protocol, and in the case of a forwarding node 104F to forward transactions 152 for propagation of such transactions throughout the network 106. The transaction protocol and the node protocol correspond to each other, a given transaction protocol and a given node protocol together implementing a given transaction model. All transactions 152 in the blockchain 150 are in accordance with the same transaction protocol (although the transaction protocol can allow for different sub-types of transactions within it). All nodes 104 in the network 106 are in accordance with the same node protocol (although it can distinguish between handling different sub-types of transactions according to rules defined for that sub-type, and different nodes can also play different roles and thus implement different corresponding aspects of the protocol).

[0041] As mentioned above, the blockchain 150 comprises a chain of blocks 151, where each block 151 comprises a set of one or more transactions 152 created through a proof-of-work process as described previously. Each block 151 also comprises a block pointer 155, which points to a previously created block 151 in the blockchain, to define the order of the blocks 151. The blockchain 150 also comprises a pool of valid transactions 154, which await inclusion in a new block through the proof-of-work process. Each transaction 152 (except the genesis transaction) comprises a pointer to a previous transaction, to define the order of the sequence of transactions (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to a genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 early in the blockchain 150 point to the genesis block 153, rather than a previous transaction.

[0042] When a given party 103 (say, Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends the transaction 152 from the client application 105 to one of the one or more forwarding nodes 104F to which she is connected. This could be, for example, the forwarding node 104F to which Alice’s computer 102 has the best or most recent connection. 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 to become “valid”, examples of which are discussed in more detail later. In some transaction protocols, the conditions for validity can be configured on a per-transaction basis by scripts included in the transaction 152. Alternatively, the conditions can simply be built-in functions of the node protocol, or defined by a combination of scripts and node protocol.

[0043] If the newly received transaction 152j passes the validity test (i.e. the conditions for being “valid”), any storage node 104S that receives the transaction 152j will add the new valid transaction 152 to the pool 154 in the copy of the blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives the transaction 152j will subsequently propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it assumes that the transaction 152j is valid, which means that the transaction will soon be propagated throughout the P2P network 106.

[0044] Once in the pool 154 in the copy of the blockchain 150 maintained at one or more of the storage nodes 104, the miner node 104M will start competing to solve a proof-of-work puzzle in respect of the latest version of the pool 154 including the new transaction 152 (other miners 104M can continue trying to solve the puzzle based on older views of the pool 154, but the first to solve the puzzle will define the end of the next new block 151 and the start of the new pool 154, eventually someone will solve the puzzle in respect of a portion of the pool 154 including Alice's transaction 152j). Once the pool 154 including the new transaction 152j has completed the proof-of-work, it becomes immutable as part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also recorded immutably.

[0045] UTXO-based model

[0046] Figure 2 An example transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 (Tx for short) is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. But this is not limited to all possible embodiments.

[0047] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure which includes one or more inputs 202 and one or more outputs 203. Each output 203 can comprise an unspent transaction output (UTXO) which can be used as the source of an input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO specifies a quantity of a digital asset (a store of value). It can also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure can also include a header 201 which can include an indicator of the size of the input field 202 and the output field 203. The header 201 can also include an ID of the transaction. In embodiments, the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the miners 104M.

[0048] It is noted that while each output in Figure 2 is shown as a UTXO, a transaction can additionally or alternatively include one or more unspendable transaction outputs.

[0049] Say Alice 103a wishes to create a transaction 152 transferring a quantity of a relevant digital asset to Bob 103b. In Figure 2In this case, Alice's new transaction 152j is labeled "Tx1." This new transaction takes the amount of digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least some of such amount to Bob. In this case, the previous transaction 152i is labeled "Tx0." Tx0 and Tx1 are arbitrary labels, which do not necessarily imply that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to the next transaction in the pool 154. Tx1 can refer to any previous (i.e., antecedent) transaction that still has an unspent output 203 locked to Alice. Figure 2 In this case, the previous transaction 152i is labeled "Tx0." Tx0 and Tx1 are arbitrary labels, which do not necessarily imply that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to the next transaction in the pool 154. Tx1 can refer to any previous (i.e., antecedent) transaction that still has an unspent output 203 locked to Alice.

[0050] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 can already be valid and included in the blockchain 150. It can at this point be included in one of the blocks 151, or it can still be in the pool 154 waiting, in which case it will soon be included in a new block 151. Alternatively, Tx0 and Tx1 can be created and sent to the network 102 together; or Tx0 can even be sent after Tx1, if the node protocol allows buffering of "orphan" transactions. The terms "previous" and "subsequent" as used in the context of the sequence of transactions herein refer to the order of the transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, and so on). They can equally be replaced by "predecessor" and "successor," "antecedent" and "descendant," or "parent" and "child," and so on. This does not necessarily refer to the order of their creation, sending to the network 106, or reaching any given node 104. However, a subsequent transaction (a descendant transaction or "child transaction") that points to a previous transaction (an antecedent transaction or "parent transaction") is not valid unless the parent transaction is valid. A child transaction that reaches a node 104 before the parent transaction is considered an orphan transaction. Depending on the node protocol and / or miner behavior, it can be discarded or buffered for some time, waiting for the parent transaction.

[0051] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital asset that the UTXO represents, and a locking script defining a condition that must be satisfied by an unlocking script in the input 202 of a subsequent transaction for the subsequent transaction to be valid, thus successfully redeeming the UTXO. Typically, the locking script will lock the amount to a specific party (the beneficiary of the transaction of the amount). That is, the locking script defines an unlocking condition, which typically includes the condition that the unlocking script in the input of the subsequent transaction includes a cryptographic signature of the party to which the previous transaction is locked.

[0052] A locking script (also known as scriptPubKey) is a piece of code written in a domain specific language recognised by the node protocol. A specific example of such a language is known as "Script" (S capitalised). The locking script specifies the information required to spend the transaction output 203, for example a requirement for Alice's signature. An unlocking script appears in the input 202 of a transaction. An unlocking script (also known as scriptSig) is a piece of code written in a domain specific language that provides the information required to satisfy the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of a transaction.

[0053] Thus in the illustrated example, the UTXO0 in the output 203 of Tx0 comprises a locking script [Checksig P A ] that requires Alice's signature Sig P A to redeem the UTXO0 (strictly speaking, to make a subsequent transaction attempting to redeem the UTXO0 valid). The [Checksig P A ] contains the public key P A from Alice's public-private key pair. The input 202 of Tx1 comprises a pointer to Tx1 (for example by its transaction ID (TxID0), which in embodiments is the hash of the entire transaction Tx0). The input 202 of Tx1 comprises an index identifying the UTXO0 in Tx0 to identify it amongst any other possible outputs of Tx0. The input 202 of Tx1 further comprises an unlocking script <Sig P A >, which comprises Alice's cryptographic signature created by Alice applying the private key of her key pair to a predetermined piece of data (sometimes referred to in cryptography as a "message"). Alice needs to sign the data (or "message") for which a valid signature is required to be provided by the locking script, the node protocol or a combination thereof.

[0054] When the new transaction Tx1 arrives at the node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions can comprise one or more criteria). In embodiments, this involves concatenating the two scripts:

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

[0056] where "||" denotes concatenation, "<...>" denotes placing data on the stack, and "[...]" denotes a function consisting of an unlocking script (in this example, referring to a stack-based language). Again, the scripts can be run one after the other using a common stack, rather than concatenating the scripts. Either way, when run together, the scripts use Alice's public key P A (included in the locking script of the output of TxO) to authenticate the signature when authenticating that the locking script in the input of Tx1 contains the data that Alice signed as part of the message. The intended part of the data itself ("message") also needs to be included in TxO in order to perform this authentication. In embodiments, the signed data includes the entire TxO (so that there is no need to include a separate element to specify the signed part of the data in cleartext, as it is already present).

[0057] The skilled person will be familiar with the details of authentication by public-private cryptography. Essentially, if Alice has signed a message by encrypting it using her private key, then given Alice's public key and the message in cleartext (the unencrypted message), another entity such as a node 104 can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value and labelling this to the cleartext version of the message as the signature, enabling any holder of the public key to authenticate the signature.

[0058] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of TxO (so, in the illustrated example, if Alice's signature is provided in Tx1 and authenticated), then the node 104 considers Tx1 to be valid. If it is a mining node 104M, this means that it will add it to the pool of transactions 154 awaiting proof-of-work. If it is a forwarding node 104F, it will forward the transaction Tx1 to one or more other nodes 104 in the network 106, so that it will be propagated throughout the network. Once Tx1 is valid and included in the blockchain 150, this defines UTXO0 in TxO as spent. Note that Tx1 is only valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Therefore, the node 104 also needs to check that the UTXO referenced in the previous transaction TxO has not already been spent (has already formed a valid input to another valid transaction). This is one of the reasons why the defined order imposed by the blockchain 150 on transactions 152 is important. In practice, a given node 104 can maintain a separate database marking UTXOs 203 of transactions 152 that have been spent, but ultimately whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in the blockchain 150.

[0059] Note that in the UTXO-based transaction model, a given UTXO needs to be spent as a whole. It is not possible to "leave behind" part of the amount defined in the UTXO as spent, while spending another part. But the amount of the UTXO can be split between multiple outputs of the next transaction. For example, the amount defined in UTXOo of Txo can be split between multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXOo, she can use the remainder to find change in a second output of Tx1, or to pay another party.

[0060] In practice, Alice will also need to include a fee to the winning miner, as the reward coins for generating a transaction are often not enough to incentivize mining on their own. If Alice does not include a fee to the miner, Txo can be rejected by the miner node 104M, and thus, although technically valid, will not propagate and be included in the blockchain 150 (miners 104M are not forced by the miner protocol to accept transactions 152 if they do not wish to). In some protocols, the mining fee does not need its own separate output 203 (i.e. does not need a separate UTXO). Rather, any difference between the total amount pointed to by the inputs 202 in a given transaction 152 and the total amount specified by the outputs 203 is automatically provided to the winning miner 104. For example, assume that the pointer to UTXOo is the only input to Tx1, and that Tx1 has only one output, UTXO1. If the amount of the digital asset specified in UTXOo is greater than the amount specified in UTXO1, then the difference is automatically provided to the winning miner 104M. Alternatively or additionally, this does not necessarily preclude the miner fee being specified explicitly in one of the UTXOs 203 of its own transaction 152.

[0061] Note also that if the total amount specified in all of the outputs 203 of a given transaction 152 is greater than the total amount pointed to by all of its inputs 202, then this is another invalidity in most transaction models. Thus, such a transaction will not propagate or mine into a block 151.

[0062] Alice's and Bob's digital assets consist of the unspent UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party's 103 assets are spread out among the UTXOs of various transactions 152 throughout the blockchain 150. No location in the blockchain 150 stores a number defining the total balance of a given party 103. The role of the wallet functionality of the client application 105 is to collate the values of various UTXOs locked to the respective party and not spent in other subsequent transactions. This can be achieved by querying the copy of the blockchain 150 stored at any storage node 104S (e.g. the storage node 104S that is closest or best connected to the computer device 102 of the respective party).

[0063] Note that script code is often represented in schematic (i.e. non-precise language). For example, one can write [Checksig P A ] to represent [Checksig P A ] = OP_DUP OP_HASH160<H(Pa)> OP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to a specific opcode of the script language. OP_CHECKSIG (also "Checksig") is a script opcode that takes two inputs (a signature and a public key) and verifies the signature's validity using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrence of the signature ('sig') is removed from the script, but the additional requirements verified by the'sig' input remain in the transaction, such as a hash puzzle. As another example, OP_RETURN is a script language opcode used to create an unspendable output of a transaction, which can store metadata in the transaction, thereby immutably recording the metadata in the blockchain 150. For example, the metadata can include a file that needs to be stored in the blockchain.

[0064] signature P A is a digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In embodiments, for a given transaction, the signature will sign some of the transaction inputs, as well as all or some of the transaction outputs. The particular piece of the outputs that is signed depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature that selects which outputs are signed (and thus fixed at the time of signing).

[0065] The locking script, sometimes called "scriptPubKey", refers to the fact that it includes the public key of the party to whom the corresponding transaction is locked. The unlocking script, sometimes called "scriptSig", refers to the fact that it provides the corresponding signature. However, more generally, in all applications of the blockchain 150, the condition for UTXO redemption does not necessarily include authenticating a signature. More generally, the script language can be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" can be preferred.

[0066] Optional side channels

[0067] Figure 3 Another system 100 is shown for implementing the blockchain 150. This system 100 is similar to the system 100 described above, except that it has additional communication functionality. Figure 1The content shown is essentially the same. The client application on each of Alice's and Bob's computer devices 102a, 102b includes an additional communication functionality, respectively. That is, this enables Alice 103a to establish a side channel 301 separate from Bob 103b (at the instigation of either party or a third party). The side channel 301 enables data exchange independent of the P2P network. Such communication is sometimes referred to as "off-chain" communication. This can be employed, for example, when exchanging a transaction 152 between Alice and Bob that is not intended to be published to the P2P network 106 or mined into a block 150 yet, 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 terms, data content, etc.

[0068] The side channel 301 can be established over the same packet-switched network 101 as the P2P overlay network 106. Additionally or alternatively, the side channel 301 can be established over 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 connection between Alice's and Bob's devices 102a, 102b. In general, the side channel 301 as referred to herein can comprise any one or more links via one or more networking technologies or communication media for exchanging data "off-chain" (i.e. independent of the P2P overlay network 106). In case multiple links are used, the bundle or collection of the entire off-chain links can be referred to as the side channel 301. Thus, it is noted that while Alice and Bob exchange specific pieces of information or data or the like over the side channel 301, this does not necessarily mean that all of these pieces of data must be sent over the same link or even the same type of network.

[0069] Node software

[0070] Figure 4 An example of node software 400 running on each node 104 of the P2P network 106 in an example based on a UTXO or output-based model is shown. The node software 400 comprises a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a collection of one or more blockchain-related functional modules 405. At any given node 104, these modules can include any one, two, or all of the following three modules: a mining module 405M, a forwarding module 405F, and a storage module 405S (depending on the one or more roles of the node). The protocol engine 401 is configured to identify different fields of a transaction 152 and to process such fields according to the node protocol. When receiving a transaction 152m(Tx m-1 ) with an input pointing to an output (e.g. UTXO) of another previous transaction 152m-1(Txm When ), the protocol engine 401 identifier Tx m The unlock script is then passed to script engine 402. Protocol engine 401 is also based on Tx. m The pointer in the input is used to identify and retrieve Tx m-1 If Tx m-1 If it is not yet on blockchain 150, then Tx can be retrieved from the corresponding node's own pending transaction pool 154. m-1 Or, if Tx m-1 If it's already on blockchain 150, it can be retrieved from a copy of block 151 in blockchain 150 stored on the corresponding node or another node 104. Regardless of the method used, script engine 401 will identify Tx. m-1 The pointer points to the locked script in the output and passes it to the script engine 402.

[0071] Therefore, script engine 402 has Tx m-1 The locking script and from Tx m The corresponding input unlock script. For example, Figure 4 The examples Tx1 and Tx2 shown are applicable, but the same applies to any transaction pair, such as Tx0 and Tx1. As previously mentioned, script engine 402 runs two scripts simultaneously, which will involve placing data onto stack 403 and retrieving data from that stack according to the stack-based scripting language being used (e.g., script).

[0072] By running the scripts simultaneously, the script engine 402 determines whether the unlock script meets one or more criteria defined in the locking script, i.e., whether the unlock script unlocks the output including the locking script. The script engine 402 returns this determination to the protocol engine 401. If the script engine 402 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns the result "TRUE". Otherwise, it returns the result "FALSE".

[0073] In the output-based model, the result "TRUE" from script engine 402 is one of the conditions for transaction validity. Typically, one or more further protocol-level conditions evaluated by protocol engine 401 must also be met; for example, Tx m The total amount of digital assets pointed to in the output does not exceed the total amount specified in the input(s), and Tx m-1 The output pointed to by the transaction has not yet been spent by another valid transaction. Protocol engine 401 evaluates the results from script engine 402 along with one or more protocol-level conditions, and only when all of them are TRUE does protocol engine 401 verify transaction Tx. mValid. The protocol engine 401 outputs an indication of whether the transaction is valid to the application-level decision engine 404. Only if the Tx m is valid, the decision engine 404 can select one or both of the mining module 405M and the forwarding module 405F to execute their respective blockchain-related functions in relation to the Tx m . This can include: the mining module 405M, which adds the Tx m to the respective pool 154 of the node to mine into a block 151; and / or the forwarding module 405F, which forwards the Tx m to another node 104 in the P2P network 106. It should be noted, however, that in embodiments, while the decision engine 404 will not select to forward or mine invalid transactions, this does not necessarily mean that the decision engine must trigger mining or forwarding of a transaction just because the transaction is valid. Optionally, in embodiments, the decision engine 404 can apply one or more additional conditions before triggering one or both of these functions. For example, if the node is a mining node 104M, the decision engine can select to mine the transaction only if the transaction is valid and reserves enough mining fees.

[0074] It should also be noted that, in this document, the terms “TRUE” and “FALSE” are not necessarily limited to returning results represented in the form of a single binary number (bit) only, although this is indeed one possible implementation. More generally, “TRUE” can refer to any state that indicates a successful or affirmative result, while “FALSE” can refer to any state that indicates an unsuccessful or non-affirmative result. For example, in an account-based model (not shown), the result can be indicated as “TRUE” by a combination of implicit protocol-level verification of the signature by the node 104 and an additional affirmative output of the smart contract (the overall result is considered TRUE if both individual results are TRUE). Figure 4

[0075] Preliminaries

[0076] Public-key cryptography

[0077] Public-key cryptography (PKC) makes use of encryption schemes that guarantee confidentiality and digital signature schemes that guarantee authenticity and non-repudiation.

[0078] Public-key cryptography allows for confidential communication between any pair of players in a large group (especially in the absence of a dedicated channel for exchanging keys). Each player has a pair of keys: a secret private key for decryption; and a corresponding public key, which is public and used to encrypt messages sent to that player. For a player Alice, her private key can be given by sk Alice , while her public key can be given by PK Alice ​is given. Any player who wants to send a secret message m to Alice will use Alice's public key PK Alice to encrypt the message and generate a ciphertext c. This ciphertext should only be able to be decrypted using sk Alice to recover the plaintext.

[0079] c = E(m, PK Alice )

[0080] m = D(c, sk Alice )

[0081] To implement such a system, a trapdoor one-way function should be used when encrypting. A one-way function is a function that is easy to compute on a one-way x→f(x) but impossible to invert f(x)→x, i.e. it is easy to find f(x) given x, but impossible to find x given f(x) computationally. In a trapdoor one-way function, it is easy to find x given the additional information (trapdoor), so f(x, trapdoor)→x is feasible. Typically, the infeasibility conclusion is based on a result of a well-studied and computationally complex mathematical problem.

[0082] Before public key encryption, symmetric key encryption is used to provide confidential communication. In symmetric key encryption, the communicating parties will share a secret key that is used to encrypt and decrypt messages. Public key encryption, also known as asymmetric key encryption. A public key encryption scheme typically includes:

[0083] • Key generation

[0084] o Alice generates a private key sk Alice from a random pool.

[0085] o Alice derives her public key PK Alice from the private key and publishes it to the parties.

[0086] • Encryption

[0087] o Any member of a party uses PK Alice to encrypt a message m,

[0088] c = E(m, PK Alice )

[0089] • Decryption

[0090] o To decrypt a message, Alice uses her private key sk Alice ,

[0091] m = D(c, sk Alice )

[0092] To ensure the security of a public key encryption scheme, it must satisfy far more requirements than a symmetric key encryption system. These requirements include that it should be computationally impossible to find skAlice sk is derived from m Alice and given c should be computationally impossible to derive m even if the attacker can compute c for any m.

[0093] Due to these additional requirements, it is more difficult to design a secure, practical public-key encryption scheme than a symmetric-key encryption scheme. Typically, public-key encryption keys are several times larger than symmetric keys to achieve the same level of security. In addition, the encryption and decryption algorithms are slower than symmetric encryption algorithms. In practical systems, symmetric-key encryption is used to encrypt data, while public-key encryption is used at the beginning to exchange symmetric keys to be used.

[0094] Digital signatures

[0095] Trapdoor one-way functions can be used to construct digital signature schemes. In a digital signature setting, each player has its own secret private key for signing and a corresponding public key for verification. A digital signature scheme includes:

[0096] • Key generation

[0097] o Alice generates a private key sk from a random pool Alice .

[0098] o Alice derives her public key PK from the private key sk Alice and publishes it to the parties.

[0099] • Signature

[0100] o Alice signs a message m using her private key sk Alice to obtain a signature s,

[0101] s = Sign(m, sk Alice ),

[0102] • Verify signature

[0103] o Any party can verify the signature by running the following command:

[0104] Verify(m, s, PK Alice )

[0105] Note that the above system guarantees authenticity, non-repudiation, and integrity. This is because only the owner of the private key can choose the message and sign it, and generate a signature linked to the corresponding public key. The system provides integrity because if m or s is changed, verification will fail.

[0106] Public Key Infrastructure (PKI)

[0107] PKC solves the problem of key sharing in symmetric key settings to a large extent. However, there is still a problem of how to guarantee that Alice's public key belongs to Alice. If the public key is damaged by mistake, or any malicious player can replace Alice's public key with his own, they will be able to decrypt all messages sent to Alice and encrypted by the malicious player's public key. Furthermore, any other player cannot easily distinguish Alice's real key from the malicious player's key, because usually PKC is a random string of at least 500 bits. Alice is a random string of at least 500 bits.

[0108] This problem can be partially avoided by using digital certificates and PKI. A digital certificate mainly includes a message containing Alice's public key and Alice's identifier. The hash value of these fields is signed by a certificate authority (CA). A certificate authority is a trusted third party whose public key is known and fully trusted by all members of the party. Therefore, any member of the party can easily verify that the certificate is indeed signed by the CA. The CA will be responsible for ensuring that Alice's public key indeed belongs to Alice. If Alice can prove her public key using a certificate issued by a known CA, she can use her public key to receive encrypted messages, or even issue certificates to other players.

[0109] For a practical system, there is only one certificate authority, and the public key of the certificate authority is known to all members of the group. This CA can provide certificates to other CAs, which in turn can issue certificates to other players. For example, a web browser is pre-installed with the certificates of multiple CAs. All these certificates can act as the trust root of any https server. If the certificate provided by the server does not have a valid trust root for the CA, the browser can warn the user that the certificate cannot be verified as belonging to the https server being accessed.

[0110] The known certificate standard is the X.509 standard, which includes the following fields:

[0111] • Version

[0112] • Validity period (start date and end date)

[0113] • Certificate issuer

[0114] • Public key type, length and value

[0115] • Purpose (e.g., whether the certificate can be used to sign other certificates)

[0116] • Hash type and value, etc.

[0117] • Subject

[0118] Identity-based encryption (IBE)

[0119] Identity-based encryption (IBE) was proposed in the early 1980s. IBE is a public-key encryption scheme where the encryption key is an arbitrary string, such as an email address or phone number. In such a system, knowing Alice's email address is sufficient to send her encrypted messages. No certificate authority is required, nor is it necessary to communicate with Alice beforehand to obtain her public key.

[0120] Standard IBE systems still require a trusted third party, typically referred to as a "private key generator" (PKG). The IBE scheme employs the following algorithms:

[0121] Generate master key

[0122] οPKG generates the master private key sk from a random pool. master .

[0123] οPKG derives its own public key PK from its private key. master and PK master Released to all parties.

[0124] Generate subscriber keys

[0125] Alice chooses her public key ID Alice (For example, her email address, mobile phone number, etc.), and request the private key (i.e., the decryption key) from PKG.

[0126] οPKG from the master private key sk master And Alice's public key ID Alice The private key sk of Alice is generated in the middle. Alice and through a secure channel sk Alice Send to Alice.

[0127] ·encryption

[0128] Any party that wants to securely exchange messages with Alice can use Alice's public key ID. Alice ,use

[0129] c = E(m, ID) Alice )

[0130] Decryption

[0131] Alice used her private key sk Alice Decrypt message

[0132] m=D(c,sk Alice )

[0133] In IBE, the PKG knows all the private keys of all the users. In some applications, this is acceptable. For example, a company can use IBE to secure its employees and want to be able to access their encrypted data, delegate or revoke access by controlling their private keys.

[0134] Furthermore, IBE can be designed with multiple PKGs. As long as all the PKGs do not collude to reveal Alice's private key, Alice will be the only one who has the decryption key. The system needs at least one honest PKG.

[0135] In secure communication applications, IBE is used to exchange the keys of a symmetric encryption system. IEB is recommended for applications that require fast call setup, such as for emergency services.

[0136] As shown in the above IBE algorithm, a trusted third party PKG computes the private key sk Alice and passes it to the user. There is no guarantee that the PKG will not use the private key later. Assuming that the PKG can be fully trusted, from the attacker's point of view, the PKG acts 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 any benefits.

[0137] Bilinear mapping

[0138] Let G1 and G2 be two groups of order q for some large prime q. The Boneh-Franklin IBE scheme (BF-IBE) uses a bilinear mapping e: G1 x G1 → G2 between the two groups. The mapping must satisfy the following properties:

[0139] 1. Bilinearity: The mapping e: G1 x G1 → G2 is bilinear if e(aP, bQ) = e(P, Q) ab

[0140] for all P, Q ∈ G1 and all a, b.

[0141] 2. Non-degeneracy: The mapping does not send all pairs in G1 x G1 to the identity in G2. Note that since G1, G2 are groups of prime order, this means that if P is a generator of G1, then e(P, P) is a generator of G2.

[0142] 3. Computability: There is an efficient algorithm for computing e(P, Q) for any P, Q ∈ G1.

[0143] For any bilinear mapping satisfying the above properties, the difficulty of the discrete logarithm problem in G1 is no greater than the discrete logarithm problem in G2. In BF-IBE, G1 is an elliptic curve E / F p ​A subgroup of the additive group at the midpoint. The G2 group is a finite field. A subgroup of the multiplication group.

[0144] Boneh-Franklin IBE

[0145] The BF-IBE scheme is described below, where a single trusted third party (TTP) acts as the PKG. Assume the PKG uses the following parameters:

[0146] 1. A pair of groups (G1, G2) of prime order q;

[0147] 2. Bilinear pair e: G1×G1→G2;

[0148] 3. Generate point P∈G1;

[0149] 4. Four hash functions H2:G2→{0,1} n ,

[0150] H4:{0,1} n →{0,1} n .

[0151] It is important to note that {0,1} * Represents a binary string of arbitrary length, {0,1} n This represents a binary string of length n. G1 is a unitless variable. Therefore, H1 is {0,1}. * As input and output Any function of elements in H3. H3 is a function that maps a pair of binary strings, each of length n, to... Functions of elements in. It is a multiplicative group of order q, including Z q Elements in \{0} are elements without additive unit elements.

[0152] • Set Algorithm 1A

[0153] PKG runs this algorithm once:

[0154] 1. Select a random number

[0155] 2. Calculate P pub =s·P

[0156] s is the master secret, which should be known only to the PKG, and has a high degree of randomness. s can be obtained using a cryptographically secure pseudo-random generator (CSPRG).

[0157] Generate the key [Algorithm 2A]

[0158] Given a user identity ID A , the PKG runs this algorithm using the secret key s:

[0159] 1. Compute Q A = H1(ID A ), a point in G1.

[0160] 2. Return D A = s • Q A .

[0161] 3. The PKG sends D A to the user over a secure channel.

[0162] 4. The user's public key is ID A .

[0163] 5. The user's private key is D A .

[0164] • Encryption

Algorithm 3A

[0165] Given an identity ID A and the PKG's public key P pub , to encrypt a message m e {0,1} n , anyone can perform the following operations:

[0166] 1. Compute Q A = H1(ID A ).

[0167] 2. Choose a random number σ of n bits.

[0168] 3. Compute r = H3(σ, m).

[0169] 4. Compute the ciphertext c as a triple (U, V, W):

[0170] a. U = r • P;

[0171] b.

[0172] c.

[0173] • Decryption

Algorithm 4A

[0174] To decrypt a ciphertext c = (U, V, W), the user uses its private key D A and runs the following algorithm:

[0175] 1. Compute

[0176] 2. Compute

[0177] 3. Compute r' = H3(σ', m').

[0178] 4. Check the equation r' · P = U.

[0179] 5. Return m'.

[0180] Note that e(Q A ,P pub ) r = e(Q A ,s·P) r = e(Q A ,P) sr = e(s·Q A ,r·P) = e(D A ,U).

[0181] Updating the private key of a user implies that the public key of the user should also be updated. Since the public key is expected to be a constant string ID (e-mail address, mobile phone number), for each user, the key update can be achieved by concatenating the public key as an identifier constant string with a variable string. The variable string can represent a validity period, e.g. a timestamp.

[0182] Multi-PKG Boneh-Franklin IBE

[0183] The above IBE scheme can be generalized to have multiple PKGs in order to distribute the required trust over several PKGs, thus reducing the dependency on each individual PKG. Furthermore, the user (i.e. the owner of the identity) is now part of the group of PKGs, thus solving the problem of key escrow.

[0184] Assume that the PKGs use the following parameters:

[0185] 1. A pair of groups (G1, G2) of prime order q;

[0186] 2. A bilinear map e: G1x G1→ G2;

[0187] 3. A generator point P e G1;

[0188] 4. Four hash functions H1: {0,1} * → G1, H2: G2→ {0,1} n ,

[0189] H4: {0,1} n → {0,1} n .

[0190] • Set up (Algorithm 1B)

[0191] Each PKG independently runs this algorithm once:

[0192] 1. Choose a random number

[0193] 2. Compute P i = s i · P.

[0194] 3. Add P i to the parameters.

[0195] • Generate Key

Algorithm 2B

[0196] Given a user identity ID A , each PKG uses their partial secret key s i to independently run this algorithm:

[0197] 1. Compute Q A = H1(ID A ), a point in G1.

[0198] 2. Return D iA = s i · Q A to the owner of ID A over a secure channel.

[0199] When the user receives D iA from each PKG, the user runs the following algorithm:

[0200] 1. Choose a random number

[0201] 2. Compute s A = x A · ∑ i D iA .

[0202] 3. Compute X A = x A · P.

[0203] 4. Compute Y i = x A · ∑iP i .

[0204] 5. The private key is s A .

[0205] 6. The partial public key is (X A , Y A ).

[0206] • Encrypt

Algorithm 3B

[0207] Given an identity IDA and public key (X A , Y A ), before encrypting the message, one can verify the partial public key by checking the following equation:

[0208]

[0209] This equation checks the dependency between the user's public key and the PKG's public key, i.e. it verifies that Alice uses the PKG's parameters. However, this equation does not verify that ID A and (X A , Y A ) belong to Alice.

[0210] In order to encrypt a message m using the full identity-based public key (ID A , X A , Y A ), one needs to run the following algorithm using ID A and Y A simultaneously:

[0211] 1. Compute Q A = H1(ID A ).

[0212] 2. Choose a random number σ of n bits.

[0213] 3. Compute r = H3(σ, m).

[0214] 4. Compute the ciphertext c = (U, V, W) as a triple:

[0215] a. U = r • P;

[0216] b.

[0217] c.

[0218] Usually in PKI, the user's public key is signed by a CA. In this case, the verification of the user's public key is essentially the verification of the CA's digital signature. In this case, the verification refers to two bilinear pairings and one equation check. Moreover, since the user can generate its own secret value as a trade-off, one has to introduce the public key (X A , Y A ) in addition to the identity ID A . Depending on the scenario, this trade-off can be crucial, as it solves the key escrow problem, i.e. the trust problem.

[0219] It is also important to note that X A and ∑ i P iInstead, they are used to check that X A and Y A are generated from the same trusted PKG parameters. Note that if an eavesdropper ("Eve") claims to be Alice and sends Bob her X E , Y E after subscribing with the same PKG, this check will pass, but decryption will fail because Bob uses Q A . If Eve can change the PKG parameters, in particular ∑ i P i , then Eve can successfully impersonate Alice, but the present disclosure assumes that the PKG parameters can be obtained and checked by the parties in a secure manner for their authenticity and integrity. Thus, Eve will not be able to successfully carry out this attack.

[0220] In the case where the user is the PKG, the security system has a single PKG containing Alice. That is, one key share is generated by the PKG and the other key share is generated by the user.

[0221] • Decryption [Algorithm 4B]

[0222] To decrypt a ciphertext c = (U, V, W), the private key s A is used to run the following algorithm:

[0223] 1. Compute σ' = H2(U, V, W).

[0224] 2. Compute m' = H3(σ', s).

[0225] 3. Compute r' = H3(σ', m').

[0226] 4. Check that the equation r' · P = U holds.

[0227] 5. Return m'.

[0228] Note that if decryption is successful, then σ' = σ, σ' = σ, and r' = r, as for encryption.

[0229] Identity-based public key generation protocol

[0230] Embodiments of the present disclosure provide an identity-based public key generation protocol, or equivalently an identity-based encryption key generation protocol. In particular, an identity-based public key / encryption key is generated for a user based on a personal identifier of the user, thereby binding the key to the user identity. The personal identifier can include one or more of: name and / or address, email address, phone number, passport number, driver’s license number, national insurance number, social media profile, date of birth, etc. The personal identifier can also be an attribute, such as being a member of a certain group (e.g. police), being a person working in a certain department (e.g. human resources officer), being a person working on a certain project, or being a person who has passed a security check. It is noted that in the example of being a member of a group, any member of the group is able to decrypt a message encrypted using the identity-based public key, unless other identifiers or attributes are also used. For example, each member of the same group can be authorised to access the private key corresponding to the identity-based public key.

[0231] Figure 5 An exemplary system 500 for implementing embodiments of the present disclosure is shown. 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 can 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, meaning that the key generator 501 can verify an identifier belonging to Alice 103a. For example, the key generator can perform the identity check as part of a “know your customer” (KYC) protocol.

[0232] Reference has been made above to Figure 1 to Figure 4The computer device of Alice 103a and the blockchain node 104 have been described, so they will not be described in detail here. Each key generator 501 (also referred to as a private key generator (PKG)) includes a corresponding computer device. The computer device of each PKG 501 includes a corresponding processing device, which includes 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 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells, which take the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on the computer device of each PKG 501 stores software, which includes a corresponding instance of at least one client application configured to run on the processing device. It should be understood that any action attributed to a given PKG 501 herein can be performed by the software running on the processing device of the corresponding computer device. A computer device with a given PKG 501 includes at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device such as a smartwatch. Alternatively, a computer device with a given PKG 501 may include a server comprising one or more physical server units, or even an entire data center. A computer device with a given PKG 501 may also include one or more other network resources, such as cloud computing resources accessed via user terminals.

[0233] In some examples, one, some, or all of the PKGs may be mining nodes 104M, in which case the computer equipment for these PKGs is the same as that for mining nodes 104M as described above.

[0234] exist Figure 5 In the example shown, Alice 103a will use the identifier ID A Transmitted to PKG 501. Alice 103a can be transmitted via wired or wireless connection (e.g., via reference...). Figure 3 The secure channel 301 transmits the identifier directly to PKG 501. Conversely, Alice 103a can transmit the identifier ID via a blockchain transaction (e.g., the address to which payment should be made to PKG 501). A Transmitted to PKG 501. For example, Alice 103a can generate blockchain transactions with (spendable or non-spendable) outputs, including an identifier ID. A If PKG 501 has a known identifier ID A Then Alice 103a does not need to send this identifier. For example, Alice's identifier ID.A It may be publicly known.

[0235] PKG 501 is based on identifier ID A Generate private key sharing D iA That is, private key sharing D iA It is the identifier ID A The function. PKG501 can share private keys. ii Transmitted to Alice, for example, via a secure channel, via a blockchain transaction (e.g., payment should be made to Alice's 103a address), or via alternative methods. Private key sharing D iA It can be sent in encrypted form. For example, Alice103a could possess the public key known to PKG 501 (“first public key”), which Alice could use as the basis for addresses on the blockchain network. The first public key could be an authentication public key, such as one authenticated by PKG 501 or by a separate certificate authority.

[0236] In some examples, Alice 103a can also generate its own corresponding private key share D using the same protocol as PKG 501. iA Here, "the same protocol" refers to the same algorithm, which involves one or more different variables to generate different private key shares.

[0237] For example, PKG 501 and Alice 103a can use the above algorithms (especially Algorithm 1B and Algorithm 2B) to generate corresponding private key shares.

[0238] Once Alice 103a obtains (e.g., receives and optionally generates) a set of private keys shared by D AA Alice 103a then generates an identity-based private key s. A Identity-based private keys A According to the shared private key group D iA Generation, i.e., identity-based private keys s A It is the shared private key of this group D AA The function. Alice 103a can use the above key generation algorithm (i.e., Algorithm 2B) to generate identity-based private keys s. A .

[0239] Alice 103a can also generate partially identity-based public keys (X). A ,Y A This key is only a partial key because it does not correspond to an identity-based private key. A That is, identity-based private keys s A It will not decrypt using a partial identity-based public key (X). A ,Y Aencrypted message. Alice can generate a partially identity-based public key using the above key generation algorithm (i.e. algorithm 2B). The partially identity-based public key (X A ,Y A ) is based on (i.e. is a function of) the identifier ID iA and the partially identity-based public key (X i is generated. Here, each public key share P i corresponds to a respective private key share D ii , because the public key share P i is generated based on the respective private key share D iA , i.e. the public key share P i is a function of the private key share D iA .

[0240] Alice 103a can transmit the partially identity-based public key (X A ,Y A ) to the PKG 501, e.g. over a secure channel, over a blockchain transaction (e.g. to an address of the PKG 501 to which a payment should be made), or by alternative means. In that case, the PKG 501 generates an (entire) identity-based public key PK A . The identity-based public key PK A is based on (i.e. is a function of) the identifier ID A and the partially identity-based public key (X A ,Y A ). Furthermore / alternatively, Alice 103a can generate the identity-based public key PK A herself. Preferably, the PKG 501 can perform an identity verification check on Alice 103a and her identifier ID A , in which case the PKG 501 preferably generates the identity-based public key PK A , assuming the identity verification check is successful.

[0241] Once the identity-based public key PK A is generated, Alice 103a and / or the PKG 501 generate a blockchain transaction containing an output comprising the identity-based public key PK A . The output can be a spendable output, e.g. a pay-to-public-key-hash (P2PKH) output, or an unspendable output, e.g. an OP_RETURN output. Preferably, the PKG 501 generates the blockchain transaction, so that other parties can rely on the PKG’s identity verification check when using Alice’s identity-based public key PK A .

[0242] The blockchain transaction (hereinafter referred to as “validity check transaction”) Tx VCTto the blockchain network 106 for inclusion in the blockchain 150. Preferably, the PKG 501 transmits the validity check transaction Tx VCT to the blockchain network 106. Alternatively, Alice 103a can transmit the validity check transaction Tx VCT to the blockchain network 106. The party that generates the transmitted validity check transaction Tx VCT may or can not be the same party that transmits the validity check transaction Tx VCT to the blockchain network 106. For example, Alice 103a can generate Tx VCT and forward it to the PKG 501 for transmission to the blockchain network 501.

[0243] In the example where the PKG 501 generates the identity-based public key PK A , the PKG 501 can transmit the identity-based public key PK A and / or the validity check transaction Tx VCT directly to Alice 103a, e.g. over a secure channel. The identity-based public key PK A may be sent in encrypted form, e.g. encrypted using Alice’s first public key.

[0244] Alice 103a can obtain the identity-based public key PK A for use, e.g. as an encryption key, e.g. from the PKG 501 or from the blockchain 150. Uses of the identity-based public key PK A will be described below. The PKG 501 can transmit the transaction identifier TxID VCT of the validity check transaction Tx VCT to Alice 103a, so that she can readily identify the validity check transaction Tx VCT on the blockchain 150.

[0245] Alice 103a and / or the PKG 501 can generate a blockchain transaction (hereinafter referred to as a parameter transaction) Tx par comprising parameters used to generate the identity-based public key PK A , e.g. the parameters of Algorithm 1B and Algorithm 2B. The parameter transaction Tx par does not comprise a private key and a secret key. The parameter transaction Tx par is transmitted by Alice 103a and / or the PKG 501 to the blockchain network 106. The parameter transaction Tx par may or can not be the same transaction as the validity check transaction Tx VCT , the party that generates the parameter transaction Tx par may or can not be the party that generates the validity check transaction Tx VCTthe same party as Alice 103a. The parameter enables a third party to verify the identity-based public key PK A and encrypt messages using the identity-based public key PK A . Furthermore, the parameter also enables Alice 103a to decrypt messages that have been encrypted using the identity-based public key PK A . The parameter can be published without using the blockchain 150. For example, the parameter can be published (hosted) on a website by Alice 103a and / or the PKG 501. They can send the parameter to parties upon request, rather than publishing the parameter.

[0246] If the parameter transaction Tx par and the validity check transaction Tx VCT are different transactions, the parameter transaction Tx par may include the transaction identifier TxID VCT of the validity check transaction Tx VCT , for example, to enable Alice 103a or a third party to identify the identity-based public key PK VCT stored in the validity check transaction Tx A .

[0247] In examples where the PKG 501 is a mining node 104M, the parameter transaction Tx par may be a generation transaction (also known in the art as a coinbase transaction). Generation transactions have been described above. In these examples, sending the parameter transaction Tx par to the blockchain network 106 means mining a new block 151 containing the parameter transaction Tx par . As part of the block mining process, only mining nodes 104M can generate multiple generation transactions. Mining a block requires proof-of-work, which is in essence a computationally intensive process. Therefore, it is assumed that the mining node 104M submits the required proof-of-work to mine a block with a generation transaction containing the parameter, where it would not contain incorrect parameters because that would be a computationally expensive process for them.

[0248] The validity check transaction Tx VCT may include a spendable output locked to a public key or a public key address of Alice 103a (e.g. Alice’s first public key). For example, the output can be a P2PKH output. To unlock a P2PKH output by an input of a spend transaction, the input of the spend transaction must include: a public key that hashes to the P2PKH in the P2PKH output; and a signature generated using that public key, but not necessarily in that order. The output can impose one or more additional requirements on the input of the spend transaction.

[0249] Alternatively, the validity check transaction Tx VCTThe spendable output can comprise a pay-to-public-key-hash (P2PKH) output locking to the public key or public key address of the PKG 501. For example, the output can be a P2PKH output payable to the public key of the PKG 501.

[0250] Alternatively, the validity check transaction Tx VCT may comprise a spendable output locking to the public key of Alice 103a and the public key of the PKG 501. According to the output script, the output can be unlocked if the input of a spending transaction comprises the public key and / or signature of Alice 103a, or if the input of a spending transaction comprises the public key of the PKG 501, or if the input of a spending transaction comprises both public keys (one from Alice 103a and one from the PKG 501) and / or both signatures (one from Alice 103a and one from the PKG 501). For example, the output can be an m / n multi-signature output, which can be unlocked if the input of a spending transaction comprises m signatures corresponding to n public keys in the multi-signature output.

[0251] In some examples, the validity check transaction Tx VCT may comprise a spendable output comprising an identity-based public key PK A . Alternatively, the validity check transaction Tx VCT may comprise two outputs, one being a spendable output and the other being an unspendable output comprising an identity-based public key PK A .

[0252] If the spendable output of the validity check transaction Tx VCT locks to Alice 103a (or, more precisely, to her public key or public key address), Alice 103a can generate a revocation transaction Tx rev spending the output of the validity check transaction Tx VCT . Once transmitted to the blockchain, the revocation transaction Tx rev removes the output of the validity check transaction Tx A comprising the identity-based public key PK VCT from the set of unspent transaction outputs (UTXO) of the blockchain 150. Similarly, if the spendable output of the validity check transaction Tx VCT locks to the PKG 501 (or, more precisely, to the public key or public key address of the PKG 501), the PKG 501 can generate a revocation transaction Tx rev spending the output of the validity check transaction Tx VCT .

[0253] As mentioned above, the identity-based public key PK AIt can be used to encrypt messages. In this sense, identity-based public key PK... A Used as an identity-based encryption key. Although these terms are synonymous, for consistency, the key will be referred to below as the identity-based public key (PK). A .

[0254] In some examples, Alice103a can use its own identity-based public key PK. A To encrypt messages. For example, Alice 103a can use the encryption algorithm described above (i.e., Algorithm 3B) to encrypt messages. Alice 103a can store encrypted messages, transmit encrypted messages to one or more different parties (including PKG501), broadcast encrypted messages on a network (e.g., on a private network), publish encrypted messages (e.g., on a public website), or include encrypted messages in a blockchain network for transmission to one or more nodes of blockchain network 106. For example, Alice 103a can generate blockchain transactions that include outputs containing encrypted messages. The encrypted messages can form part of a locking script; for example, it can impose a requirement on the input of a spending transaction to include the decrypted message. Of course, only those who can access the identity-based private key can access it. A Only one party can decrypt the encrypted message; preferably, only Alice 103a can do so.

[0255] In other examples, a party other than Alice 203a can use an identity-based public key PK. A To encrypt messages. For example, the party can check the validity of transaction Tx. VCT Obtain identity-based public key PK A Alice can obtain encrypted messages directly from the cryptographic party, blockchain transactions, or other means. Alice 103a can then use identity-based private keys... A The encrypted message is then decrypted to reveal its contents. Alice can use the aforementioned decryption algorithm (i.e., Algorithm 4B) to decrypt the encrypted message. As previously mentioned, the encrypted message can form part of the locking script for a blockchain transaction, and Alice 103a can include the decrypted message in the unlocking script for a spending transaction to unlock the locking script.

[0256] Figure 6 Another exemplary system 600 for implementing embodiments of the present disclosure is shown. Figure 6 The system 600 shown is Figure 5 The system shown is similar to system 500, the difference being the addition of a PKG. Figure 6 In the example, there is a first PKG 501a and a second PKG 501b. Typically, a system can include any number of PKG 501s. Both the first PKG 501a and the second PKG 501b can be configured to execute before...Figure 5 The actions associated with PKG 501 are shown.

[0257] The first PKG 501a and / or the second PKG 501b can obtain the identifier ID from Alice 103a. A In some examples, a PKG (e.g., PKG 501a) can retrieve the identifier ID. A and the identifier ID A Transmission is made to one or more different PKGs (e.g., PKG 501b). Each of the first PKG 501a and the second PKG 501b is based on an identifier ID. A Generate the corresponding private key sharing D iA The first PKG 501a generates the first private key shared D. 1A The second PKG 501b generates a second private key shared D. 2A Each PKG uses the same algorithm to generate its corresponding private key shared D. iA However, different variables are used (e.g., secret and / or random number). Each PKG shares its corresponding private key with D. iA The data is transmitted to Alice 103a, which may or may not generate a corresponding private key sharing D. iA Each PKG 501 can share its corresponding private key using the same communication method. iA Transmitted to Alice 103a, for example, both the first PKG 501a and the second PKG 501b can transmit their shared private key D via a secure channel or through different communication methods. iA For example, the first PKG 501a can share the private key D. 1A Including in blockchain transactions, the second PKG can transmit its private key shared D via a wired connection. 2A .

[0258] Alice 103a uses the first private key to share D 1A Second private key shared D 2A To generate identity-based private keys s A The identity-based private key A Each private key shares D iA The function.

[0259] Alice 103a can also generate partially identity-based public keys (X). A ,Y A ), namely, partially identity-based public key (X A ,Y A Partially identity-based public key (X) A ,Y A) is based on (i.e., its function) sharing D with that set of private keys. iA A corresponding set of public key sharing P i Generated. Each of the first PKG 501a and the second PKG 501b can share its corresponding public key. i Transmitted to Alice 103a, for example, via a secure channel or using a corresponding blockchain transaction. Alice 103a can transmit a portion of the identity-based public key (X). A ,Y A The public key (X) can be transmitted to the first PKG 501a and the second PKG 501b, or partially based on the identity (X). A ,Y A The data is transmitted to one of the PKGs (e.g., PKG 501a), which then forwards it to other PKGs (e.g., PKG 501b). Partially based on the identity-based public key (X). A ,Y A It can be sent in encrypted form (for example, using Alice's first public key).

[0260] One, some, or all of the PKGs are based on the identifier ID. A and partially identity-based public keys (X A ,Y A Generate a complete identity-based public key PK. A Preferably, only one PKG (e.g., PKG 501a) generates an identity-based public key PK. A Validity check of transaction Tx VCT Then the transaction Tx VCT Transmitted to blockchain network 106. However, it is not excluded that multiple PKG 501s can generate identity-based public key PKs. A The corresponding validity check transaction Tx VCT One, some, or all of the PKG can generate parameterized transactions (Tx). par This parameter transaction includes the public key (PK) used to generate identity-based public keys. A The (public) parameters. Preferably, a validity check transaction Tx is generated. VCT The PKG also generates parameter transactions Tx par The transaction in this parameter may or may not be a transaction on the same blockchain.

[0261] Embodiments of the present disclosure provide an implementation of an identity-based encryption (IBE) system and use the blockchain 150 and its UTXO set to allow for key validity checks on key revocation. The blockchain 150 is used to provide authorization and guarantee integrity when reading IBE keys and parameters. Preferably, the IBE system is implemented by reputable mining nodes 104M. Each mining node 104M can create a publicly known identity that is cryptographically guaranteed to be secure, for example as an ECDSA public key, and backed up by a proof-of-work based reputation system. Assuming that each mining node 104M is unwilling to risk their reputation by cheating the system, then reputable mining nodes 104M will be trusted to perform checks on a user’s identity and effectively generate IBE keys. Furthermore, the UTXO set can act as a whitelist in a PKI setup, whereby if an IBE key is referenced by a transaction output in the UTXO, then the IBE key is valid.

[0262] Another illustrative example embodiment of the present disclosure is described below. Without loss of generality, assume that there are three mining nodes 104M providing IBE key generation services. Assume that Alice 103a wants to verify her identity Alice@Blockland.com and thus use it as her IBE public key.

[0263] Alice contacts all three mining nodes (M1, M2 and M3) to obtain the private key. Each mining node M i independently verifies Alice’s identity. Once they are sure that Alice 103a is indeed the owner of Alice@Blockland.com, then the following steps will be followed:

[0264] 1. Each mining node runs the key generation algorithm (Algorithm 2B) on ID A = Alice@Blockland.com and sends D iA to Alice 103a.

[0265] 2. Alice 103a then generates her partial public key (X A , Y A ).

[0266] 3. Upon receiving (X A , Y b ) from Alice 103a, each mining node verifies the equation e(X A ,∑ i P i ) = e(P, Y A ).

[0267] 4. If the equation holds, then each mining node sets PK A = (ID AX A Y A If the equation does not hold, then the process is stopped.

[0268] 5. A mining node or other interested party generates a validity check transaction, which has:

[0269] a. Input: any valid UTXO of the mining node.

[0270] b. Output 1 : P2PKH (a unique public key PK iVCT chosen by the mining node).

[0271] c. Output 2: OP_RETURN PK A

[0272] 6. When the validity check transaction is mined, each mining node is given and records the transaction ID TxID iVCT .

[0273] 7. Each mining node creates a coinbase (generation) transaction containing the following information:

[0274] a. Public key parameters (G1, G2, q, P, P1, P2, P3, e, H1, H2, H3, H4);

[0275] b. Alice's public key PK A = (ID A X A Y A );

[0276] c. VCT identifier TxID VCT

[0277] 8. Each mining node attempts to mine the coinbase transaction, provided that no other mining node has already mined the transaction.

[0278] Once the coinbase transaction is mined, the IBE public key of Alice can be used. Note that the information in the transaction generated in step 7 need only be included once in the coinbase transaction mined by any mining node. Once the coinbase transaction is mined, other miners need not include the same information in further transactions.

[0279] Key revocation can be achieved by spending validity check transactions, i.e. removing from the UTXO set. This results in the key being revoked immediately, and this immediate revocation can be done by the user, the key generator, a trusted third party, or a combination of them. Furthermore, another party (say Bob 103b) can easily check whether Alice's IBE key is valid by just checking her details in the UTXO set. Note that multiple mining nodes 104M can generate corresponding validity check transactions. This will allow revocation rules to be configured. For example, if there are three validity check transactions, one rule can state that in order for an IBE key to be considered revoked, one of the three validity check transactions needs to be spent. Another rule can state that all three validity check transactions need to be spent in order for an IBE key to be considered revoked.

[0280] As an alternative to step 5, Alice's IBE key PK A can be inserted into the locking script of the transaction. This will guarantee that PK A is always in the UTXO set and will not be pruned like an OP_RETURN output.

[0281] As mentioned above, the key generation service can be provided by a mining node or by a non-miner. A non-mining node can run a smart contract, thereby generating private keys for subscribers (e.g. Alice 103a). The key generation public parameters are published on the blockchain and will benefit from the immutability of the blockchain. Note that Alice 103a must inform Bob 103b which key generation service provider she is using.

[0282] As the number of blockchain users increases, it is necessary to store information on the blockchain efficiently and avoid time delays. The information of multiple users can be inserted in the coinbase transaction created in step 7. In this case, the public parameters in step 7.a only need to be inserted once at the beginning, followed by the IBE public key and validity check transaction identifier of each user (steps 7.b and 7.c). The same public parameters are used by each user. The number of public keys that can be added to one coinbase transaction will only be limited by the size of the transaction or any other size imposed by the blockchain protocol.

[0283] The transaction sequence field of a transaction can be used to activate a set of IBE keys at a later date. This can be particularly useful when there is a separate server responsible for generating keys, which are then taken offline to reduce exposure time. In this case, the server generates the key set and inserts it into a locktime transaction, which is later activated automatically by a mining node. The same technique can also be employed for automatic key updates by creating a locktime transaction that spends the validity check output using a spend transaction that includes the updated IBE key.

[0284] Alice's identifier can take the following form:

[0285] ID A = identifier_string_type || identifier_value || functional_string_type || value

[0286] The identifier_string can be an email, mobile number, passport number, or social media account, among others. The functional_string can be any of the following or a combination thereof:

[0287] • Expiry date: After this date, the ID should not be used A and a new ID with a new expiry date should be used A . The key generator service provider will have to generate and send the private key for the new ID A This will ensure that the IBE key is updated. Depending on the use case requirements, the update period can be set to monthly, daily, etc.

[0288] • Effective date: This can be used to ensure that the private key generator does not issue private keys before this date. In this instance, the key generator service provider is used to enforce a time lock. Optionally, the date can be at a blockchain height.

[0289] • Attributes: The service provider will send the private key only if the attribute or a set of attributes is satisfied. This can be used to enforce attribute-based access control and location encryption. For example, if Alice 103a has a security clearance, then Bob 103b can send a message that can be decrypted. The key generator service provider will issue the decryption key to Alice 103a only if she can satisfy this requirement.

[0290] Use cases

[0291] Figure 7 A first use case (UC1) is shown. Alice 103a contacts private key generator 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 her the private key skAlice This use case can be performed on the blockchain by inserting Alice's request and PKG1's response in OP_RETURN in two blockchain transactions. Alice 103a can insert the encryption public key (PK Alice ) in her request to PKG1 501a to guarantee channel security, but this can be skipped if such a channel already exists. PKG1 501a performs the verification and key generation steps and sends Alice's private key encrypted using PK Alice in the response transaction. The two example transactions are shown below.

[0292]

[0293]

[0294] It is noted that the above transactions are simplified in order to express the concept. More detailed transactions can include ephemeral encryption keys and initialization vectors, as well as additional outputs for any changes.

[0295] The following transactions show the second use case (UC2). Alice 103a adds her own private key so that even if the partial private key generated by PKG1 is leaked, her key is secure. Alice can announce (X A ,Y A ) on the blockchain in at least two possible ways. The first way is a single transaction paid by Alice 103a herself.

[0296]

[0297] The second way is two transactions (a request transaction and a response transaction) between Alice 103a and PKG1 501a.

[0298]

[0299]

[0300] Figure 8a and Figure 8bA third example use case (UC3) is shown. Bob 103b wants to send a message to Alice 103a that she can only read within a certain time frame (not before ti and not after t2). Such a service can be provided by a different key generator, PKG2 501b, than PKG1 501a. Bob 103b generates a new IBE public key for Alice 103a that uses Alice’s IBE public key generated based on Alice@Blockland.com (verified and generated by PKG1 in UC1) and inserts a validity period and a nonce. He encrypts the message Ml using the newly generated IBE public key Alice@Blockland.com PKG1_t1_t2_nonce with the public key parameters of PKG2 to output C1. He sends the ciphertext and the IBE public key he used in the 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 the new IBE public key, he retrieves the public parameters of PKG1 and PKG2 from the blockchain 150. He should make sure that PKG1 is a private key generator and a trusted identity verification service provider. Alice PKG1 and PKG2. He should make sure that PKG1 is a private key generator and a trusted identity verification service provider.

[0301] Alice 103a contacts PKG2 501b to get the private key to unlock Bob’s encrypted message C1. PKG2 501b will check if PKG1 501a is a trusted service provider and check if the time of the request is between ti and t2. If all checks pass, PKG2 501b will generate Alice’s 103a private key that corresponds to the encryption key that Bob 103b generated and used. The new private key can be encrypted into C2 using Alice’s existing IBE key (i.e., based on Alice@Blockland.com generated). It is noted that in this use case, PKG2 103b provides the time check service and relies on PKG1 501a to run the email verification service that was already done in UC1. Similar to UC1, Alice 103a and PKG2 501b communicate on the blockchain 150.

[0302] These use cases show how the IBE protocol can be used to allow Bob (the encryptor) to set conditions that Alice (the decryptor) can decrypt the message. In UC1, Alice gets the IBE key from PKG1. Bob uses a different PKG, PKG2, to check if Alice meets Bob’s conditions.

[0303] Conclusion

[0304] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus or program can be provided in accordance with any one or more of the following statements.

[0305] Statement 1. A computer-implemented method for generating an identity-based encryption key, the method being performed by a first party having a personal identifier and comprising:

[0306] obtaining a set of private key shares and a set of corresponding public key shares, wherein each private key share is generated based on the personal identifier, and wherein at least one private key share of the set of private key shares is generated by a respective one of a set of key generating parties;

[0307] generating an identity-based private key based on each of the one or more private key shares; and

[0308] generating a partially identity-based public key, wherein the partially identity-based public key is generated based on each of the set of corresponding public key shares;

[0309] transmitting the partially identity-based public key to at least one of the set of key generating parties to generate the identity-based public key, wherein the identity-based public key comprises the personal identifier and the partially identity-based public key; and / or

[0310] generating the identity-based public key, wherein the identity-based public key comprises the personal identifier and the partially identity-based public key.

[0311] A key share is a component part of a private key, which can be used to generate a private key together with one or more other key shares.

[0312] Statement 2. The method of statement 1, wherein a first output of a first blockchain transaction comprises the identity-based public key, the identity-based public key comprising the personal identifier and the partially identity-based public key, and wherein the method comprises obtaining the identity-based public key from the first blockchain transaction.

[0313] Statement 3. The method of statement 2, wherein the obtaining the identity-based public key from the first blockchain transaction comprises:

[0314] obtaining a transaction identifier of the first blockchain transaction from at least one of the one or more key generating parties; and

[0315] using the transaction identifier to obtain the first blockchain transaction from a blockchain in which the first blockchain transaction is recorded.

[0316] Statement 4. The method of any one of statements 1 to 3, comprising:

[0317] obtaining the identity-based public key from at least one of the set of key generation parties.

[0318] Statement 5. The method of any one of Statements 1 to 4, comprising:

[0319] encrypting a first message using the identity-based public key to generate a first encrypted message; and

[0320] transmitting the first encrypted message to a second party, and / or generating a second blockchain transaction comprising an output comprising the encrypted message.

[0321] Statement 6. The method of any one of Statements 1 to 5, comprising:

[0322] obtaining a second encrypted message encrypted using the identity-based public key; and

[0323] decrypting the second encrypted message using the private key to reveal a second message.

[0324] Statement 7. The method of any one of Statements 1 to 6, comprising transmitting the personal identifier to at least one of the one or more key generation parties.

[0325] Statement 8. The method of Statement 7, wherein the transmitting the personal identifier comprises:

[0326] generating a third blockchain transaction comprising an output comprising the personal identifier; and

[0327] transmitting the third blockchain transaction to one or more nodes of a blockchain network for inclusion of the transaction in the blockchain.

[0328] Statement 9. The method of Statement 2 or any claim dependent thereon, wherein the first party possesses a first public key, wherein the first blockchain transaction comprises a second output locked to the first public key of the first party, and wherein the method comprises:

[0329] generating a fourth blockchain transaction comprising an input a) referencing the second output of the first blockchain transaction, and b) comprising a signature generated based on a private key corresponding to the first public key of the first party; and

[0330] transmitting the fourth blockchain transaction to one or more nodes of the blockchain network for inclusion of the transaction in the blockchain.

[0331] The first output and the second output of the first blockchain transaction can be the same output. That is, the identity-based public key can be included in a spendable (e.g., P2PKH) output. For example, the output can include a public key using OP_PUSHDATA and OP_DROP.

[0332] Statement 10, the method of any one of Statements 1 to 9, wherein the transmitting the partial identity-based public key to at least one of the set of key generators comprises:

[0333] generating a fifth blockchain transaction comprising an output, the output comprising the partial identity-based public key; and

[0334] transmitting the fifth blockchain transaction to one or more nodes of the blockchain network for inclusion of the transaction in the blockchain.

[0335] Statement 11, the method of any one of Statements 1 to 10, wherein the identifier of the first party comprises one or more of: a name and / or address of the first party, an email address of the first party, a phone number, a passport number, a driver’s license number, a social media profile, a date of birth, and a group member identifier.

[0336] Statement 12, a computer-implemented method for generating an identity-based encryption key, wherein a first party has a personal identifier, and wherein the method is performed by a first key generator and comprises:

[0337] transmitting a private key share to the first party, wherein the private key share is generated based on the personal identifier and has a corresponding public key share;

[0338] obtaining a partial identity-based public key, wherein the partial identity-based public key is generated based on the corresponding public key share;

[0339] generating and / or obtaining the identity-based public key, wherein the identity-based public key is generated based on the partial identity-based public key and the personal identifier; and

[0340] generating a first blockchain transaction comprising a first output, the first output comprising the identity-based public key.

[0341] In some examples, the method comprises generating a private key share and a corresponding public key share.

[0342] Statement 13, the method of Statement 12, comprising transmitting the first blockchain transaction to one or more nodes of a blockchain network for inclusion of the transaction in the blockchain.

[0343] Clause 14. The method of clause 12, comprising transmitting the first blockchain transaction to the first party.

[0344] Clause 15. The method of any one of clauses 12 to 14, wherein the first output of the first blockchain transaction is an unspendable output.

[0345] Clause 16. The method of any one of clauses 13 to 15, comprising obtaining the personal identifier from the first party.

[0346] Clause 17. The method of clause 16, wherein the blockchain comprises a third blockchain transaction, the third blockchain transaction being generated by the first party and comprising the personal identifier, and wherein the obtaining the personal identifier from the first party comprises obtaining the personal identifier from the third blockchain transaction.

[0347] Clause 18. The method of any one of clauses 12 to 17, wherein the first key generating party possesses a first public key, and wherein the first blockchain transaction comprises a second output, the second output being locked to the first public key of the key generating party.

[0348] The first output and the second output can be the same output. Alternatively, the first output and the second output can be different outputs.

[0349] Clause 19. The method of clause 18, comprising:

[0350] generating a fourth blockchain transaction comprising an input a) referencing the second output of the first blockchain transaction, and b) comprising a signature generated based on a private key corresponding to the public key of the first key generating party; and

[0351] transmitting the fourth blockchain transaction to one or more nodes of the blockchain network for inclusion of the transaction in the blockchain.

[0352] Clause 20. The method of any one of clauses 12 to 19, wherein the first party possesses a first public key, and wherein the first blockchain transaction comprises a second output, the second output being locked to the first public key of the first party.

[0353] Clause 21. The method of any one of clauses 12 to 20, wherein the blockchain comprises a fifth blockchain transaction, the fifth blockchain transaction comprising the partially identity-based public key, wherein the obtaining the partially identity-based public key comprises obtaining the partially identity-based public key from the fifth blockchain transaction.

[0354] Statement 22, the method of any one of statements 12 to 21, comprising:

[0355] generating a sixth blockchain transaction comprising an output comprising the private key share, and wherein the 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 of the transaction in the blockchain.

[0356] Statement 23, the method of statement 22, wherein the private key share is transmitted in encrypted form.

[0357] Statement 24, the method of any one of statements 12 to 23, comprising:

[0358] generating a seventh blockchain transaction comprising an output comprising a set of parameters used to generate the identity-based public key; and

[0359] transmitting the seventh blockchain transaction to one or more nodes of the blockchain network for inclusion of the transaction in the blockchain.

[0360] The seventh blockchain transaction can comprise an identifier of the first blockchain transaction.

[0361] Statement 25, the method of any one of statement 24, wherein the partial identity-based public key is generated based on a plurality of public key shares, each public key share being generated by a respective one of a set of key generating parties, and wherein the seventh blockchain transaction comprises the set of parameters used by each respective key generating party to generate the identity-based public key.

[0362] Statement 26, the method of statement 24 or statement 25, wherein the first key generating party is a mining node of the blockchain network, and wherein the seventh blockchain transaction is a generation transaction.

[0363] By using a generation (i.e. coinbase) transaction to record the identifier of the first blockchain transaction and the parameters used to generate the identity-based key, trust in the PoW displayed by the mining node can be delegated to trust in the generated cryptographic key, and thus the mining node can be considered as a trusted certificate authority.

[0364] Statement 27, a computer device, the computer device comprising:

[0365] a memory comprising one or more memory units; and

[0366] a processing device comprising one or more processing units, wherein the memory stores code arranged to run on the processing device, the code being configured to perform the method according to any of statements 1 to 26 when run on the processing device.

[0367] Statement 28. A computer program embodied on a computer readable storage and configured so as when run on a computer device as in statement 27 to perform the method according to any of statements 1 to 26.

[0368] According to a further aspect disclosed herein, there can be provided a method comprising measures of a first party and a key generating party.

[0369] According to a further aspect disclosed herein, there can be provided a system comprising computer devices of a first party and a key generating party.

[0370] Other variations to those described herein can become apparent to those skilled in the art once given the benefit of the present disclosure. The scope of the disclosure is not to be limited by the embodiments disclosed but only by the claims that follow.

Claims

1. A computer-implemented method for generating identity-based encryption keys, the method being performed by a first party having a personal identifier and comprising: Obtain a set of private key shares and a set of corresponding public key shares, wherein each private key share is generated based on the personal identifier, and wherein at least one of the private key shares in the set of private key shares is generated by a corresponding party in a set of key generators; Generate an identity-based private key based on each of the one or more private key shares; and Generate a partially identity-based public key, wherein the partially identity-based public key is generated based on each of the corresponding set of public key shares; The partial identity-based public key is transmitted to at least one of the group of key generators to generate the identity-based public key, wherein the identity-based public key includes the personal identifier and the partial identity-based public key; and / or Generate the identity-based public key, wherein the identity-based public key includes the personal identifier and the partial identity-based public key.

2. The method of claim 1, wherein the first output of the first blockchain transaction includes the identity-based public key, the identity-based public key including the personal identifier and the partial identity-based public key, and wherein the method includes obtaining the identity-based public key from the first blockchain transaction.

3. The method according to claim 2, wherein obtaining the identity-based public key from the first blockchain transaction comprises: Obtain the transaction identifier of the first blockchain transaction from at least one of the one or more key generating parties; and The first blockchain transaction is retrieved from the blockchain that records the first blockchain transaction using the transaction identifier.

4. The method according to any one of claims 1 to 3, comprising: The identity-based public key is obtained from at least one of the key generators in the group.

5. The method according to any one of claims 1 to 4, comprising: The first message is encrypted using the identity-based public key to generate the first encrypted message; and The first encrypted message is transmitted to a second party, and / or a second blockchain transaction is generated, including the output, which includes the encrypted message.

6. The method according to any one of claims 1 to 5, comprising: Obtain the second encrypted message encrypted using the identity-based public key; and The second encrypted message is decrypted using the private key to reveal the second message.

7. The method according to any one of claims 1 to 6, comprising transmitting the personal identifier to at least one of the one or more key generating parties.

8. The method of claim 7, wherein transmitting the personal identifier comprises: Generate a third blockchain transaction that includes the output, the output including the personal identifier; and The third blockchain transaction is transmitted to one or more nodes in the blockchain network so that the transaction is included in the blockchain.

9. The method of claim 2 or any dependent claim thereof, wherein the first party possesses a first public key, wherein the first blockchain transaction includes a second output locked to the first party's first public key, and wherein the method comprises: Generate a fourth blockchain transaction including inputs, wherein the inputs a) reference the second output of the first blockchain transaction, and b) include a signature generated based on the private key corresponding to the first party's first public key; and The fourth blockchain transaction is transmitted to one or more nodes of the blockchain network to include the transaction in the blockchain.

10. The method according to any one of claims 1 to 9, wherein transmitting the partial identity-based public key to at least one of the group of key generators comprises: Generate a fifth blockchain transaction that includes an output, the output including the identity-based public key portion; and The fifth blockchain transaction is transmitted to one or more nodes of the blockchain network to include the transaction in the blockchain.

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

12. A computer-implemented method for generating identity-based cryptographic keys, wherein a first party has a personal identifier, and wherein the method is performed by a first key generator and includes: A private key share is transmitted to the first party, wherein the private key share is generated based on the personal identifier and has a corresponding public key share; Obtain a partial identity-based public key, wherein the partial identity-based public key is generated based on the corresponding public key sharing; Generate and / or obtain the identity-based public key, wherein the identity-based public key is generated based on the partial identity-based public key and the personal identifier; as well as Generate a first blockchain transaction that includes a first output, the first output including the identity-based public key.

13. The method of claim 12, further comprising transmitting the first blockchain transaction to one or more nodes of the blockchain network to include the transaction in the blockchain.

14. The method of claim 12, comprising transmitting the first blockchain transaction to the first party.

15. The method according to any one of claims 12 to 14, wherein the first output of the first blockchain transaction is an unspendable output.

16. The method according to any one of claims 13 to 15, comprising obtaining the personal identifier from the first party.

17. The method of claim 16, wherein the blockchain includes a third blockchain transaction, the third blockchain transaction being generated by the first party and including the personal identifier, and wherein obtaining the personal identifier from the first party includes obtaining the personal identifier from the third blockchain transaction.

18. The method according to any one of claims 12 to 17, wherein the first key generator has a first public key, and wherein the first blockchain transaction includes a second output, the second output being locked to the first public key of the key generator.

19. The method of claim 18, comprising: Generate a fourth blockchain transaction including inputs, wherein the inputs a) reference the second output of the first blockchain transaction, and b) include a signature generated based on the private key corresponding to the public key of the first key generator; and The fourth blockchain transaction is transmitted to one or more nodes of the blockchain network to include the transaction in the blockchain.

20. The method according to any one of claims 12 to 19, wherein the first party possesses a first public key, and wherein the first blockchain transaction includes a second output locked to the first party's first public key.

21. The method of any one of claims 12 to 20, wherein the blockchain includes a fifth blockchain transaction, the fifth blockchain transaction including the partially identity-based public key, wherein obtaining the partially identity-based public key includes obtaining the partially identity-based public key from the fifth blockchain transaction.

22. The method according to any one of claims 12 to 21, comprising: Generate a sixth blockchain transaction including the output, the output including the private key share, and 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 to include the transaction in the blockchain.

23. The method of claim 22, wherein the private key sharing is transmitted in encrypted form.

24. The method according to any one of claims 12 to 23, comprising: Generate a seventh blockchain transaction that includes an output, the output of which includes a set of parameters for generating the identity-based public key; and The seventh blockchain transaction is transmitted to one or more nodes of the blockchain network to include the transaction in the blockchain.

25. The method of any one of claims 24, wherein the partial identity-based public key is generated based on a plurality of public key shares, each public key share being generated by a corresponding party in a set of key generators, and wherein the seventh blockchain transaction includes the set of parameters used by each corresponding key generator to generate the identity-based public key.

26. The method of claim 24 or claim 25, wherein the first key generator is a mining node of the blockchain network, and wherein the seventh blockchain transaction is a generation transaction.

27. A computer device, the computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 26 when run on the processing apparatus.

28. A computer program, the computer program being contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 26 when run on a computer device.

Images