Computer-implemented systems and methods

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] This invention broadly relates to security methods and cryptographic techniques implemented on computers. More specifically, it relates to a method for atomically exchanging control of resources. This invention is suitable for one or more blockchains, such as the Bitcoin Cash (BCH) blockchain, but is not limited to these. [Background technology]

[0002] In this paper, 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. While Bitcoin may be referred to in this specification for illustrative purposes, it should be noted that the invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols fall within the scope of the invention. The term “user” in this specification may refer to a human or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger, implemented as a computer-based, decentralized system composed of blocks, each block consisting of a transaction. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and it contains at least one input and at least one output. Each block contains the hash of the previous block, thereby chaining the blocks together to create a persistent and immutable record of all transactions written to the blockchain since its inception. A transaction contains a small program known as a script embedded in its input and output, which specifies who can access the transaction's output and how. On 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 that each transaction is valid, and invalid transactions are rejected from the network. Software clients installed on the nodes perform 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 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 the transaction. 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 built by a miner, and iii) be mined, that is, added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to explore implementing new systems using both Bitcoin's underlying cryptographic security system and the data that can be stored on the blockchain. Blockchain would be highly advantageous if it could be used for automated tasks and processes not limited to the realm of cryptocurrency. Such solutions would allow for a wider range of applications while still leveraging the benefits of blockchain (e.g., permanent, tamper-proof recording of events, distributed processing, etc.).

[0006] The concept of atomic swaps has long been discussed in the cryptocurrency community. The exchange between parties is "atomic" in the sense that all participants either receive the desired resource (e.g., cryptocurrency tokens or coins) or no one receives it. As of this writing, Wikipedia describes atomic swaps as "a proposed feature in cryptocurrencies that would allow one cryptocurrency to be exchanged for another without the need for a trusted third party." In traditional cryptocurrencies, a trusted third party, such as a cryptocurrency exchange, is required to perform the swap to prevent parties from sending currency without receiving it in return. The atomic swap system uses a hash-time locked smart contract so that parties must deliver the swapped currencies within a specified time, otherwise the transaction is canceled. This preserves "atomicity" in the sense that "either the swap takes place, or the currencies are not swapped at all."

[0007] Thus, atomic swaps offer enhanced security for transfers conducted through blockchain. Eliminating the need for a trusted third party eliminates the risk of abuse and malicious intervention. Indeed, several security breaches or "hacking" incidents have occurred involving cryptocurrency exchanges, such as the Mt. Gox case. [Prior art documents] [Non-patent literature]

[0008] [Non-Patent Document 1] https: / / en.wikipedia.org / wiki / Atomic_swap [Overview of the project] [Problems that the invention aims to solve]

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

[0010] Thus, it is desirable to provide a cryptographically implemented resource exchange method that atomically exchanges trust-free and immutable resources or assets provided by blockchain technology, and improves the security of exchanges carried out through a blockchain implementation network.

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

[0012] According to the present invention, a computer-implemented replacement method is provided.

[0013] This method may include the following steps: (i) Communicating a first veiled secret value from the first user to the 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, each containing the first veiled secret and the second veiled secret, respectively, wherein the transactions are configured to be unlockable to transfer control of the respective first or second resource once both the first and second secrets are provided to the respective blockchain transaction.

[0014] Here, the first secret value is revealed to the second user by unlocking the first blockchain transaction, and the second secret value is revealed to the first user by unlocking the second blockchain transaction.

[0015] This method provides a secure way to ensure that secret values ​​are exchanged atomically in an untrusted environment, and no user of this method has greater control over it than any other user.

[0016] While it is not practically possible to determine a secret value from another secret value, it is practically possible to determine a secret value from another secret value; thus, secret values ​​are related to corresponding secret values.

[0017] As an example of this relationship, applying one-way functions such as hashing or modulo arithmetic to a secret value can yield a veiled secret value.

[0018] At least one of the first and second transactions may be configured to be redeemable only when applying the respective first and second private keys.

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

