Computer-implemented system and method

Abstract

To provide a resource exchange method that is implemented in a cryptographic manner and improves security related to exchanges implemented through a blockchain-implemented network.SOLUTION: In an exchange method, Alice (A) communicates to Bob (B) a secret value (H(A0)) hashed from A's secret (A0), and B communicates a secret value (H(B0)) hashed from B's secret (B0) to A. A and B construct a first blockchain transaction (tx1) and a second blockchain transaction (tx2) that contain H(A0) and H(B0), respectively. The transactions are configured so that when both A0 and B0 are provided in the respective blockchain transactions, they can be unlocked to transfer control of the respective first or second resource. Unlocking tx1 reveals A0 to B, and unlocking tx2 reveals B0 to A.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to computer-implemented security methods and cryptographic techniques. More particularly, the present invention relates to a method for atomically exchanging control of resources. The present invention is suitable for, but not limited to, one or more blockchains, such as the Bitcoin Cash (BCH) blockchain. [Background technology]

[0002] In this document, the term "blockchain" is used to encompass all forms of electronic, computer-based, and distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, this document may refer to Bitcoin. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. The term "user" as used herein may refer to a human or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, computer-based system composed of blocks, which are made up of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, thereby chaining blocks together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs that specify who can access the transaction's outputs and how. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure each transaction is valid; invalid transactions are rejected by the network. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing their lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, the transaction is valid and is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be validated by the first node that receives it. If the transaction is validated, the node relays it to other nodes in the network. The transaction must ii) be added to a new block constructed by miners and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to consider implementing new systems using both the cryptographic security system that Bitcoin is based on and the data that can be stored on the blockchain. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be able to take advantage of the benefits of blockchain (e.g., permanent, immutable recording of events, distributed processing, etc.) while being more diverse in their applications.

[0006] The concept of atomic swaps has long been discussed in the cryptocurrency community. An exchange between parties is "atomic" in the sense that either all participants receive the desired resource (e.g., cryptocurrency tokens or coins) or none receive it. At the time of writing, Wikipedia describes atomic swaps as "a proposed feature in cryptocurrencies that allows one cryptocurrency to be exchanged for another without the need for a trusted third party." Traditional cryptocurrencies require a trusted third party, such as a cryptocurrency exchange, to execute cryptocurrency swaps, preventing parties from sending currency without receiving it in return. Atomic swap systems use hash-time-lock smart contracts to require parties to deliver the swapped currency within a specified time period, or the transaction is canceled. This preserves "atomicity" in the sense that either the swap occurs or the currency is not swapped at all.

[0007] Atomic swaps thus offer increased security for transfers conducted through the blockchain, as removing the need for a trusted third party eliminates the risk of abuse or malicious intervention. Indeed, there have been several security breaches or "hacks" of cryptocurrency exchanges, such as the Mt. Gox incident. [Prior art documents] [Non-patent literature]

[0008] [Non-Patent Document 1] https: / / en.wikipedia.org / wiki / Atomic_swap Summary of the Invention [Problem to be solved by the invention]

[0009] However, the proposed atomic swap solution involves the use of only one secret and the swap is performed asynchronously, which creates the drawback that one transaction can only be consumed after another transaction has been consumed.

[0010] Thus, it is desirable to provide a cryptographically implemented method of resource exchange that atomically exchanges resources or assets with the trustlessness and immutability provided by blockchain technology, and that improves security for exchanges conducted over a blockchain-implemented network.

[0011] Such an improved solution has now been devised. [Means for solving the problem]

[0012] In accordance with the present invention, a computer-implemented exchange method is provided.

[0013] The method may include the following steps: (i) communicating a first veiled secret value from a first user to a second user and a second veiled secret value from the second user to the first user; and (ii) constructing a first blockchain transaction and a second blockchain transaction including the first veiled secret value and the second veiled secret value, respectively, configured such that the transactions are unlockable to transfer control of the respective first or second resource when both the first secret value and the second secret value are provided in the respective blockchain transaction;

[0014] wherein unlocking the first blockchain transaction reveals the first secret value to the second user, and unlocking the second blockchain transaction reveals the second secret value to the first user.

[0015] The method provides a secure way to ensure that secret values are exchanged atomically in a trustless environment, and no user of the method has more control over the method than any other user.

[0016] A secret value is related to a corresponding veiled secret value in such a way that it is practically impossible to determine the secret value from the veiled secret value, but it is practically possible to determine the veiled secret value from the secret value.

[0017] An example of this relationship is when a one-way function such as a hash or modulo arithmetic is applied to a secret value to obtain a veiled secret value.

[0018] At least one of the first transaction and the second transaction may be configured to be redeemable only upon application of the respective first and second private keys.

[0019] This provides the advantage that only the intended recipient, as indicated by the private key, can unlock the transaction.

[0020] The method may further include calculating at least one of: (a) a first derived public key based at least in part on the first public key of the first user, and (b) a second derived public key based at least in part on the second public key of the second user, wherein the first derived public key is part of a cryptographic key pair that includes the first private key, and the second derived public key is part of a cryptographic key pair that includes the second private key.

[0021] This allows assets to be stored in derived addresses rather than public addresses, providing additional privacy and security to users of the method. It should be noted that the terms "asset" and "resource" may be used interchangeably herein. The term "asset" should not be construed as having only a financial context or use. An asset may be, for example, a token representing some other entity on or off the blockchain.

[0022] The step of calculating at least one of (a) a first derived public key based at least in part on the first public key of the first user and (b) a second derived public key based at least in part on the second public key of the second user may further include combining the first and second veiled secret values. This provides the advantage of providing a recorded, indelible link between the transaction and the atomic swap that is performed.

[0023] The combination of the first and second veiled secret values may include at least one of a concatenation of the first veiled secret value with a second veiled secret value and a concatenation of at least one veiled secret value with a random or pseudorandom value. This provides the advantage of further increasing the security of the transaction through additional deterministic obfuscation.

[0024] The method may further include constructing at least one of: a third blockchain transaction configured to return control of the first asset to the first user in response to the passage of a first period of time during which the first transaction is not redeemed; and a fourth blockchain transaction configured to return control of the second asset to the second user in response to the passage of a second period of time during which the second transaction is not redeemed. This allows at least one user of the method to have control of their respective assets returned to them if another user does not fully participate in the exchange, thereby increasing the versatility of the method.

[0025] At least one of the first veiled secret value and the second veiled secret value may include a combination of at least one of the first secret value and the second secret value and a shared secret value accessible by both the first user and the second user. This provides the advantage of increasing the privacy and security provided by the method.

[0026] The shared secret value may be established as a common secret prior to step (i). This provides the advantage of further increasing the security of the method.

[0027] The method may further comprise the steps of: (iii) generating at least one sequence of veiled secret values starting from at least one of the first secret value and the second secret value; (iv) performing the method of any of the preceding claims using at least one of the first secret value and the second secret value; (v) redeeming at least one blockchain transaction to reveal at least one of the first secret value and the second secret value, thereby revealing at least one veiled secret value of said sequence.

[0028] This allows us to perform a series of secure atomic exchanges more efficiently than a simple iteration of the method, since less storage space is required to store the secret. Furthermore, the number of rounds of communication is reduced, which saves time and improves security.

[0029] Performing at least step (ii) of the method may use at least one veiled secret value disclosed in step (v) of the method. This provides the advantage of further improving the efficiency of the method.

[0030] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described herein.

[0031] Embodiments of the present invention will now be described, by way of example only and not in a limiting sense, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0032] [Figure 1] 1 shows a flow chart illustrating the steps taken in a method embodying the present invention. [Figure 2] 1 is a schematic diagram of an exemplary system for determining a common secret for a first node and a second node that may be used in accordance with the present invention to securely transmit sensitive information; [Figure 3] 1 is a flowchart of a computer-implemented method for determining a common secret that may be used in accordance with the present invention to securely transmit sensitive information. [Figure 4] 1 is a flowchart of a computer-implemented method for registering first and second nodes. [Figure 5] 4 is another flowchart of a computer-implemented method for determining a common secret that may be used in accordance with the present invention to securely transmit sensitive information. DETAILED DESCRIPTION OF THE INVENTION

[0033] An atomic transaction exchange on a blockchain means that for two transactions, one from a first user, Alice, to a second user, Bob, and another from Bob to Alice, either both transactions are completed or neither is completed.

[0034] The present invention involves enabling Alice and Bob to each generate a secret, denoted A0 and B0, respectively. If Alice and Bob trust each other, they can exchange information, including these secrets, using a communication channel that is not part of the present blockchain protocol. They may use the secure secret exchange described below under the subheading "Determining a Common Secret."

[0035] Suppose one party is untrustworthy and will not share his or her secret. With the present invention, the only way this party can spend his or her funds is to reveal his or her secret on the blockchain, thereby making it public and available to other users. This is due to the structure of the transactions used in the exchange. Thus, the method does not require either party to trust the other party.

[0036] In one embodiment of the present invention, there are two secrets: one generated by and accessible to Alice, and one generated by and accessible to Bob, which are communicated through a channel outside the blockchain.

[0037] Single atomic swap P A0 corresponds to the private key S A0 denote Alice's elliptic curve digital signature algorithm (ECDSA) public key with P B0 is the private key S B0 Let denote Bob's public key with

[0038] 1. Alice has a secret that only she knows.

number

number

[0039] 2. Alice and Bob open a communication channel between them. This may be a secure communication channel generated using the method described below under the subheading "Determining a Common Secret." They then share their public keys and hashes of their respective secrets. The hash values of A0 and B0 are denoted H(A0) and H(B0), where a standard hash function such as SHA-256 may be used. The values H(A0) and H(B0) may also be publicly shared. Both Alice and Bob P A0 , P B0 , H(A0), H(B0) I know.

[0040] 3. Alice and Bob have deterministic keys H(A0)|H(B0) (where "|" indicates the OP_CAT operation) or alternatively H(H(A0)|H(B0)) Calculate a derivative hash such as

[0041] 4. Alice and Bob now have their derived public keys

number

number

[0042] H(A0)|H(B0)|Z Additional privacy can be achieved by incorporating a deterministic pseudorandom-looking value such as where Z is something both parties can calculate based on a shared starting value, such as a pre-agreed zeta function.

[0043] 5. Alice and Bob construct the following lock script. The script is described schematically here; an example implementation in Bitcoin script is shown later.

number

number

[0044] 6. Alice uses the locking script LockingScript(B) to B1 Bob creates transaction tx1 to P using locking script LockingScript(A). A1 At this stage, both Alice and Bob have A1 and P B1 The funds in cannot be spent because neither party knows both A0 and B0. These transactions are sent to the network and then appear on the blockchain.

[0045] 7. Alice sends secret A0 to Bob, and Bob sends secret B0 to Alice. This is done using the communication channel between Alice and Bob established above. Alice and Bob can verify that these hash values are correct by checking that they are equal to H(A0) and H(B0).

[0046] 8. Assuming that Alice and Bob are both honest and share the correct secret, both parties can A1 and P B1 The locked funds can be spent at and the atomic swap is complete.

[0047] 9. For example, suppose Bob does not send his correct secret B0 to Alice. Because of the locking script LockingScript(B), Bob cannot send P B1 To spend the funds locked in P, Bob must reveal his secret B0 in the unlocking script. As a result, as soon as Bob spends the funds, Alice knows Bob's secret and therefore P A1This ensures that either Alice and Bob can both spend their funds, or neither can spend their funds.