[0020] The method may further include the step of computing at least one of the following: (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. The first derived public key is part of a cryptographic key pair including the first private key, and the second derived public key is part of a cryptographic key pair including the second private key.

[0021] This allows assets to be stored in derived addresses rather than publicly known addresses, providing users of this method with additional privacy and security. It should be noted that the terms “Asset” and “Resource” may be used interchangeably as herein. The term “Asset” should not be interpreted solely as having a financial context or use. An asset could, for example, be a token representing some other entity on or outside the blockchain.

[0022] The step of computing 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 a combination of the first and second veiled secret values. This offers the advantage of providing a recorded, non-erasable link between the transaction and the atomic swap being performed.

[0023] A combination of the first and second veiled secret values ​​may include at least one of the following: 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. This offers the advantage of further enhancing transaction security through additional deterministic obfuscation.

[0024] The method may further include the step of constructing at least one of the following: a third blockchain transaction configured to return control of the first asset to the first user in response to the expiration of a first time period 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 expiration of a second time period during which the second transaction is not redeemed. This allows at least one user of this method to regain control of their respective assets if another user does not fully participate in the exchange, thereby increasing the versatility of this method.

[0025] At least one of the first veiled secret and the second veiled secret may include a combination of at least one of the first secret and the second secret and a shared secret accessible by both the first and second users. This offers the advantage of increased privacy and security provided by this method.

[0026] A shared secret may be established as a common secret before step (i). This offers the advantage of further enhancing the security of this method.

[0027] This method may further include the following steps: (iii) To generate at least one sequence of veiled secret values ​​beginning with at least one of the first secret value and the second secret value; (iv) Using at least one of the first secret value and the second secret value to perform any of the methods of the preceding claims; (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 the sequence.

[0028] This allows for a series of secure atomic exchanges to be performed with greater efficiency than simple repetition of this method, because less storage space is required to store secrets. Furthermore, the number of communication rounds is reduced, saving time and improving security.

[0029] The step of performing at least step (ii) of the Method may use at least one veiled secret value disclosed in step (v) of the Method. This offers the advantage of further improving the efficiency of this method.

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

[0031] Herein, embodiments of the present invention will be described with reference to the attached drawings, not in an restrictive sense, but merely as examples. [Brief explanation of the drawing]

[0032] [Figure 1] A flowchart illustrating the steps taken in the method for embodying the present invention is shown. [Figure 2] This is a schematic diagram of an exemplary system for determining a common secret between a first node and a second node, which can be used in accordance with the present invention to securely transmit highly confidential information. [Figure 3] This is a flowchart of a computer-implemented method for determining a common secret, which can be used in accordance with the present invention to securely transmit highly confidential information. [Figure 4] This is a flowchart of a computer-implemented method for registering the first and second nodes. [Figure 5] This is another flowchart of a computer-implemented method for determining a common secret, which may be used in accordance with the present invention to securely transmit highly confidential information. [Modes for carrying out the invention]

[0033] An atomic transaction exchange on the blockchain means that for two transactions—one from the first user, Alice, to the second user, Bob, and another from Bob to Alice—both transactions must be completed, or neither must be completed.

[0034] This invention includes enabling Alice and Bob to generate secrets designated A0 and B0, respectively. If Alice and Bob trust each other, they can exchange information containing these secrets using a communication channel that is not part of this blockchain protocol. They may also use a secure secret exchange, as described later under the subheading "Determining a Common Secret."

[0035] Suppose one party is untrustworthy and unwilling to share their secrets. According to this invention, the only way for this party to spend their funds is to reveal their secrets on the blockchain, thereby making them publicly available for use by other users. This is due to the structure of the transactions used in the exchange. Therefore, this method does not require either party to trust the other.

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

[0037] Single atomic swap P A0 The corresponding private key S A0 The public key of Alice's elliptic curve digital signature algorithm (ECDSA) is shown, and P B0 is the private key S B0 Let's assume we're showing Bob's public key, which has the following properties.

[0038] 1. Alice's 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 key and their respective secret hashes. The hash values ​​of A0 and B0 are denoted as 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 made public. Alice and Bob both, P A0 , P B0 , H(A0), H(B0) I know.

[0040] 3. Alice and Bob are deterministic keys H(A0)|H(B0) (Here, "|" represents the OP_CAT operation) or alternatively H(H(A0)|H(B0)) Calculate a derived hash like this.

[0041] 4. Alice and Bob's derived public key is here

number

number

[0042] H(A0)|H(B0)|Z Additional privacy can be achieved if values that appear to be deterministic and pseudorandom, such as

[0043] are incorporated. Here, Z is something that both parties can calculate, like a pre-agreed zeta function, based on a shared starting value.

Number

Number

[0044] 6. Alice uses LockingScript(B) to P B1 A transaction tx1 is created to P, and Bob uses the lock script LockingScript(A) to P A1 Create transaction tx2 for [the specified location]. At this stage, both Alice and Bob are P A1 and P B1 The funds cannot be used because neither party knows either A0 or 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 established between Alice and Bob above. Alice and Bob can verify that these hash values ​​are correct by confirming that their hash values ​​are equal to H(A0) and H(B0).

[0046] 8. If both Alice and Bob are honest and share the correct secret, then both parties are P A1 and P B1 The locked funds can be consumed, and the atomic swap is completed.

[0047] 9. For example, suppose Bob did not send Alice his true secret B0. Because of the form LockingScript(B), Bob would have P B1 In order to use the locked funds, Bob must reveal his secret B0 in the unlock script. As a result, as soon as Bob uses the funds, Alice learns Bob's secret, and therefore P A1This will allow them to use their own funds. This ensures that either Alice and Bob can use their own funds, or neither can use their own funds.

[0048] Below is an exemplary lock and unlock script for Alice in Step 4 above, which is compatible with the Bitcoin blockchain. A 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 Unlock script for Alice: <b0> <a0><SigP A1 > <P A1 > It should be noted that both Pay To Public Key Hash (P2PKH) addresses and Pay To Script Hash (P2SH) addresses accept the types of lock and unlock scripts described above. For P2SH addresses, the lock script is presented as a hash of the redemption script containing the same information.

[0049] The method described above is written with reference to blockchains that use a public / private key cryptography system similar to ECSDA used in the Bitcoin blockchain. However, this method can be generalized to any general cryptographic mechanism that requires the disclosure of a common form of secret (which can be any data structure) in the unlock script. What is needed is a lock script, a transaction, and a blockchain, which is a secure and verifiable communication channel.

[0050] Time-locked refund transaction If Bob refuses to give Alice his true secret B0, address P B1 If the funds stored in are not unlocked, Bob's secret will not be revealed to Alice, and Alice will not be able to access P A1 The funds stored in cannot be unlocked. Furthermore, Alice sent to Bob, P B1 It is also impossible to recover the funds stored there.

[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 period of time if the funds have not been used. This also requires some modifications to LockingScript(A) and LockingScript(B), which will be described later.

[0052] This new transaction utilizes time-dependent behavior in lock scripts, which allows the transaction to be accepted by the block only after a predetermined time has elapsed. For example, in Bitcoin scripts, this could be Check Sequence Verify (CSV) behavior for relative time since a specified value, or Check Lock Time Verify (CLTV) behavior for a fixed time value.

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

number

[0054] After step 4 of the above method, and before step 5, two new transactions are generated. Alice returns all of Bob's funds, P A1 Transaction t from Bob x4 This generates a time-locked transaction, which will only be accepted within a block after a certain period of time (for example, 24 hours). Bob is P B1 Generates a similar transaction tx3 from to Alice. Transactions tx3 and tx4 are their respective lock scripts.

number

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

[0056] If neither party complies at this stage, the process is terminated and the funds are not transferred. If both parties comply, step 5 of the method described above is performed. If neither party uses the funds exchanged in the atomic swap, the funds are returned to their original owners after 24 hours.

[0057] Here, a 24-hour relative time in CSV was used as an example, but it would be possible to use any relative time in the future, or any specific time in the future (for example, by using the CLTV operator).

[0058] Here is an example of a lock script that uses the Bitcoin blockchain to return funds to Alice in 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 of secrets Further embodiments include a masking step such that the values ​​A0 and B0 are known only to Alice and Bob and are never made public.

[0060] Initially, Alice and Bob shared a secret that only the two of them knew. C We agree on this. This can be achieved through the secure exchange of secrets using the method described later under the subheading "Determination of Common Secrets."

[0061] Next, Alice and Bob define a new secret.

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

[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 an access chain. When an atomic swap is performed, the hash value of the next secret to be used in the next atomic swap is revealed. This process can be repeated sequentially up to n times.

[0064] This method is more efficient than a sequence of individual swaps because Alice and Bob only need to store one secret at a time, requiring less storage space for each secret. The next secret can be calculated by hashing the previous secret. Since the hash of the secret doesn't need to be communicated each time, fewer communication rounds are required. This saves time and improves security.

[0065] This method is as follows: Alice and Bob agree on the number of repeated exchanges n. They each choose a random value A. n and B n Generates the following. Alice calculates the next access chain:

number

[0066] The methods for implementing these swaps are outlined below. It should be understood that Bob follows an equivalent process.

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

[0068] 2. Alice's derived public key

number

number

[0069] 3. Alice and Bob perform their first swap. As mentioned earlier, this involves the exchange of A0 and B0 between Alice and Bob. This means that after the swap, Alice will know H(B1)=B0.

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

number

number

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

[0072] 6. This process is repeated sequentially until the swap is not completed or the maximum number of swaps n is reached.

[0073] As described in the previous embodiment, the pseudo-random value Z i Calculate H(A i )|H(B i )|Z i By introducing it, further security can be incorporated. In this case, the function is, for example, the hash function Z i-1 =H(Z i The conversion should be performed for each iteration by using ).

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

[0075] Furthermore, atomic swap methods can be used to exchange cryptocurrencies. For example, it could be used for Alice to send Bitcoin to Bob on the Bitcoin blockchain, and for Bob to send Ethereum to Alice on the Ethereum blockchain. [Table 1]

[0076] The only constraint on an atomic swap between two different blockchains is that those blockchains allow (or are equivalent to) the use of the same hash function in the hash puzzle in the lock script. The reason is as follows: Suppose Alice's blockchain only allows the use of the SHA-256 hash algorithm, and Bob's blockchain only allows the SHA-384 algorithm. Bob sends Alice a secret SHA-256 hash, but Bob's lock script sets up a SHA-384 hash puzzle for a different secret. When Bob spends his funds, the unlock script reveals a secret that is useless to Alice, and Alice has no way of knowing this until Bob has run out of funds.

[0077] A further embodiment provides a method for enabling two parties to each generate a public key, wherein the corresponding private key for each public key is either accessible to both parties or inaccessible to both parties. This method utilizes the atomic swap method described above to exchange two secret values ​​between the two parties. These secret values ​​are used to compute 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. This method allows Alice and Bob to each generate a public key, the private key for that public key is unknown until an atomic swap takes place. The atomic swap ensures that either Alice and Bob can compute the corresponding private key, or neither can compute the private key.

[0079] This method is described below using ECSDA private and public key pairs, such as those used in Bitcoin, Ethereum, and Dash. However, this method is not critically dependent on the ECSDA protocol and can be easily adapted to any public / private key-based cryptosystem that can deterministically generate a new secure public key from an existing private key and a publicly known deterministic key.

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

[0081] 1. Alice has the corresponding public key P A =S A • Private key S with G A And so, he begins with a secret S2 that only he knows. Bob then uses the corresponding public key P. B =S B • Private key S with G B And so, I'll start with "A Secret Only I Know" S1.

[0082] 2. Alice sends Bob P2 = S2·G, and Bob sends Alice P1 = S1·G. Their secrets are multiplied by the base points of the elliptic curve and are therefore not disclosed in this process, and P2 and P1 may be publicly known.

[0083] 3. Alice creates a new public key P that can be used as an address to receive Bitcoin transactions (or similar for altcoins). AE =P A Create +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 corresponding private key is S AE =S A +S1, which means P AE =S AE It is G. BE The corresponding private key is S BE =S B It is +S2.

[0085] At this stage, Alice does not know S1, therefore P AE He doesn't know the secret key for S. Bob knows S1, but S A Unaware of this, therefore P AE They do not know the secret key for P. By the same logic, neither Alice nor Bob knows P. BE I don't know the private key for that.

[0086] 4. Alice is Bob's address P BE Bob made a transaction to Alice's address P AE Transactions are made to [a specific entity]. These transactions may be the exchange of some cryptocurrency using a public / private key system, or tokens or even physical assets using a public key P AE and P BE It may be transferred to the ownership of [another party]. Any combination of the above is also acceptable.

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

[0088] 6. Alice and Bob exchange secrets. That is, [Table 2] Alice and Bob may use the formulas P1=S1·G and P2=S2·G to verify that they have received the correct secret. They cannot consume the output of the atomic swap unless they exchange the correct values.

[0089] 7. Alice now holds S1, P AE The corresponding secret key can be calculated. Besides Alice, only Alice's secret key S A Since it is unknown, even if S1 is public, no one else can calculate the private key corresponding to P AE Similarly, now Bob holds the secret S2 and can calculate the private key corresponding to P BE , but no one other than Bob can do this. Neither Alice nor Bob will disclose Alice's secret S2 to Bob or Bob's secret S1 to Alice if they do not use their own transaction outputs for that atomic swap. In this case, neither Alice nor Bob can calculate the private keys corresponding to P AE and P BE .

[0090] The blockchain uses a public key / private key encryption system to sign transactions and prove the ownership of transaction outputs. This enables sending transactions to P AE and P BE simultaneously in several cryptocurrencies using the method of the above embodiment. For example, after establishing P AE and P BE in step 3 above, Alice moves funds in BCH and ETH to P BE , and Bob moves funds in BCH and DASH to P AE .

[0091] Once the atomic swap is executed, the private keys to P BE and P AE 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. Thus, the next transaction from Alice to Bob can be safely completed.

Table 3

[0092] It should be noted that these blockchains do not need to allow the same hash function in their lock scripts.

[0093] The above provides a general method for two parties to unlock a public key through a secret exchange using an atomic swap. This has applications beyond cryptocurrency exchange and is relevant to any system using a public / private key cryptography scheme similar to ECDSA. Other use cases include, but are not limited to, the following: 1. Providing access to a distributed hash table (DHT); 2. Encrypted computation; 3. Private email client; 4. Access to logistics data and exchange; 5. Swap of goods and services; 6. Private exchange of value; 7. Key hierarchy.

[0094] Decision to keep a common secret Where appropriate, security can be enhanced by using a secure method of exchanging information between two parties, such as the public / private key system described below.

[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 shares of the share. The common secret (CS) is a secret (S A,B,1,2 ), for example, they are generated and used to enable the secure exchange of secret values, keys, or shares thereof.

[0096] Hereafter, for convenience, Alice and Bob will be referred to as the first node (C) and the second node (S). The objective is to generate a common secret (CS) known to both nodes, but this common secret will not be transmitted via a communication channel. In this way, the possibility of its unauthorized discovery is eliminated.

[0097] The secure transmission technique relies on the CS (Cryptographic Key) being generated independently at each end of the transmission. Therefore, both nodes know the CS, but the CS does not need to travel through a potentially insecure communication channel. Once the CS is established at both ends, it can be used to generate a secure encryption key that both nodes can then use for communication.

[0098] Figure 2 shows a system 1 including a first node 3 that communicates with a second node 7 through a communication network 5. The first node 3 has an associated first processing unit 23, and the second node 5 has an associated second processing unit 27. The first and second nodes 3 and 7 may include electronic devices such as computers, telephones, tablet computers, mobile communication devices, and computer servers. 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 for a digital wallet provider.

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

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

[0101] To determine the common secret (CS) at both the first node 3 and the second node 7, nodes 3 and 7 execute the steps of respective methods 300 and 400 without communicating the secret keys through the communication network 5.

[0102] The method 300 executed by the first node 3 includes determining (330) the second secret key (V 1C ) of the first node based on at least the master secret key (V 2C ) and the generator value (GV) of the first node. 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 through the communication network 5, as will be described in more detail later. The method 300 also includes determining (370) the second public key (P 1S ) of the second node based on at least the master public key (P 2S ) and the generator value (GV) of the second node. The method 300 includes determining (380) the common secret (CS) based on the second secret key (V 2C ) of the first node and the second public key (P 2S ) of the second node.

[0103] The same common secret (CS) can also be determined at the second node 7 by the method 400. The method 400 includes determining (430) the second public key (P 1C ) of the first node based on the master public key (P 2C ) and the generator value (GV) of the first node. The method 400 further includes determining (470) the second secret key (V 1S ) of the second node based on the master secret key (V 2S ) and the generator value (GV) of the second node. The method 400 includes determining (480) the common secret (CS) based on the second secret key (V 2S ) of the second node and the second public key (P 2C ) of the first node.

[0104] The communication network 5 may include local area networks, wide area networks, cellular networks, wireless communication networks, the Internet, etc. These networks, on which data may be transmitted via communication media such as electric wires, optical fibers, or wirelessly, may be subject to eavesdropping by eavesdroppers 11, etc. Methods 300, 400 may allow both the first node 3 and the second node 7 to independently determine a common secret without transmitting the common secret through the communication network 5.

[0105] Thus, 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 the potentially insecure communication network 5. The common secret may then be used as a secret key (or as the basis for a secret key) for encrypted communication between the first node 3 and the second node 7 over the communication network 5.

[0106] Methods 300 and 400 may include additional steps. Method 300 involves, at the first node 3, the message (M) and the second secret key (V) of the first node. 2C Method 300 may also include generating a signed message (SM1) based on the first public key (P). Method 300 further includes sending the first signed message (SM1) to a second node 7 over a communication network (360). The second node 7 may then perform step 440 to receive the first signed message (SM1). Method 400 also includes generating a signed message (SM1) based on the second public key (P) of the first node. 2C The process includes step 450 validating the first signed message (SM2) using the master secret key (V), and step 460 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 claimed first node (where the first signed message was generated) is the first node 3. This is because only the first node 3 has the master secret key (V) of the first node. 1C ) can access, and therefore only the first node 3 has the first node's second secret key (V) to generate the first signed message (SM1). 2C This is based on the assumption that it is possible to determine that ). Similarly, it is understood that a second signed message (SM2) can be generated at the second node 7 and sent to the first node 3, thereby allowing the first node 3 to authenticate the second node 7 as in a peer-to-peer scenario.

[0107] Sharing a message (M) between a first node and a second node can be achieved in various ways. In one example, the message is generated at the first node 3 and then sent to the second node 7 via the communication network 5. Alternatively, the message may be generated at the second node 7 and then sent to the second node 7 via 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, the user may input the message through the user interface 15 and it may be received by the first and second nodes 3 and 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 and 7. In some examples, the message (M) may be public and therefore may be transmitted over an insecure network 5.

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

[0109] Advantageously, records that allow for the regeneration of a common secret (CS) can be maintained without the need for the records themselves to be stored confidentially or transmitted securely. This can be advantageous when a large number of transactions are executed on the first and second nodes 3 and 7, and it is not practical to store all messages (M) on the nodes themselves.

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

[0111] An asymmetric cryptographic pair contains associated secret and public keys, similar to those used in public-key cryptography. In this example, an asymmetric cryptographic pair is generated using elliptic curve cryptography (ECC) and the properties of elliptic curve operations.

[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 US5,600,725, US5,761,305, US5,889,865, US5,896,455, US5,933,504, US6,122,736, US6,141,420, US6,618,483, US6,704,870, US6,785,813, US6,078,667, and US6,792,530.

[0113] Methods 100 and 200 involve the first and second nodes agreeing on a common ECC system and using a base point (G). (Note: The base point could be called 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 to the first node 3, method 100 includes determining a common ECC system and base point (G) 110. This may include receiving a common ECC system and base point from a second node 7 or a third node 9. Alternatively, a user interface 15 may be attached to the first node 3, thereby allowing the user to selectively provide a 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 notice to the second node 7 via the communication network 5 indicating that it will use a common ECC system with a base point (G). The second node 7 may then resolve by sending a notice indicating an acknowledgment of using a common ECC system and base point (G) (210).

[0115] Method 100 involves the first node 3 obtaining the first node's master secret key (V 1C ) and the master public key of the first node (P 1C This also includes generating a first asymmetric cryptographic pair containing ) 120. This at least in part generates a first master secret key (V) based on a random integer within a specified acceptable range in a common ECC system. 1C This includes generating the master secret key (P) of the first node. 1C Formulas for ) and the base point (G): P 1C =V 1C ×G (Formula 1) Based on elliptic curve point multiplication according to the formula, the master public key of the first node (P 1C This includes determining the following:

[0116] Thus, the first asymmetric cryptographic pair includes: V 1C : The master secret key of the first node, which is kept secret by the first node. P 1C : The publicly known master public key of the first node.

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

[0118] Method 100 further transmits the master public key (P) of the first node via the communication network 5. 1C This includes sending the master public key (P) of the first node to the second node 7. The second node 7 then sends the master public key (P) of the first node to the second node 7. 1C When the first node receives the master public key (P 1C ) may be stored 230 in the 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 is the master secret key of the second node (V 1S ) and the master public key of the second node (P 1S This includes generating a second asymmetric cryptographic pair containing the master secret key (V) of the second node. 1S ) is also a random integer within the acceptable range. Next, the master public key of the second node (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 secret key of the second node, which is kept secret by the second node. P 1S : The publicly known master public key of the second node.

[0121] The second node 7 may store the second asymmetric cryptographic pair in the second data store 17. Method 200 further involves the first node 3 receiving the master public key (P) of the second node. 1S This includes sending ) 250. Next, the first node 3 sends the master public key (P) of the second node. 1S The system may receive (140) and store (150).

[0122] In some alternatives, it is understood that each public master key may be received and stored in a third datastore 19 associated with a third node 9 (for example, a trusted third party). This could include a third party acting as a public directory, such as a certificate authority. Thus, in some examples, the master public key of the first node (P 1C ) can only be requested and received by the second node 7 when a common secret (CS) is required (and vice versa).

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

[0124] Next, an example of determining a common secret (CS) is described with reference to Figure 5. The common secret (CS) may be used for a specific 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). Thus, the common secret (CS) may change between different sessions, times, transactions, etc.

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

[0126] In this example, the method 300 performed by the first node 3 includes generating a message (M) 310. The message (M) may be random, pseudo-random, 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 selective values ​​(e.g., Unix time) that may be useful in some applications.

[0129] Method 300 includes sending a message (M) to a second node 7 315 ​​over a communication network 3. Since the message (M) does not contain any information about a secret key, the message (M) may be sent over an insecure network.

[0130] Method 300 further includes step 320 of determining a Generator Value (GV) based on a message (M). In this example, this includes determining the cryptographic hash of the message. An example of a cryptographic hash algorithm is 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 within 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] Next, method 300 uses the master secret key (V) of the second node. 1C Based on the generator value (GV), the second secret key (V) of the first node 2C This includes step 330, which determines the master secret key (V) of the first node, according to the following formula. 1C This can be done by scalar addition of the generator value (GV) and the generator value (GV): V 2C =V 1C +GV (Equation 5)

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

[0134] Thus, the second public key (P) of the corresponding first node 2C ) is the master public key (P) of the first node. 1C Given knowledge of the second public key (P) of the first node, it can be derived. The second node 7 has the second public key (P) of the first node. 2C ) may have such knowledge to independently determine, which will be discussed in more detail below with respect to Method 400.

[0135] Method 300 further includes the message (M) and the determined second secret key (V) of the first node. 2C This involves generating a first signed message (SM1) based on 350. Generating a signed message involves digitally signing the message (M) by applying a digital signature algorithm. In one example, this involves signing the message with the second secret key (V) of the first node in the Elliptic Curve Digital Signature Algorithm (ECDSA). 2C This includes applying ) to obtain the 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) of the first node. 2C This can be verified using ). This verification of the first signed message (SM1) may also be used by the second node 7 to authenticate the first node 3, which is discussed in Method 400 below.

[0138] Next, the first node 3 receives the second public key (P) of the second node. 2S ) may be determined as 370. As discussed above, the second public key of the second node (P 2S ) is the master public key (P) of at least the second node. 1S ) and may be based on the generator value (GV). In this example, the public key is determined as the private key multiplied by the base point (G) and the elliptic curve point, so the second public key (P2S) of the second node can be expressed in a similar manner to Equation 6 as follows: 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) of the first node. 2C The same steps described above are used to derive equation 9.1 for ). It is understood that the first node 3 can determine the second public key of the second node 3 independently of the second node 7.

[0139] Next, the first node 3 uses the second secret key (V) of the first node that was determined. 2C ) and the second public key of the determined second node (P 2S Based on this, a common secret (CS) may be determined. The common secret (CS) may be determined by the first node 3 by the following formula: S=V 2C ×P 2S (Formula 11)

[0140] Method 400 to be executed at the second node 7 Here, we describe the corresponding method 400 performed on 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] Method 400 includes receiving a message (M) from the first node 3 through the communication network 5 410. This may include the message (M) sent by the first node 3 in step 315. The second node 7 then determines a Generator Value (GV) based on the message (M) 420. The step 420 in which the second node 7 determines the Generator Value (GV) is similar to the step 320 performed by the first node described above. In this example, the second node 7 performs this determination step 420 independently of the first node 3.