[0048] Below is an example lock and unlock script for Alice in step 4 above, compatible with the Bitcoin blockchain: Rock Script About Alice: OP_DUP OP_HASH160 <Hash160 P A1 >OP_EQUALVERIFY OP_CHECKSIG OP_HASH256<Hash256 A0> OP_EQUALVERIFY OP_HASH256<Hash256 B0> OP_EQUALVERIFY Alice unlock script: <b0> <a0><SigP A1 > <P A1 > Note that transactions to Pay To Public Key Hash (P2PKH) addresses and Pay To Script Hash (P2SH) addresses both allow the above types of locking and unlocking scripts. For P2SH addresses, the locking script is presented as a hash of the redemption script, which contains the same information.

[0049] The above method is described with reference to a blockchain that uses a public / private key encryption system similar to ECSDA used in the Bitcoin blockchain. However, the method can be generalized to any cryptographic mechanism that requires a secret of any form (which can be any data structure) to be disclosed in an unlock script. All that is required is a lock script, a transaction, and a blockchain, which is a secure and verifiable communication channel.

[0050] Time-locked refund transactions If Bob refuses to give Alice his correct secret B0 and B1 If Alice does not also unlock the funds stored in P, Bob's secret is not revealed to her, and Alice can A1 Furthermore, Alice cannot unlock the funds stored in P B1 It is also not possible to recover funds stored in

[0051] This problem can be solved by introducing a new transaction from Bob to Alice that is configured to send the funds back after a certain time if the funds have not been spent. This also requires some slight modifications to LockingScript(A) and LockingScript(B), which are described below.

[0052] This new transaction makes use of a time-dependent operation in the lock script that allows the transaction to be accepted by the block only after some pre-specified time has passed. For example, in the Bitcoin script, this may be the Check Sequence Verify (CSV) operation for a relative time since a specified value, or the Check Lock Time Verify (CLTV) operation for a fixed time value.

[0053] The locking script from step 4 above is modified as follows to include the option to consume if both Alice and Bob agree to sign:

number

[0054] After step 4 and before step 5 of the above method, two new transactions are created: Alice returns all of Bob's funds, P A1 Transaction t to Bob x4 This transaction is time-locked so that it will only be accepted in a block after a certain amount of time (e.g., 24 hours). Bob generates P B1 Generate a similar transaction tx3 from Alice to Alice. Transactions tx3 and tx4 are the same as the lock scripts

number

[0055] Alice signs tx4 and sends it to Bob, who signs and sends it to the network. Similarly, Bob signs tx3 and sends it to Alice, who signs and sends it to the network.

[0056] At this stage, if either party does not comply, the process is aborted and no funds are transferred. If both parties comply, step 5 of the method above is executed. Now, if neither party spends the funds exchanged in the atomic swap, the funds are returned to their original owners after 24 hours.

[0057] Here, a 24 hour CSV relative time was used as an example, but any relative time in the future, or any specific time in the future (eg, using the CLTV operator) could be used.

[0058] Here is an example of a locking script that uses the Bitcoin blockchain to return funds to Alice after 24 hours: "24h" OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 <Hash160 P A1 >OP_EQUALVERIFY OP_CHECKSIG The corresponding unlock script is <Sig P A1 > <P A1 > is given by

[0059] Masking the secret value Further embodiments include a masking step so that the values A0 and B0 are known only to Alice and Bob and are never revealed to the public.

[0060] Initially, both Alice and Bob share a shared secret S known only to them. C This can be accomplished through the secure exchange of secrets using the methods described below under the subheading "Determining a Common Secret."

[0061] Alice and Bob then define a new secret.

[0062] A'0=A0+S C B'0=B0+S C They then proceed as outlined above, but using the masked secrets A'0 and B'0 instead of the original secrets. During the atomic swap, only the masked secrets are publicly visible on the blockchain. This is useful if the secret values A0 and B0 are also used in other contexts, such as in further embodiments described below.

[0063] A further embodiment allows Alice and Bob to perform a series of n atomic swaps. Each party starts with a random secret and creates a sequence of hash values of this secret, called the Access Chain. After an atomic swap is performed, the hash value of the next secret is revealed, which will be used in the next atomic swap. This process is repeated iteratively up to n times.

[0064] This method offers efficiency savings over a series of individual swaps in that Alice and Bob only need to store one secret at a time, requiring less storage space for secrets. The next secret can be calculated from the hash of the previous secret. There are fewer rounds of communication between them, as they do not need to communicate the hash of the secret each time. This saves time and improves security.

[0065] The method is as follows: Alice and Bob agree on the number of iterative exchanges, n. They each select a random value, A n and B n Alice computes the following access chain:

number

[0066] The way these swaps are performed is outlined below. It should be understood that Bob goes through an equivalent process.

[0067] 1. Alice creates her chain A0,A1,…,A n , Bob's public key P B0 , start with Bob's secret hash H(B0). As before, H(B0) may be publicly shared by Bob.

[0068] 2. Alice creates a derived public key

number

number

[0069] 3. Alice and Bob perform the first swap. As mentioned before, this involves exchanging A0 and B0 between Alice and Bob. This means that after the swap, Alice knows H(B1) = B0.

[0070] 4. Alice repeats step 2 of this method, but with Bob's second secret hash in the chain, H(B1). Explicitly, Alice creates the derived public key

number

number

[0071] 5. Once the second swap is complete, Alice knows H(B2) = B1. She repeats step 2 again using Bob's third secret hash, H(B2).

[0072] 6. This process is iteratively repeated until no swaps are completed or a maximum number of n swaps is reached.

[0073] As described in the previous embodiment, the pseudorandom value Z i Calculate H(A i )|H(B i )|Z i Further security can be built in by introducing a function, e.g., a hash function Z i-1 =H(Z i ) should be transformed at each iteration.

[0074] The atomic swap outlined above is not constrained to the Bitcoin blockchain. A key component of the atomic swap method described above is that when one party spends funds in step 7, they reveal their secret on the blockchain. This means that the method described above can be used to perform an atomic swap on any blockchain that accepts the lock and unlock scripts of the form given in step 4.

[0075] Additionally, atomic swap methods may be used to exchange cryptocurrencies, for example, Alice may send Bitcoin to Bob on the Bitcoin blockchain, and Bob may send Ethereum to Alice on the Ethereum blockchain. [Table 1]

[0076] The only constraint on atomic swaps between two different blockchains is that they allow the use of the same hash function in the hash puzzles in their lock scripts (or equivalently). Here's why: Suppose Alice's blockchain only allows the SHA-256 hash algorithm, and Bob's blockchain only allows the SHA-384 algorithm. Bob sends Alice the SHA-256 hash of a secret, but in Bob's lock script, he sets up a SHA-384 hash puzzle for a different secret. When Bob spends his funds, his unlock script will reveal a secret that is useless to Alice, and Alice will have no way of knowing this until Bob runs out of funds.

[0077] According to a further embodiment, there is provided a method for allowing two parties to each generate a public key for which the corresponding private key is either made accessible to both parties or to neither party. The method utilizes the atomic swap method described above to exchange two secret values between the parties. These secret values are used to calculate the private key.

[0078] One application of this method is to allow two parties to exchange multiple types of cryptocurrencies controlled by a single public / private key pair. The method allows Alice and Bob to each generate a public key for which the private key is not known until an atomic swap is performed. The atomic swap ensures that either Alice and Bob can compute the corresponding private key, or neither can compute the private key.

[0079] The method is described below using an ECDSA private / public key pair, such as those used in Bitcoin, Ethereum, and Dash. However, the method does not critically depend on the ECDSA protocol and can be easily adapted to any public / private key-based cryptosystem that allows deterministic generation of a new secure public key from an existing private key and a known deterministic key.

[0080] This method is pseudonymous in the sense that partial information about the new private key is stored in one or more blockchains, which are open ledgers, however only the parties involved in the process can decrypt this information, so security is never compromised.

[0081] 1. Alice receives the corresponding public key P A =S A ·Private key S with G A Bob starts with a secret S2 known only to him. He has the corresponding public key P B =S B ·Private key S with G B So, let's start with S1, a secret that only I know.

[0082] 2. Alice sends P2 = S2 · G to Bob, and Bob sends P1 = S1 · G to Alice. Their secrets are not revealed in this process because they are multiplied by the base point of the elliptic curve; P2 and P1 may be public.

[0083] 3. Alice creates a new public key P that can be used as an address to receive Bitcoin transactions (or the equivalent for altcoins). AE =P A +P1. Bob creates a new public key P BE =P B Create +P2.

[0084] According to the properties of elliptic curve cryptography, P AE The private key corresponding to AE =S A +S1, that is, P AE =S AE ·G. P BE The private key corresponding to BE =S B +S2.

[0085] At this stage, Alice does not know S1, so P AE Bob knows S1 but does not know the private key for S A Therefore, P AE By the same logic, neither Alice nor Bob knows the secret key for P BE I don't know the private key for

[0086] 4. Alice receives Bob's address P BE and Bob sends Alice's address P AE These transactions may be exchanges of some cryptocurrency using a public / private key system, or may involve exchanging tokens or even physical assets with a public key P AE and P BE The ownership of the property may be transferred to another company. A combination of the above may also be used.

[0087] 5. Alice and Bob now initialize an atomic swap as described above using any blockchain, with S2 and S1 as their respective secrets.

[0088] 6. Alice and Bob exchange secrets, i.e., [Table 2] Alice and Bob may verify that they received the correct secrets using the formula P1 = S1 · G, P2 = S2 · G. They cannot spend the output of the atomic swap without exchanging the correct values.

[0089] 7. Now Alice has S1 and P AE , and no one except Alice can calculate the private key corresponding to Alice's private key S A Therefore, even if S1 is publicly known, no one else knows P AE Similarly, Bob now has secret S2 and cannot compute the private key corresponding to P BE However, no one can do this except Bob. If neither Alice nor Bob uses their own transaction output in the atomic swap, Alice's secret S2 is not revealed to Bob, and Bob's secret S1 is not revealed to Alice. In this case, neither Alice nor Bob has P AE and P BE It is not possible to calculate the private key corresponding to

[0090] Blockchains use a public / private key cryptography system to sign transactions and prove ownership of transaction outputs. This allows the P AE and P BE For example, in step 3 above, P AE and P BE After establishing Alice will transfer BCH and ETH funds to BE Go to Bob will hold BCH and DASH funds. AE Move to.

[0091] Once the atomic swap is performed, P BE and P AE The private keys to are unlocked. These unlock the funds in the Bitcoin and Ethereum public keys held by Alice and the Bitcoin and Dash public keys held by Bob, so the next transaction from Alice to Bob can be completed securely. [Table 3]

[0092] Note that these blockchains do not have to allow the same hash function in the lock script.

[0093] The above gives a general method for two parties to unlock a public key through a secret exchange using an atomic swap. This has applications beyond cryptocurrency exchanges and is relevant to any system that uses public / private key cryptography similar to ECDSA. For example, other use cases include, but are not limited to: 1. Providing access to a Distributed Hash Table (DHT); 2. Encrypted calculations; 3. Private email client; 4. Access to logistics data and exchange; 5. Swap of goods and services; 6. Private value exchange; 7. Key hierarchy.