[0142] The next step is to obtain the master public key (P) of the first node. 1C Based on the first node's second public key (P 2C This includes the step of determining the second public key (P) of the first node. In this example, the public key is determined as the private key multiplied by the base point (G) and the elliptic curve point, so the second public key (P) of the first node is determined. 2C ) can be expressed in the same way as in Equation 9, as follows: 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] Method 400 may include a step performed by the second node 7 to verify that the claimed first node 3 is the first node 3. As discussed above, this includes receiving a first signed message (SM1) from the first node 3 440. The second node 7 then uses the second public key (P) of the first node determined in step 430. 2C The signature on the first signed message (SM1) may be validated using 450.

[0144] The verification of the digital signature may be performed according to the Elliptic Curve Digital Signature Algorithm (ECDSA) discussed above. Importantly, the second secret key (V) of the first node 2C The first signed message (SM1) signed using ) is V 2C and P 2C Since these form an encryption pair, the second public key (P) of the corresponding first node 2C These keys should only be properly verified when using the master secret key (V) of the first node, which was generated when the first node 3 was registered. 1C ) and the master public key of the first node (P 1C Since it is deterministic based on ), verifying the first signed message (SM1) can be used as a basis for authenticating that the claimed 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 the first node 3 (460) based on the result of validating (450) the first signed message.