[0094] Determining the common secret Security can be improved by using a secure method of exchanging information between two parties, using a public / private key system such as those described below, where appropriate.

[0095] A common secret (CS) is established between two parties and can then be used to generate a secure encryption key for the transmission of one or more of the shares. The common secret (CS) is any secret (S A,B,1,2 ), generated and used to enable the secure exchange of, for example, secret values, keys, or shares thereof.

[0096] For convenience, Alice and Bob are hereafter referred to as the first node (C) and the second node (S). The goal is to generate a common secret (CS) that is known to both nodes, but is not transmitted over the communication channel, thus eliminating the possibility of its unauthorized discovery.

[0097] The secure transmission technique involves a CS being generated independently at each end of the transmission. Thus, both nodes know the CS, but the CS does not have to travel through a potentially insecure communication channel. Once the CS is established at both ends, it can be used to generate secure encryption keys that both nodes can then use for communication.

[0098] 2 illustrates a system 1 including a first node 3 communicating with a second node 7 over a communications network 5. The first node 3 has an associated first processing device 23, and the second node 5 has an associated second processing device 27. The first and second nodes 3, 7 may include electronic devices such as computers, phones, tablet computers, mobile communications devices, computer servers, etc. In one example, the first node 3 may be a client (user) device and the second node 7 may be a server. The server may be a server of a digital wallet provider.

[0099] The first node 3 receives the master private key (V 1C ) and the first node's master public key (P 1C ) The second node (7) is associated with a first asymmetric cryptographic pair having the second node's master private key (V 1S ) and the second node's master public key (P 1S ) In other words, the first and second nodes each hold a public-private key pair.

[0100] The first and second asymmetric cryptographic pairs for each first and second node 3, 7 may be generated during a registration process, such as registration for a wallet. The public key for each node may be publicly shared over the communications network 5.

[0101] To determine the common secret (CS) at both the first node 3 and the second node 7, the nodes 3, 7 perform the steps of their respective methods 300, 400 without communicating the secret key over the communications network 5.

[0102] The method 300 performed by the first node 3 includes obtaining at least the master private key (V 1C ) and the Generator Value (GV), the first node's second private key (V 2C The generator value may be based on a message (M) shared between the first node and the second node, which may include sharing the message over the communication network 5, as described in more detail below. The method 300 also includes determining (330) a master public key (P 1S ) and the generator value (GV) of the second node, 2S The method 300 includes determining (370) a second private key (V 2C ) and the second node's second public key (P 2S ) and determining a common secret (CS) based on the

[0103] The same common secret (CS) can also be determined at the second node 7 by the method 400. The method 400 determines the master public key (P 1C ) and the generator value (GV), the second public key (P 2C ) of the second node. 1S ) and the generator value (GV) based on which the second node's second private key (V 2S ) of the second node. 2S ) and the first node's second public key (P 2C ) and determining a common secret (CS) based on the

[0104] The communications network 5 may include a local area network, a wide area network, a cellular network, a wireless communications network, the Internet, etc. These networks, in which data may be transmitted over communications media such as electrical wires, optical fibers, or wirelessly, may be subject to eavesdropping, such as by an eavesdropper 11. The methods 300, 400 may allow both the first node 3 and the second node 7 to independently determine the common secret without transmitting the common secret over the communications network 5.

[0105] In this way, one advantage is that the common secret (CS) can be securely and independently determined by each node without the need to transmit a secret key over a potentially insecure communications network 5. The common secret may then be used as (or as the basis for) a secret key for encrypted communications between the first node 3 and the second node 7 over the communications network 5.

[0106] The method 300, 400 may include additional steps. The method 300 comprises, at the first node 3, transmitting the message (M) and the second private key (V) of the first node. 2C ) to the second node 7. The method 300 may further include transmitting (360) the first signed message (SM1) to the second node 7 over the communication network. The second node 7 may then perform step 440 of receiving the first signed message (SM1). The method 400 may also include receiving a second public key (P 2C ), and step 460 of authenticating the first node 3 based on the result of validating the first signed message (SM1). Advantageously, this allows the second node 7 to authenticate that the purported first node (where the first signed message was generated) is the first node 3. This means that only the first node 3 has the master private key (V 1C ), so that only the first node 3 has access to the first node's second private key (V 2C ) can be determined. Similarly, it will be appreciated that a second signed message (SM2) can be generated at the second node 7 and sent to the first node 3, thereby enabling the first node 3 to authenticate the second node 7 as in a peer-to-peer scenario.

[0107] Sharing the message (M) between the first node and the second node may be accomplished in a variety of ways. In one example, the message is generated at the first node 3 and then sent to the second node 7 over the communication network 5. Alternatively, the message may be generated at the second node 7 and then sent to the second node 7 over the communication network 5. In yet another example, the message may be generated at the third node 9 and sent to both the first node 3 and the second node 7. In yet another alternative, a user may enter a message through the user interface 15, which is received by the first and second nodes 3, 7. In yet another example, the message (M) may be retrieved from the data store 19 and sent to the first and second nodes 3, 7. In some examples, the message (M) may be public and thus transmitted over an insecure network 5.

[0108] In a further example, one or more messages (M) may be stored in a data store 13, 17, 19, where the message may be associated with some entity, such as a digital wallet, or a communication session established between a first node 3 and a second node 7. In this manner, the message (M) may be retrieved and used at each of the first and second nodes 3, 7 to recreate a common secret (CS) associated with that wallet or session.

[0109] Advantageously, a record allowing the recreation of the common secret (CS) may be kept without the record itself having to be stored privately or transmitted securely. This may be advantageous where a large number of transactions are carried out at the first and second nodes 3, 7 and it is impractical to store all the messages (M) at the nodes themselves.

[0110] Examples of registration methods 100, 200 are described with reference to Figure 4, where method 100 is performed by a first node 3 and method 200 is performed by a second node 7. This involves establishing first and second asymmetric cryptographic pairs for the first and second nodes 3, 7, respectively.

[0111] An asymmetric cryptographic pair contains an associated private key and a public key, such as those used in public key cryptography. In this example, the asymmetric cryptographic pair is created using the properties of elliptic curve cryptography (ECC) and elliptic curve arithmetic.

[0112] Standards for ECC may include known standards such as those described by the Standards for Efficient Cryptography Group (www.sceg.org). Elliptic curve cryptography is also described in US 5,600,725, US 5,761,305, US 5,889,865, US 5,896,455, US 5,933,504, US 6,122,736, US 6,141,420, US 6,618,483, US 6,704,870, US 6,785,813, US 6,078,667, and US 6,792,530.

[0113] In methods 100 and 200, this involves the first and second nodes agreeing on a common ECC system and using a base point (G). (Note: The base point can be referred to as a Common Generator, but the term base point is used to avoid confusion with the generator value GV.) In one example, the common ECC system may be based on secp256K1, the ECC system used by Bitcoin. The base point (G) can be selected, randomly generated, or assigned.

[0114] Turning now to the first node 3, the method 100 includes determining 110 a common ECC system and base point (G). This may include receiving the common ECC system and base point from the second node 7 or the third node 9. Alternatively, a user interface 15 may be associated with the first node 3, allowing a user to selectively provide the common ECC system and / or base point (G). In yet another alternative, one or both of the common ECC system and / or base point (G) may be randomly selected by the first node 3. The first node 3 may send a notification over the communication network 5 to the second node 7 indicating the use of the common ECC system with the base point (G). The second node 7 may then settle 210 by sending a notification indicating an acknowledgment to the use of the common ECC system and base point (G).

[0115] The method 100 is performed by the first node 3 obtaining the first node's master private key (V 1C ) and the first node's master public key (P 1C ), which is based, at least in part, on random integers within an acceptable range specified in a common ECC system, and a first master private key (V 1C ), which also includes generating the first node's master private key (P 1C ) and the formula for the base point (G): P 1C =V 1C ×G (Formula 1) The first node's master public key (P 1C )

[0116] Thus, the first asymmetric cryptographic pair includes: V 1C : a master private key of the first node, held secretly by the first node; P 1C : The master public key of the first node, which is made public.

[0117] The first node 3 receives the master private key (V 1C ) and the first node's master public key (P 1C ) may be stored in a first data store 13 associated with the first node 3. For security purposes, the master private key (V 1C ) may be stored in a secure part of the first data store 13 to ensure that the key remains secret.

[0118] The method 100 further comprises transmitting the master public key (P 1C ) to the second node 7. The second node 7 transmits 130 the master public key (P 1C ) is received 220, the first node's master public key (P 1C ) may be stored 230 in a second data store 17 associated with the second node 7.

[0119] Similar to the first node 3, the method 200 of the second node 7 involves obtaining the master private key (V 1S ) and the second node's master public key (P 1S ) of the second node. 1S ) is also a random integer within the acceptable range. Next, the master public key (P 1S ) is determined by the following formula: P 1S =V 1S ×G (Formula 2)

[0120] Thus, the second asymmetric cryptographic pair includes: V 1S : the master private key of the second node, held secretly by the second node; P 1S : The master public key of the second node, which is made public.

[0121] The second node 7 may store the second asymmetric cryptographic pair in the second data store 17. The method 200 may further include providing the first node 3 with the second node's master public key (P 1S ) 250. The first node 3 then transmits the master public key (P 1S ) may be received 140 and stored 150.

[0122] It will be appreciated that in some alternatives, each public master key may be received and stored in a third data store 19 associated with a third node 9 (e.g., a trusted third party). This may include a third party acting as a public directory, such as a certificate authority. Thus, in some examples, the first node's public master key (P 1C ) can be requested and received by the second node 7 (and vice versa) only when the common secret (CS) is needed.

[0123] The registration step may be required only once, for example as an initial setup of a digital wallet.

[0124] An example of determining a common secret (CS) will now be described with reference to Figure 5. The common secret (CS) may be used for a particular session, time, transaction, or other purpose between the first node 3 and the second node 7, and it may be undesirable or insecure to use the same common secret (CS). As such, the common secret (CS) may change between different sessions, times, transactions, etc.

[0125] The following is provided to illustrate the secure transmission techniques described above.

[0126] In this example, the method 300 performed by the first node 3 includes generating 310 a message (M). The message (M) may be random, pseudorandom, or user-defined. In one example, the message (M) is based on Unix time and a nonce (and any value). For example, the message (M) may be given as follows:

[0127] Message (M) = Unix time + nonce (Equation 3)

[0128] In some examples, the message (M) is arbitrary. However, it is understood that the message (M) may have alternative values (e.g., Unix time, etc.) that may be useful in some applications.

[0129] The method 300 includes transmitting 315 the message (M) to the second node 7 over the communication network 3. Because the message (M) does not include information about the private key, the message (M) may be transmitted over an insecure network.

[0130] The method 300 further includes step 320 of determining a generator value (GV) based on the message (M). In this example, this involves determining a cryptographic hash of the message. An example of a cryptographic hash algorithm includes SHA-256, which generates a 256-bit generator value (GV). That is, GV=SHA-256(M) (Equation 4)

[0131] It is understood that other hash algorithms may be used. This may include other algorithms in the Secure Hash Algorithm (SHA) family. Some specific examples include instances in the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. Other hash algorithms may include those in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. A specific example may include RIPEMD-160. Other hash functions may include families based on the Zemor-Tillich hash function and knapsack-based hash functions.

[0132] The method 300 then calculates the master private key (V 1C ) and the generator value (GV) based on which the second private key (V 2C ) of the first node according to the formula: 1C ) and a generator value (GV): V 2C =V 1C +GV (Equation 5)