[0145] The authentication described above may be suitable for scenarios where one of the two nodes is a trusted node, and only one of those 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 case, the server (second node 7) may need to authenticate the client's (first node 3) credentials in order to allow the client to access the server system. The server may not need to authenticate its own credentials to the client. However, in some scenarios, such as a peer-to-peer scenario, it may be desirable for both nodes to authenticate each other.

[0146] Method 400 further involves the second node 7 obtaining the master secret key (V) of the second node. 1S Based on the second secret key (V) of the second node, and the generated value (GV) 2S This may include determining the second secret key (V) of the second node, similar to step 330 performed by the first node 3. 2S ) is obtained according to the following formula: the master secret key of the second node (V 1S ) and the generator value (GV) can be based on scalar addition: V 2S =V 1S +GV (Equation 13.1) V 2S =V 1S +SHA-256(M) (Equation 13.2) Next, the second node 7, independently of the first node 3, retrieves the second secret key (V) of the second node. 2S ) and the second public key of the first node (P 2C Based on the following formula, the common secret (CS) may be determined: 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. Here, we present a mathematical proof that equations 11 and 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, we get: 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 the ECC algebra is commutative, equations 15 and 16 are equivalent. This is because: S=(V 2C ×V 2S ) × G = (V 2S ×V 2C )×G (Equation 17)

[0148] The Common Secret (CS) can now be used as a private key, or as the basis for a private key in a symmetric key algorithm for secure communication between the first node 3 and the second node 7. This communication may be used to transmit a portion of the private key, a representation of the private key, an identifier for the private key, or a mnemonic about 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 be performed.

[0149] The common secret (CS) is the elliptic curve point (x S ,y S It may also be in the form of ). This may be converted to a standard key format using standard 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. Alternatively, it may be converted to a 160-bit integer using RIPEMD160. This is for any application that requires a key of this length.

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

[0151] However, depending on the application, the common secret (CS) may be the master secret key (V) of the first node. 1C The common secret (CS) can be stored in a first datastore (X) associated with the first node, provided it is kept as secure as the first node.

[0152] The embodiments described above are illustrative, not limiting, of the invention, and it should be noted that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, reference numerals in parentheses should not be construed as limiting the claims. Words such as “includes” and “has” do not exclude the existence of elements or steps other than those enumerated in any claim or throughout the specification. In this specification, “includes” means “includes or consists of…”, and “has” means “includes or consists of…”. A singular reference to an element does not exclude a plural reference to such element, and vice versa. The invention can be implemented by hardware having several distinct elements and by a suitably programmed computer. In apparatus claims that enumerate several means, some of these means may be embodied by the same hardware item. The mere fact that certain measures are described in different dependent claims does not indicate that combinations of these measures cannot be advantageously utilized. < / b0>

Claims

1. A computer-implemented exchange method, the method being: (i) a device associated with the first user communicates a first veiled secret value from the first user to the second user; (ii) The step of receiving a second veiled secret value from the second user by a device associated with the first user; (iii) A step of constructing a first blockchain transaction including the first veiled secret and the second veiled secret, wherein the first blockchain transaction is configured to become unlockable for transferring control of the first resource when both the first secret known to the first user and the second secret known to the second user are provided to the first blockchain transaction, The first secret is revealed to the second user by the provision of the first secret and the second secret to the first blockchain transaction as a result of the second user communicating the second secret to the first user, thereby unlocking the first blockchain transaction, and the second secret is revealed to the first user by the provision of the first secret and the second secret to the second blockchain transaction as a result of the first user communicating the first secret to the second user, thereby unlocking the second blockchain transaction, the second blockchain transaction includes the first veiled secret and the second veiled secret, and is configured to become unlockable for transferring control of the second resource once both the first secret and the second secret are provided to the second blockchain transaction. method.

2. The method according to claim 1, wherein at least one of the first blockchain transaction and the second blockchain transaction is configured to be redeemable only when the respective first and second private keys are applied.

3. The method according to claim 2, further comprising the step of computing at least one of (a) a first derived public key based at least in part on a first public key of the first user and (b) a second derived public key 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 including the first private key and the second derived public key is part of a cryptographic key pair including the second private key.

4. The method according to claim 3, wherein the step of computing 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 further includes a combination of the first and second veiled secret values.

5. The method according to claim 4, wherein the combination of the first and second veiled secret values ​​includes at least one of the following: the concatenation of the first veiled secret value and the second veiled secret value, and the concatenation of at least one veiled secret value with a random or pseudo-random value.

6. The method according to any one of claims 1 to 5, further comprising the step of 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 expiration of a first time period 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 expiration of a second time period during which the second blockchain transaction is not redeemed.

7. The method according to any one of claims 1 to 6, wherein at least one of the first veiled secret and the second veiled secret includes a combination of at least one of the first secret and the second secret and a shared secret accessible by both the first user and the second user.

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

9. (iv) The step of generating at least one sequence of veiled secret values ​​beginning with at least one of the first secret value and the second secret value; (v) The step of performing the method according to any one of claims 1 to 8 using at least one of the first secret value and the second secret value; (vi) further comprising the step of 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, The method according to any one of claims 1 to 8.

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

Images