[0133] In this way, the second private key (V 2C ) is not a random value, but is deterministically derived from the master private key of the first node. The corresponding public key in the cryptographic pair, i.e., the second public key (P 2C ) have the following relationship: P 2C =V 2C ×G (Formula 6) V from Equation 5 2C Substituting into equation 6, we get: P 2C =(V 1C +GV)×G (Formula 7) Here the '+' operator refers to elliptic curve point addition. Note that elliptic curve cryptography algebra is distributive, so Equation 7 can be expressed as: P 2C =V 1C ×G+GV×G (Formula 8) Finally, we can substitute Equation 1 into Equation 7 to give: P 2C =P 1C +GV×G (Formula 9.1) P 2C =P 1C +SHA-256(M)×G (Equation 9.2)

[0134] In this way, the second public key (P 2C ) is the master public key (P 1C ) and the message (M). The second node 7 obtains the second public key (P 2C ), which is discussed in more detail below with respect to method 400.

[0135] The method 300 further comprises: combining the message (M) and the determined second private key (V) of the first node; 2C ) to generate 350 a first signed message (SM1). Generating the signed message includes applying a digital signature algorithm to digitally sign the message (M). In one example, this involves signing the message with the first node's second private key (V) in an Elliptic Curve Digital Signature Algorithm (ECDSA). 2C ) to obtain a first signed message (SM1).

[0136] Examples of ECDSA include those based on ECC systems using secp256k1, secp256r1, secp384r1, and sec3cp521r1.

[0137] The first signed message (SM1) is sent to the second node 7 using the corresponding second public key (P 2C ) This verification of the first signed message (SM1) may be used by the second node 7 to authenticate the first node 3, which is discussed in method 400 below.

[0138] The first node 3 then receives the second public key (P 2S ) of the second node. As discussed above, the second node may determine 370 the second public key (P 2S ) contains at least the master public key (P 1S ) and the generator value (GV). In this example, the public key is determined 370' as the private key multiplied by the base point (G) and the elliptic curve point, so that the second public key (P2S) of the second node can be expressed in a manner similar to Equation 6 as: P 2S =V 2S ×G (Equation 10.1) P 2S =P 1S +GV×G (Equation 10.2) The mathematical proof of Equation 10.2 is given by the second public key (P 2C ) It will be appreciated that the first node 3 can determine 370 the second node's second public key independently of the second node 7.

[0139] The first node 3 then transmits the determined second private key (V 2C ) and the determined second public key of the second node (P 2S ) the first node 3 may determine 380 a common secret (CS). The common secret (CS) may be determined by the first node 3 according to the following formula: S=V 2C ×P 2S (Formula 11)

[0140] Method 400 performed in second node 7 We will now describe the corresponding method 400 performed in the second node 7. It will be understood that some of these steps are similar to the steps performed by the first node 3 above.

[0141] The method 400 includes receiving 410 a message (M) over the communication network 5 from the first node 3. This may include the message (M) sent by the first node 3 in step 315. The second node 7 then determines 420 a generator value (GV) based on the message (M). The step 420 of determining the generator value (GV) by the second node 7 is similar to the step 320 performed by the first node 3 described above. In this example, the second node 7 performs this determination step 420 independently from the first node 3.

[0142] The next step is to create the master public key (P 1C ) and the generator value (GV), the second public key (P 2C In this example, the public key is determined 430′ as the private key multiplied by the base point (G) and the elliptic curve point, so that the first node's second public key (P 2C ) can be expressed in a similar manner to Equation 9 as: P 2C =V 2C ×G (Equation 12.1) P 2C =P 1C +GV×G (Equation 12.2) The mathematical proofs of Equations 12.1 and 12.2 are the same as those discussed above for Equations 10.1 and 10.2.

[0143] The method 400 may include steps performed by the second node 7 to authenticate the purported first node 3 as the first node 3. As discussed above, this includes receiving 440 a first signed message (SM1) from the first node 3. The second node 7 then receives 440 the first node's second public key (P 2C ) may be used to validate 450 the signature on the first signed message (SM1).

[0144] Verification of the digital signature may be done according to the Elliptic Curve Digital Signature Algorithm (ECDSA) discussed above. Importantly, the first node's second private key (V 2C ) is signed using V 2C and P 2C form a cryptographic pair, the second public key (P 2C ) are used to verify the keys. These keys are generated when the first node 3 registers, using the master private key (V 1C ) and the first node's master public key (P 1C ), verifying the first signed message (SM1) can be used as a basis for authenticating that the purported first node sending the first signed message (SM1) is the same first node 3 at the time of registration. Thus, the second node 7 may further perform the step of authenticating (460) the first node 3 based on the result of validating (450) the first signed message.

[0145] The above authentication may be suitable for scenarios where one of two nodes is a trusted node and only one of the nodes needs to be authenticated. For example, the first node 3 may be a client, and the second node 7 may be a server trusted by the client, such as a wallet provider. In this manner, the server (second node 7) may need to authenticate the credentials of the client (first node 3) to allow the client to access the server system. It may not be necessary for the server to authenticate the server's credentials to the client. However, in some scenarios, such as peer-to-peer scenarios, it may be desirable for both nodes to be authenticated to each other.

[0146] The method 400 further comprises the step of: the second node 7 transmitting the master private key (V 1S ) and the generator value (GV) based on which the second node's second private key (V 2S ) of the second node 3. Similar to step 330 performed by the first node 3, determining 470 the second private key (V 2S ) is calculated from the master private key (V 1S ) and a generator value (GV): V 2S =V 1S +GV (Equation 13.1) V 2S =V 1S +SHA-256(M) (Equation 13.2) The second node 7 then independently of the first node 3 obtains the second node's second private key (V 2S ) and the first node's second public key (P 2C ), a common secret (CS) may be determined 480 based on the following formula: S=V 2S ×P 2C (Formula 14) The common secret (CS) determined by the first node 3 is the same as the common secret (CS) determined at the second node 7. We now provide a mathematical proof that Equation 11 and Equation 14 give the same common secret (CS).

[0147] Looking at the common secret (CS) determined by the first node 3, substituting Equation 10.1 into Equation 11 gives: S=V 2C ×P 2S (Formula 11) S=V 2C ×(V 2S ×G) S=(V 2C ×V 2S )×G (Equation 15) Looking at the common secret (CS) determined by the second node 7, substituting Equation 12.1 into Equation 14, we get: S=V 2S ×P 2C (Formula 14) S=V 2S ×(V 2C ×G) S=(V 2S ×V 2C )×G (Equation 16) Since ECC algebra is commutative, Equation 15 and Equation 16 are equivalent because: S=(V 2C ×V 2S )×G=(V 2S ×V 2C )×G (Equation 17)

[0148] The common secret (CS) may now be used as a private key or as the basis for a private key in a symmetric key algorithm for secure communication between a first node 3 and a second node 7. This communication may be used to convey a portion of the private key, a representation of or identifier for the private key, or a mnemonic for the private key. Thus, once the present invention is used, for example, in setting up a digital wallet or other controlled resource, secure communication between the two parties can then take place.

[0149] The common secret (CS) is the elliptic curve point (x S ,y S ), which may be converted into a standard key format using standard well-known operations agreed upon by nodes 3 and 7. For example, x S The value is AES 256 It may be a 256-bit integer that can be used as a key for encryption, or it may be converted to a 160-bit integer using RIPEMD160 for any application requiring a key of this length.

[0150] The common secret (CS) may be determined as needed. Importantly, the first node 3 does not need to store the common secret (CS), as it can be determined again based on the message (M). In some examples, the message (M) used may be stored in a data store 13, 17, 19 (or other data store) without the same level of security required for a master private key. In some examples, the message (M) may be publicly available.

[0151] However, in some applications, the common secret (CS) is the master secret key (V 1C ), the common secret (CS) may be stored in a first data store (X) associated with the first node.

[0152] It should be noted that the above-described embodiments are illustrative rather than limiting of the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, reference signs placed between parentheses shall not be construed as limiting the claims. The use of words such as "comprise" and "have" does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. As used herein, "comprise" means "comprises or consists of," and "has" means "comprises or consists of." The singular reference of an element does not exclude the plural reference of such elements, and vice versa. The present invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. < / b0>

Claims

1. 1. A computer-implemented exchange method, the method comprising: (i) communicating a first veiled secret value from a first user to a second user by a device associated with the first user; (ii) receiving, by a device associated with the first user, a second veiled secret value from the second user; (iii) constructing a first blockchain transaction including the first veiled secret value and the second veiled secret value, the first blockchain transaction being configured to be unlockable to transfer control of a first resource when both the first secret value known to the first user and the second secret value known to the second user are provided in the first blockchain transaction; unlocking the first blockchain transaction by providing the first and second secret values to the first blockchain transaction as a result of the second user communicating the second secret value to the first user reveals the first secret value to the second user; unlocking the second blockchain transaction by providing the first and second secret values to the second blockchain transaction as a result of the first user communicating the first secret value to the second user reveals the second secret value to the first user; the second blockchain transaction includes the first veiled secret value and the second veiled secret value and is configured to be unlockable to transfer control of a second resource when both the first and second secret values are provided to the second blockchain transaction. method.

2. 2. The method of claim 1, wherein at least one of the first blockchain transaction and the second blockchain transaction is configured to be redeemable only upon application of a respective first private key and second private key.

3. 3. The method of claim 2, further comprising calculating at least one of (a) a first derived public key that is based at least in part on a first public key of the first user and (b) a second derived public key that is based at least in part on a second public key of the second user, wherein the first derived public key is part of a cryptographic key pair that includes the first private key and the second derived public key is part of a cryptographic key pair that includes the second private key.

4. 4. The method of claim 3, wherein calculating at least one of (a) a first derived public key that is based at least in part on the first public key of the first user and (b) a second derived public key that is based at least in part on the second public key of the second user further includes combining the first and second veiled secret values.

5. 5. The method of claim 4, wherein the combination of the first and second veiled secret values comprises at least one of a concatenation of the first veiled secret value and the second veiled secret value, and a concatenation of at least one veiled secret value with a random or pseudorandom value.

6. 6. The method of claim 1, further comprising constructing at least one of: a third blockchain transaction configured to return control of the first resource to the first user in response to the passage of a first period of time during which the first blockchain transaction is not redeemed; and a fourth blockchain transaction configured to return control of the second resource to the second user in response to the passage of a second period of time during which the second blockchain transaction is not redeemed.

7. 7. The method of claim 1, wherein at least one of the first veiled secret value and the second veiled secret value comprises a combination of at least one of the first secret value and the second secret value and a shared secret value accessible by both the first user and the second user.

8. The method of claim 7 , wherein the shared secret value is established as a common secret (CS) prior to step (i).

9. (iv) generating at least one sequence of veiled secret values starting from at least one of the first secret value and the second secret value; (v) performing the method of any one of claims 1 to 8 using at least one of the first secret value and the second secret value; (vi) redeeming at least one blockchain transaction to reveal at least one of the first secret value and the second secret value, thereby revealing at least one veiled secret value of the sequence; 9. The method according to any one of claims 1 to 8.

10. 10. The method of claim 9, further comprising performing at least step (iii) of the method of any one of claims 1 to 9 using the at least one veiled secret value revealed in step (vi).

Images