Cryptographic key storage and transfer based on a blockchain system in combination with a wallet management system

Abstract

The invention relates to computer-implemented methods and apparatuses and methods of controlling access to a digital wallet, providing a solution to controlling access to a resource (e.g. a digital wallet implemented using a blockchain). Use of the invention during setup of a wallet can enable subsequent operations to be processed in a secure manner over an unsecure channel. An example method comprises splitting a verification element into a plurality of shares; determining a common secret at a plurality of nodes in a network; and using the common secret to transfer shares of the verification element between the nodes. The shares can be split such that no share is sufficient to determine the verification element and the shares can be stored at separate locations. When a share is not available, location accessibility of the share can be retrieved. To securely transfer the shares, the common secret is generated at two different nodes independently and used to generate an encryption key which is used to encrypt at least one share of the verification element to be securely transferred.

Description

[0001] This application is a continuation-in-part of, and claims priority to, Chinese Patent Application No. 201780003338.4 (corresponding to PCT International Application No. PCT / IB2017 / 050829), filed on February 14, 2017, entitled "Secure Multi-Party Anti-Lost Storage and Encryption Key Transfer for Blockchain-Based Systems in Combination with a Wallet Management System."

[0002] Cross Reference to Related Applications

[0003] This application is a continuation of U.S. Application No. 16 / 111,022, filed August 23, 2018, entitled “SECURE MULTIPARTY LOSS RESISTANT STORAGE AND TRANSFER OF CRYPTOGRAPHIC KEYS FOR BLOCKCHAIN BASED SYSTEMS IN CONJUNCTION WITH A WALLET SYSTEMS,” which is a continuation of PCT Application No. PCT / IB2017 / 050829, filed February 14, 2017, entitled “SECURE MULTIPARTY LOSS RESISTANT STORAGE AND TRANSFER OF CRYPTOGRAPHIC KEYS FOR BLOCKCHAIN BASED SYSTEMS IN CONJUNCTION WITH A WALLET SYSTEMS,” which claims priority to U.K. Application No. 1603117.1, filed February 23, 2016, entitled “DETERMINING A COMMON SECRET FOR TWO BLOCKCHAIN NODES FOR THE SECURE EXCHANGE OF INFORMATION,” U.K. Application No. 1605026.2, filed March 24, 2016, entitled “SECURE MULTIPARTY LOSS RESISTANT STORAGE AND TRANSFER OF CRYPTOGRAPHIC KEYS FOR BLOCKCHAIN BASED SYSTEMS IN CONJUNCTION WITH A WALLET MANAGEMENT SYSTEM,” and U.K. Application No. 1619301.1, filed November 15, 2016, entitled “DETERMINING A COMMON SECRET FOR TWO BLOCKCHAIN NODES FOR THE SECURE EXCHANGE OF INFORMATION.”Priority of GB application No. 3. The aforementioned application is incorporated herein in its entirety by reference. TECHNICAL FIELD

[0004] The present invention relates generally to computer and data security, and more particularly to secure handling of highly sensitive data items such as encryption keys. The present invention provides an access control mechanism. The present invention is particularly suitable for, but not limited to, use with digital (software) wallets. This can include wallets for use in relation to cryptographic currencies such as Bitcoin. The present invention provides an advantageous access control mechanism. BACKGROUND

[0005] Cryptography relates to techniques for secure storage of sensitive data and communication of sensitive data between two or more nodes in a network. Nodes can include mobile communication devices, tablet computers, laptop computers, desktop computers, other forms of computing and communication devices, server devices in a network, client devices in a network, one or more nodes in a distributed network, and the like. Nodes can be associated with a natural person, a group of persons such as employees of a company, a system such as a banking system, or a distributed peer-to-peer ledger (i.e. a blockchain).

[0006] Two or more nodes can be linked by a communication network which is insecure and susceptible to eavesdropping or interception by an unauthorised third party. Accordingly, messages sent between nodes are often sent in encrypted form. Upon receipt, the intended recipient decrypts the message using a corresponding decryption key or other decryption method. The security of such communications can therefore depend on preventing the third party from determining the corresponding decryption key.

[0007] One known encryption method involves the use of a symmetric key algorithm. The key is symmetric in the sense that the same symmetric key is used to encrypt a plaintext message and to decrypt a ciphertext message. However, the symmetric key must be transmitted to the two nodes in a secure manner, preventing unauthorised access to the symmetric key. This can involve, for example, physically passing the symmetric key to the nodes (authorised) such that the symmetric key is never transmitted over an insecure communication network. However, physical passing is not always a practical option. Accordingly, a problem with such cryptographic systems is that the symmetric key (which can be based on a public secret) is established between nodes over an insecure electronic network (such as the internet). This step of providing the symmetric key (public secret) can therefore be a catastrophic vulnerability. Because symmetric key algorithms and protocols are simple and widely used, the two nodes need to determine the symmetric key based on the public secret in an insecure network.

[0008] The use of asymmetric keys, also known as public key cryptography, alleviates this problem to some extent. When a private key is kept secret, its corresponding public key can be made publicly available. Interception of the private key on the network is not catastrophic. Existing protocols include the Diffie-Hellman Key Exchange and the Three Pass Protocol.

[0009] However, the storage of private keys raises a number of security concerns. Consider, for example, a digital wallet such as a Bitcoin wallet. A digital wallet comprises software that enables a user to connect with other nodes in order to perform transactions with their electronic assets, such as using Bitcoin funds to purchase goods and services. Public key cryptography is often used to protect important information required for such connections and transactions. The private key is stored either by the wallet installed on the user's device ("client side") or by a wallet service provider ("server side"). However, if the private key is stored only at the client side, the private key can be lost via theft, loss or damage to the user's hardware (e.g. computer, mobile phone, etc.). Similarly, if the user dies or becomes incapacitated, knowledge of or access to the private key can be lost, and thus the funds associated with the wallet become inaccessible. While server side storage of the private key can overcome these problems, the user must be willing to trust the service provider to keep their private key secure. Security breaches at the server side are a real and significant risk. SUMMARY

[0010] Accordingly, there is a need to provide a solution that enables secure handling of secrets. Such secrets can be cryptographic keys and / or something that provides access to the keys. Such improved solutions have now been devised. According to the present invention, there is provided an improved solution as defined in the appended claims.

[0011] The present invention can provide a computer implemented method. The computer implemented method can enable controlling access to a resource. The method can be referred to as a verification or authentication method. The method can be referred to as a cryptographic key management solution. The resource can be any type of physical or electronic resource. In one embodiment, the resource is a digital wallet or other resource related to a form of currency. The resource can be a Bitcoin wallet or other wallet for managing a resource of a cryptocurrency. The present invention can provide a method of controlling access to a digital wallet (and corresponding system).

[0012] The present invention can be used during the setup, registration or creation of a digital wallet via an unsecured communication channel (e.g. the Internet), enabling subsequent wallet related operations, such as transactions to be processed, communicated and / or created, to be performed in a secure manner.

[0013] One or more embodiments of the invention can comprise the step of deriving an encryption key from an existing encryption key pair. This can comprise the steps of:

[0014] determining a first entity secondary private key based on at least a first entity primary private key and a generator value;

[0015] determining a second entity secondary private key based on at least a second entity primary private key and the generator value;

[0016] determining a common secret (CS) at the first entity based on the first entity secondary private key and a second entity secondary public key, and determining a common secret (CS) at the second entity based on the second entity secondary private key and a first entity secondary public key; and

[0017] wherein:

[0018] the first entity secondary public key and the second entity secondary public key are each based on at least the first / second entity primary key and the generator value.

[0019] Additionally or alternatively, the invention can comprise a method of controlling access to a digital wallet, the method comprising the steps of:

[0020] determining a first entity secondary private key based on at least a first entity primary private key and a generator value;

[0021] determining a second entity secondary private key based on at least a second entity primary private key and the generator value;

[0022] determining a common secret (CS) at the first entity based on the first entity secondary private key and a second entity secondary public key, and determining a common secret (CS) at the second entity based on the second entity secondary private key and a first entity secondary public key; and

[0023] wherein:

[0024] the first entity secondary public key and the second entity secondary public key are each based on at least the first / second entity primary key and the generator value.

[0025] Additionally or alternatively, the method can comprise the steps of:

[0026] splitting a verification element into a plurality of shares;

[0027] determining a common secret at or across two or more nodes in a network;

[0028] transferring at least one share of the authentication element from one node in the network to at least one other node using the common secret.

[0029] The authentication element can be an encryption key. The authentication element can be a private key in an asymmetric cryptographic pair. Additionally or alternatively, the authentication element can represent an encryption key, or some item that can be used to access, compute, derive or retrieve an encryption key. The authentication element can be some secret or value that can be used in a verification process, such as a mnemonic or a seed.

[0030] Accordingly, one aspect of the invention can relate to splitting a secret, such as a private key, into a (unique) plurality of shares. The authentication element can be split into a plurality of shares, such that the authentication element can be recovered or regenerated from two or more of the plurality of shares. Shamir's Secret Sharing Scheme can be used to split the authentication element into a plurality of shares.

[0031] The shares can be split such that any share does not itself have a value, meaning that a share cannot be used to achieve the (original, unsplit) authentication element. The splitting can be performed such that the authentication element can only be recovered after a predetermined number of shares are combined. In one embodiment, any two shares can be sufficient to recover the authentication element.

[0032] Another aspect of the invention can relate to the secure handling or storage of individual shares. The shares can be sent to and stored by different parties. Some or all of these parties can be nodes on the network. In one embodiment, the method can comprise the step of storing at least three shares of the authentication element at different locations from each other.

[0033] At least one of the shares can be stored in or on a backup or "secure storage" facility. The backup or "secure storage" facility can be separate, independent and / or distinct from any other location in which a share is stored. This can provide an important advantage, as this way enables the recovery of the authentication element in the event that one of the other shares becomes unavailable. In this scenario, the share can be obtained from the secure storage facility.

[0034] A verification process can be performed using the shares prior to the recovery of the authentication element. The verification process can comprise verifying a predetermined or specified individual identity and / or computing resource.

[0035] Another aspect of the invention may relate to the secure distribution of one or more of the said shares. The method may include the step of generating an encryption key using a public secret, wherein the encryption key is used to encrypt at least one share of the verification element or a message including said at least one share.

[0036] A public secret can be determined at at least two independent nodes. Therefore, each node can determine or generate its own secret without inputting it from or communicating with other nodes or parties. This means the public secret may not need to be transmitted over the communication channel. This enhances security because the public secret cannot be intercepted by unauthorized parties. The public secret can be shared only by the at least two nodes (i.e., shared by the at least two nodes). The public secret can then be used to generate an encryption key, which can be used for the secure transmission of shares. The encryption key can also be used to transmit other data.

[0037] The method may include the step of determining a public secret (CS) shared by the first node (C) and the second node (S) at a first node (C), wherein the first node (C) and the second node (S) have a first node master private key (V 1C ) and the first node master public key (P 1C The first asymmetric cryptographic pair is associated with the second node (S), and the second node (S) is associated with the second node master private key (V). 1S ) and the second node master public key (P 1S The method is associated with a second asymmetric cipher pair, wherein the method includes:

[0038] -At least based on the first node's master private key (V 1C The first node's secondary private key (V) is determined by the generator value (GV) and the generator value (GV). 2C );

[0039] -At least based on the second node's master public key (P 1S The second node secondary public key (P) is determined by the generator value (GV) and the generator value (GV). 2S );and

[0040] -Based on the first node's secondary private key (V) 2C ) and the second node secondary public key (P 2S And to determine the public secret (CS),

[0041] Among them, based on the first node secondary public key (P) 2C ) and the second node secondary private key (V 2S The second node (S) has the same public secret (CS), wherein: the first node's secondary public key (P) 2Cbased on at least the first node master public key (P 1C ) and the generator value (GV); and the second node secondary private key (V 2S ) is based on at least the second node master private key (V 1S ) and the generator value (GV).

[0042] The generator value (GV) can be based on a message (M). The method can further comprise generating a first signed message (SM1) based on the message (M) and the first node secondary private key (V 2C ); and sending the first signed message (SM1) to the second node (S) via the communication network, wherein the first signed message (SM1) can be verified using a first node secondary public key (P 2C ), thereby authenticating the first node (C).

[0043] The method can further comprise receiving a second signed message (SM2) from the second node (S) via the communication network; verifying the second signed message (SM2) using the second node secondary public key (P 2S ); and based on the result of verifying the second signed message (SM2), authenticating the second node (S), wherein the second signed message (SM2) is generated based on the message (M) or a second message (M2) and the second node secondary private key (V 2S ).

[0044] The method can further comprise generating a message (M); and sending the message (M) to the second node (S) via a communication network. Alternatively, the method can comprise receiving the message (M) from the second node (S) via the communication network. In yet another alternative, the method can comprise receiving the message (M) from another node via the communication network. In yet another alternative, the method can comprise receiving the message (M) from a data store and / or an input interface associated with the first node (C).

[0045] The first node master public key (P 1C ), the second node master public key (P 1S ) can be based on elliptic curve point multiplication of a first node master private key (V 1C ) and a second node master private key (V 1S ) with a generator (G), respectively.

[0046] The method can further comprise the steps of receiving the second node master public key (P 1S ) via the communication network; and sending the second node master public key (P 1S) stored at a data storage device associated with the first node (C).

[0047] The method can further comprise the steps of generating, at the first node (C), a first node master private key (V 1C ) and a first node master public key (P 1C ); sending the first node master public key (P 1C ) to the second node (S) and / or other nodes via the communications network; and storing the first node master private key (V 1C ) in a first data storage device associated with the first node (C).

[0048] The method can further comprise sending a notification to the second node via the communications network, the notification indicating that the method for determining a common secret (CS) utilizes a common Elliptic Curve Cryptography (ECC) system and a base point (G). The steps of generating the first node master private key (V 1C ) and the first node master public key (P 1C ) can comprise generating the first node master private key (V 1C ) based on a random integer within a permissible range specified in the common ECC system; and determining the first node master public key (P 1C ) based on an elliptic curve point multiplication of the first node master private key (V 1C ) with the base point (G) according to the following equation:

[0049] P 1C = V 1C x G

[0050] The method can further comprise determining a generator value (GV) based on a hash of the message (M), wherein the step of determining the first node secondary private key (V 2C ) is based on a scalar addition of the first node master private key (V 1C ) with the generator value (GV) according to the following equation:

[0051] V 2C = V 1C + GV

[0052] The step of determining the second node secondary public key (P 2S ) can be based on an elliptic curve point addition of the second node master public key (P 1S ) to an elliptic curve point multiplication of the generator value (GV) with the base point (G) according to the following equation:

[0053] P 2S = P 1S + GV x G.

[0054] The generator value (GV) can be determined based on a hash of a previous generator value (GV).

[0055] The first and second asymmetric cryptographic pairs can be based on a function of a previous first and second asymmetric cryptographic pair respectively.

[0056] In other words, the present application can provide a method comprising the steps of:

[0057] Splitting the verification element into a plurality of shares;

[0058] Generating a resulting (or second) private encryption key at the first node based on a first master asymmetric key pair;

[0059] Using the resulting private key to encrypt and / or securely transport at least one share of the verification element.

[0060] The method can further comprise the step of generating the same resulting private key at a second node, the resulting private key being generated independently of the first node and based on a second master asymmetric key pair.

[0061] The resulting private key can be part of an asymmetric key pair comprising a private key and a public key. The first and / or second node can use Elliptic Curve Cryptography (ECC) to generate the private key (and its corresponding public key).

[0062] The method can comprise the steps of:

[0063] • agreeing a standard ECC system between the first and second nodes using a base point (G); and / or

[0064] • generating a public / private key pair at the first and / or second node using the agreed standard ECC system and publishing the public key; this can mean making the public key publicly available; and / or

[0065] • registering the first node's master public key (P MC ) at the second node or another location; and / or registering the second node's master public key (P MC ) at the first node or another location; and / or

[0066] • sending a message (M) from the first node to the second node, and / or vice versa, and creating a hash of the message; the resulting private key can be used to sign the message; this step can represent 1) establishing a shared secret between the nodes and 2) initiating a secure communication session between the nodes, the only transmission required. The first or second node can use the received message M to generate its own resulting (secondary) public / private key pair. This can allow the node to calculate the other node's resulting public key; and / or

[0067] • receiving the message and independently calculating a hash of the message M (e.g. SHA-256(M)); and / or

[0068] • calculating a public key (P MC ) that can be derived from the master private key (P 2C ); and / or

[0069] • confirming a signature (Sig-V 2C ) against the calculated P 2C

[0070] The resulting private key can be deterministically derived from the master public key of the first or second node.

[0071] The present application can also comprise a computer implemented system arranged and configured to implement any embodiment of the method described above. The system can comprise or utilise a blockchain network or platform. Additionally or alternatively, the system can comprise a digital wallet provider or management system.

[0072] Any feature described above in relation to one aspect or embodiment of the present application can also be used in relation to any other aspect or embodiment. For example, and without limitation, features described in relation to the method can be applicable to the system, and vice versa.

[0073] These and other aspects of the present application will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF DRAWINGS

[0074] Embodiments of the present application will now be described, by way of example only, with reference to the accompanying drawings in which:

[0075] Figure 1 is a schematic diagram of an example system to determine a common secret for a first node and a second node, which can be used for secure transmission of highly sensitive information such as shares of a private key, in accordance with the present application;

[0076] Figure 2 ​is a flowchart of a computer-implemented method for determining a common secret, according to the present invention, which can be used for secure transmission of highly sensitive information such as shares of a private key;

[0077] Figure 3 is a flowchart of a computer-implemented method for registering a first and a second node;

[0078] Figure 4 is another flowchart of a computer-implemented method for determining a common secret, according to the present invention, which can be used for secure transmission of highly sensitive information such as shares of a private key;

[0079] Figure 5 is a flowchart of a computer-implemented method for secure communication between a first node and a second node. DETAILED DESCRIPTION

[0080] As explained above, there is a need to enhance the storage and / or exchange of secrets such as encryption keys or secrets that can be used to generate keys. The secrets can be seeds of wallet mnemonics or other security-related items. The present invention provides such a solution. The embodiments described below are for illustrative purposes and the embodiments utilize the field of digital wallets implemented on a blockchain. However, the present invention is not limited to such implementations and the present invention can be implemented for any computer-implemented network or system.

[0081] As mentioned above, public key cryptography is often used for digital wallets. If the end user, which we can call a "client" or simply "user", is responsible for storing their private key, then a problem can arise when the user or their hardware becomes unavailable: this renders the private key and thus the wallet funds inaccessible. However, storing the key at the end of the wallet provider, which we call "server side", requires a certain degree of trust in the provider and its security mechanisms. Therefore, there is a need to store the private key such that it is not accessible by unauthorized parties, but the private key can also be reproduced if necessary. The term "user" can be a human user or a computer-implemented resource.

[0082] A known encryption algorithm, known as the "Shamir Secret Sharing Scheme" (4S), teaches splitting a secret into unique parts or shares, which are then distributed to different parties. These shares can be used thereafter to reconstruct the secret. Each individual share has no value or use by itself until it is combined with one or more other shares. The number of shares needed to reconstruct the secret can vary depending on the situation. In some cases, all shares can be needed, while in other cases, only a sufficient number of shares is needed. This is known as a threshold scheme, where any k shares are sufficient to reconstruct the original secret.

[0083] In this illustrative embodiment, a secret, such as a private key or mnemonic seed, is split into several parts using 4S. Then, the key or mnemonic seed is also regenerated from a number of parts using 4S. The use of mnemonics in conjunction with digital wallets is known. Mnemonics are human-friendly codes or word clusters that can be converted into binary seeds for generating wallets or data.

[0084] In this document, the following terms are used.

[0085] • "secret" (S) is a secret (e.g., a number or value) that needs to be securely shared between parties.

[0086] • "share" is a piece of a secret. A secret is divided into multiple pieces, and each piece is called a share. A share is computed from a given secret. To recover the secret, an individual must obtain a number of shares.

[0087] • "threshold" (k) is the minimum number of shares that an individual needs to regenerate or recover the secret. The secret can only be regenerated if you have >= k shares.

[0088] • "prime" (p) is a random prime number.

[0089] Broadly speaking, the illustrative embodiments can include a method as follows. In this example, we use a "2-of-3" scheme (i.e., k = 2):

[0090] • A user registers with a wallet provider to generate and set up a new wallet associated with the user. In this example, the wallet is a Bitcoin wallet using a blockchain

[0091] • A public-private key pair is generated and associated with the user's wallet;

[0092] • The private key is split into multiple shares using 4S

[0093] • One share of the private key is sent to the user via secure transmission

[0094] • Another share of the private key is retained by the service provider and stored on a server

[0095] • another share is sent via secure transmission to a remote location for secure storage. The term "remote" does not imply any particular geographic distance or location. Instead, the use of "remote" in this context means that the share is held at (or on) a secure storage facility or resource that is independent of the wallet provider or the user (preferably both) in some sense. "Independent" can include physical independence, logical independence, financial independence, political independence, and / or organizational independence. For example, the secure storage can be outsourced to a commercial entity that provides a fee-based secure storage service; or the secure storage can be held by a user's agent or some other chosen (and trusted) party that is responsible for storing the share and providing it upon request when needed;

[0096] • the wallet provider can destroy any or all copies of the complete private key, since they are no longer needed. When a subsequent user authorization requires the private key (e.g., because the user now wishes to make a transaction), the key can be reconstructed from the user's share and the wallet provider's share, and the user provides the key to the wallet provider when needed.

[0097] The advantage of this is that even if the wallet provider's security is compromised, an unauthorized party cannot obtain the user's private key, since the user's private key is not stored anywhere on the wallet provider's system, and the wallet provider's system alone does not include enough shares to allow reconstruction of the private key. This advantage also applies to the case where the customer's security is compromised.

[0098] Another advantage is that by storing a share at a secure storage location, the private key can be reconstructed by retrieving the share from the secure storage and combining it with the wallet provider's share. Thus, if the user dies or becomes incapacitated, or if the user's hardware (and thus the share) is lost, damaged, or stolen, the funds in the wallet can still be accessed. In this case, the user's identity will be verified. In some cases, the identity of a verified trusted party (e.g., the executor or agent of the user's estate) will be verified. This is accomplished, for example, by providing proof of identification such as a death certificate, passport, legal document, or other form of authentication. Upon verification of the authorized identity, the secret share is retrieved from the secure storage. Thus, the secure storage serves as a type of backup facility that can be used in special or predetermined circumstances.

[0099] Thus, the present invention provides a favorable combination of enhanced system / data security with convenience. The present invention provides a simple, effective, and secure solution for access control.

[0100] It should be noted that in the above example, the private key is generated by the wallet service provider and the portions are sent to the user and the secure storage resource. However, in other embodiments, this can not be the case. It is also important to note that the transmission of the portions between the parties, which can be referred to as "nodes," must be performed in a secure manner, as unauthorized interception of the multiple shares can enable an interceptor to reconstruct the secret (e.g., the mnemonic or key). This problem of secure exchange is also addressed by the present invention, as described below.

[0101] More detailed aspects of the present invention are now described for purposes of illustration. It should be noted that the Shamir secret sharing scheme is a known technique in the art, and one of skill in the art will appreciate, understand, and be able to use the Shamir secret sharing scheme. Thus, the following is provided for purposes of completeness only.

[0102] Splitting a secret into shares

[0103] Given a secret S, a number of participants n, a threshold number k, and a prime number p, we construct the following polynomial with constant term S:

[0104] y = f(x) of degree k - 1 (modulo our prime p)

[0105] Next, we choose n unique random integers between 1 and p - 1 (inclusive), and evaluate the polynomial at those n points. Each of the n participants is given a (x, y) pair. This can be accomplished by the following steps:

[0106] 1. Convert to integer

[0107] For the 4S algorithm, the secret needs to be an integer. Thus, if the secret is in some other format (e.g., a string, a hexadecimal number, etc.), the secret must first be converted to an integer. If the secret is already an integer, this step can be omitted. For this example, assume S = 1234.

[0108] 2. Decide on number of shares (n) and threshold (k)

[0109] It should be noted that k portions will be needed to regenerate the secret. Thus, S and k are chosen so that when the secret is recovered, k portions are always available. For this example, assume n = 6, k = 3.

[0110] 3. Create polynomial

[0111] We need to create a polynomial of the form y = f(x) mod p

[0112] i. Determine the constant term and the polynomial degree

[0113] f(x) = a0 + a1x + a2x 2 +a3x 3 +…+a k-1 x k-1

[0114] - constant term a0 = S

[0115] - polynomial degree = k - 1

[0116] So, for k = 3 and S = 1234, we need to build a polynomial of degree 2 with a0 = 1234

[0117] f(x) = 1234 + a1x + a2x 2

[0118] ii. Determine coefficients

[0119] Choose k - 1 random numbers (using a random (or pseudo-random) number generator) such that:

[0120] 0 < a n < S

[0121] Let a1 = 166; a2 = 94

[0122] So, f(x) = 1234 + 166x + 94x 2

[0123] iii. Choose a random prime number

[0124] Choose a random prime number (p) such that:

[0125] p > max(S, n)

[0126] Let p = 1613

[0127] iv. Final polynomial

[0128] y = f(x) mod p

[0129] y = (1234 + 166x + 94x 2 ) mod 1613

[0130] Creating a share

[0131] To split the secret into n shares, we need to use the following polynomial to construct n points (shares):

[0132] y = (1234 + 166x + 94x 2 ) mod 1613

[0133] Since for this example n = 6, we will have 6 points. Note that we start at x = 1 instead of x = 0.

[0134] For x = 1 to 6, the 6 points are as follows:

[0135] (1, 1494); (2, 329); (3, 965); (4, 176); (5, 1188); (6, 775)

[0136] From these n (6) points, any k (3) points can be used to regenerate the secret key.

[0137] Reconstructing a secret from a given number of shares

[0138] i. Get the secret integer

[0139] To reconstruct the secret, we need the following information:

[0140] n = 6, k = 3, p = 1613,

[0141] k shares:

[0142] (x0, y0) = (1, 1494); (x1, y1) = (2, 329); (x2, y2) = (3, 965)

[0143] Once we have the above information, we can use techniques known in the art and readily understood by those skilled in the art, such as Lagrange Interpolation. In using this technique, we can reconstruct the entire polynomial. The coefficients can be calculated according to the following formula:

[0144] a i (x) = [∑ k-1 i＝0 y i Π 0<＝j<＝k-1,j≠i (x-x j ) / (x i -x j )] mod p

[0145] But since S = a0, we only need to find a0= a0(0)

[0146]

[0147] where x i -x j ≠ 0

[0148] Those skilled in the art will appreciate that in the above, the exponent -1 denotes taking the multiplicative inverse. Most programming languages include built-in data packages to perform mathematical operations such as the multiplicative inverse.

[0149] ii. Converting an integer to the desired format

[0150] If step 1 is performed to convert a particular format to an integer, then we follow the reverse procedure to convert the integer back to the desired format.

[0151] Secure transmission of shares

[0152] As mentioned above, it is important that the shares of the secret are transmitted to the respective recipients in a secure manner so as to prevent an unauthorized party from being able to reconstruct the secret. In a preferred embodiment, secure transmission can be achieved as described below.

[0153] A common secret (CS) can be established between the two parties and then used to generate a secure encryption key for transmitting one or more of the shares. This common secret (CS) is not to be confused with the secret (S) mentioned above. The common secret (CS) is generated and used to enable secure exchange of the secret (S), e.g. a key or share thereof.

[0154] The two parties can be two of a wallet service provider, a user, a secure storage resource or other legitimate parties. Hereinafter, for convenience, the two parties will be referred to as a first node (C), a second node (S). The aim is to generate a common secret (CS) known to both nodes without sending the common secret over a communication channel, thus eliminating the possibility of its unauthorized discovery. Secret splitting plus secure storage technology and secure transmission technology such as described below provide a secure key management solution.

[0155] The secure transmission technology of the present invention involves generating the CS at each end of the transmission in an independent manner, such that when both nodes know the CS, the CS does not need to be moved over a potentially insecure communication channel. Once the CS has been established at both ends, the CS can be used to generate a secure encryption key that both nodes can use thereafter for communication. This is particularly advantageous during the wallet registration process for transmitting a split private key from one party to the other.

[0156] Figure 1A system 1 is shown which includes a first node 3 in communication with a second node 7 via a communication network 5. The first node 3 has an associated first processing device 23 and the second node 7 has an associated second processing device 27. The first node 3 and the second node 7 can comprise electronic devices such as computers, telephones, tablet computers, mobile communication devices, computer servers and the like. In one example, the first node 3 can be a client (user) device and the second node 7 can be a server. The server can be a server of a digital wallet provider.

[0157] The first node 3 is associated with a first asymmetric cryptographic pair having a first node master secret key (V1C) and a first node master public key (P1C). The second node (7) is associated with a second asymmetric cryptographic pair having a second node master secret key (V 1S ) and a second node master public key (P 1S ). In other words, the first and second nodes each possess a respective public-secret key pair.

[0158] The first asymmetric cryptographic pair for the first node 3 and the second asymmetric cryptographic pair for the second node 7 can be generated during a registration process (e.g. wallet registration) respectively. The public keys for each node can be publicly shared (e.g. via the communication network 5).

[0159] To determine a common secret (CS) at the first node 3 and the second node 7, the nodes 3, 7 perform steps of methods 300, 400 respectively without communicating secret keys via the communication network 5.

[0160] The method 300 performed by the first node 3 includes determining a first node secondary secret key (V2C) 330 based at least on the first node master secret key (V 1C ) and a generator value (GV). The generator value can be based on a message (M) shared between the first node and the second node, which can include sharing the message via the communication network 5, as described in further detail below. The method 300 also includes determining a second node secondary public key (P 1S ) based at least on the second node master public key (P 2S ) and the generator value (GV). The method 300 includes determining a common secret (CS) 380 based on the first node secondary secret key (V 2C ) and the second node secondary public key (P 2S ).

[0161] Importantly, the same common secret (CS) can also be determined at the second node 7 by the method 400. The method 400 includes determining a first node secondary public key (P 1C ) based on the first node master public key (P 2C)430. The method 400 further comprises determining a second node secondary private key (V 1S ) based on the second node primary private key (V 2S ) and a generator value (GV) 430. The method 400 comprises determining a second node secondary public key (P 2S ) based on the second node secondary private key (V 2C ) and the first node secondary public key (P

[0162] The communication network 5 can comprise a local area network, a wide area network, a cellular network, a radio communication network, the Internet, etc. These networks, in which data can be transmitted via a communication medium, e.g. an electrical wire, an optical fibre, or wirelessly, can be susceptible to eavesdropping, e.g. by an eavesdropper 11. The methods 300, 400 can allow the first node 3 and the second node 7 to independently determine a common secret without transmitting the common secret via the potentially insecure communication network 5.

[0163] Thus, one advantage is that the common secret (CS) can be securely and independently determined by each node without having to transmit the private keys via the potentially insecure communication network 5. In turn, the common secret can be used as a secret key (or as a basis for a secret key) for encrypted communication between the first node 3 and the second node 7 via the communication network 5.

[0164] The methods 300, 400 can comprise additional steps. The method 300 can comprise generating a signed message (SM1) at the first node 3 based on the message (M) and the first node secondary private key (V 2C ). The method 300 further comprises sending the first signed message (SM1) to the second node 7 via the communication network 360. In turn, the second node 7 can perform the step of receiving the first signed message (SM1) 440. The method 400 also comprises the steps of verifying the first signed message (SM2) 450 using the first node secondary public key (P 2C ) and authenticating the first node 3 460 based on the result of verifying the first signed message (SM1). Advantageously, this allows the second node 7 to authenticate that the purported first node (which generated the first signed message) is the first node 3. This is based on the assumption that only the first node 3 has access to the first node primary private key (V1C) and, therefore, only the first node 3 can determine the first node secondary private key (V 2C ) to generate the first signed message (SM1). It will be appreciated that similarly, a second signed message (SM2) can be generated at the second node 7 and sent to the first node 3 so that the first node 3 can authenticate the second node 7 in, for example, a point-to-point scenario.

[0165] The sharing of messages (M) between the first and second nodes can be achieved in a variety of ways. In one example, a message can be generated at the first node 3 which is then sent to the second node 7 via the communications network 5. Alternatively, a message can be generated at the second node 7 and then sent to the second node 7 via the communications network 5. In yet another example, a message can be generated at the third node 9 and sent to the first node 3 and the second node 7. In yet another alternative, a user can enter a message via the user interface 15 to be received by the first node 3 and the second node 7. In yet another example, a message (M) can be retrieved from the data store 19 and sent to the first node 3 and the second node 7. In some examples, the message (M) can be public and therefore can be transmitted via the unsecure network 5.

[0166] In other examples, one or more messages (M) can be stored in the data stores 13, 17, 19, where the messages can be associated with a certain entity, such as a digital wallet, or a communication session established between the first node 3 and the second node 7. Thus, the messages (M) can be retrieved and used to re-establish the common secret (CS) associated with the wallet or session at the first node 3 and the second node 7 respectively.

[0167] Advantageously, a record can be kept which allows the common secret (CS) to be re-established without the record itself needing to be stored privately or transmitted securely. This can be advantageous in situations where numerous transactions are performed at the first node 3 and the second node 7 and it is impractical to store all messages (M) individually at the nodes themselves.

[0168] Registration method 100, 200

[0169] Reference will be made to Figure 3 Examples of the registration methods 100, 200 are described, where the method 100 is performed by the first node 3 and the method 200 is performed by the second node 7. This includes establishing first and second asymmetric cryptographic pairs for the first node 3 and the second node 7 respectively.

[0170] The asymmetric cryptographic pairs include associated private and public keys, such as a private key and a public key for public key encryption. In this example, the asymmetric cryptographic pairs are generated using elliptic curve cryptography (ECC) and properties of elliptic curve operations.

[0171] The ECC standard can comprise a known standard such as that described by the High Assurance 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, US 6,792,530.

[0172] In the methods 100, 200, this comprises the first and second nodes agreeing on a common ECC system and using a base point (G) 110, 210. (Note that 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 can be based on secp256K1, which is the ECC system used by Bitcoin. The base point (G) can be selected, randomly generated or assigned.

[0173] Turning now to the first node 3, the method 100 comprises selecting a common ECC system and a base point (G) 110. This can comprise receiving the common ECC system and base point from the second node 7 or the third node 9. Alternatively, a user interface 15 can be associated with the first node 3, whereby a user can 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) can be randomly selected by the first node 3. The first node 3 can send a notification to the second node 7 via the communications network 5 indicating that the common ECC system and base point (G) are to be used. In turn, the second node 7 can arrange 210 by sending a notification indicating that the common ECC system and base point (G) are to be used.

[0174] The method 100 further comprises the first node 3 generating a first asymmetric cryptographic pair 120 comprising a first node master private key (V 1C ) and a first node master public key (P 1C ). This comprises generating the first master private key (V 1C ) based at least in part on a random integer within an allowable range specified in the common ECC system. This further comprises determining the first node master public key (P 1C ) based on an elliptic curve point multiplication of the first node master private key (V 1C ) with the base point (G) according to the following equation:

[0175] P 1C = V 1C x G (Equation 1)

[0176] Therefore, the first asymmetric cipher pair includes:

[0177] V 1C The first node master secret key is kept confidential through the first node.

[0178] P 1C The first node's master public key becomes publicly known.

[0179] First node 3 can transmit the first node master private key (V) 1C ) and the first node master public key (P 1C The master private key (V) of the first node is stored in the first data storage device 13 associated with the first node 3. For security, the master private key (V) of the first node can be stored in the first data storage device 13 associated with the first node 3. 1C The key is stored in the secure portion of the first data storage device 13, thereby ensuring that the key remains private.

[0180] Method 100 further includes transmitting the first node's master public key (P) via communication network 5. 1C The public key (P) is sent to the second node 7,130. Upon receiving the primary public key (P) from the first node... 1C After 220, the second node 7 can then transmit the first node's master public key (P) 1C It is stored in the second data storage device 17 associated with the second node 7 230.

[0181] Similar to the first node 3, the method 200 of the second node 7 includes generating a second asymmetric cryptographic pair 240, the second asymmetric cryptographic pair including the second node master private key (V 1S ) and the second node master public key (P 1S Second node master private key (V) 1S (P) is still a random integer within the allowed range. Then, the second node master public key (P) is determined using the following formula. 1S ):

[0182] P 1S =V 1S x G (Equation 2)

[0183] Therefore, the second asymmetric cipher pair includes:

[0184] V 1S The second node master secret key is kept confidential through the second node.

[0185] P 1S The public key of the second node becomes publicly known.

[0186] The second node 7 can store the second asymmetric cryptographic pair in the second data storage device 17. Method 200 further includes storing the second node's master public key (P...1S ) to the first node 3, 250. In turn, the first node 3 can receive the second node master common key (P 1S ) 140 and store the second node master common key (P 1S ) 150.

[0187] It will be appreciated that in some alternatives, respective common master keys can be received and stored at a third data store 19 associated with the third node 9 (e.g. a trusted third party). This can include a third party acting as a common directory, e.g. a credential authority. Thus, in some examples, the first node master common key (P1C) can be requested and received by the second node 7 (and vice versa) only when it is determined that a common secret (CS) is required.

[0188] The registration step can only need to be performed once as an initial set up of, for example, a digital wallet.

[0189] Session initiation and determination of common secret by first node 3

[0190] An example of determining a common secret (CS) will now be described with reference to Figure 4 The common secret (CS) can be used for a particular session, time, transaction or other use between the first node 3 and the second node 7, and the use of the same common secret (CS) is undesirable or insecure. Thus, the common secret (CS) can change between different sessions, times, transactions, etc. The common secret (CS) can be determined by the first node 3, 350. The common secret (CS) can be determined by the second node 7, 360. The common secret (CS) can be determined by the third node 9, 370.

[0191] To illustrate the secure transmission techniques described above, the following is provided.

[0192] Generating message (M) 310

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

[0194] Message (M) = Unix Time + nonce (Equation 3)

[0195] In some examples, the message (M) is arbitrary. However, it will be appreciated that the message (M) can have a selective value (e.g. a Unix time, etc.) which can be used for some applications.

[0196] The method 300 includes sending the message (M) to the second node 7 via the communication network 5, 315. The message (M) can be sent via an unsecured network as the message (M) does not include information about a private key.

[0197] Determining generator value (GV) 320

[0198] The method 300 further comprises a step of determining a generator value (GV) based on the message (M) 320. In this example, this comprises determining a cryptographic hash of the message. Examples of cryptographic hash algorithms include SHA-256 which creates a 256-bit generator value (GV). That is:

[0199] GV = SHA-256(M) (Equation 4)

[0200] It will be appreciated that other hash algorithms can be used. This can include other hash algorithms in the Secure Hash Algorithm (SHA) family. Some particular examples include those in the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256. Other hash algorithms can include those in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. A particular example can include RIPEMD-160. Other hash functions can include those based on the Zémor-Tillich hash function and the knapsack hash function family.

[0201] Determining first node secondary private key 330

[0202] The method 300 then comprises a step of determining a first node secondary private key (V 1C ) based on the second node master private key (V 2C ) and the generator value (GV) 330. This can be based on a scalar multiplication of the first node master private key (V 1C ) with the generator value (GV) according to the following equation:

[0203] V 2C = V 1C + GV (Equation 5)

[0204] Thus, the first node secondary private key (V 2C ) is not a random value, but is deterministically derived from the first node master private key. The corresponding public key in the cryptographic pair, i.e. the first node secondary public key (P 2C ), has the following relationship:

[0205] P 2C = V 2C x G (Equation 6)

[0206] V 2CSubstituting into Equation 6 gives:

[0207] P 2C = (V 1C + GV) x G (Equation 7)

[0208] where the "+" operator denotes elliptic curve point addition. Note that elliptic curve cryptography algebra is commutative, and Equation 7 can be expressed as follows:

[0209] P 2C = V 1C x G + GV x G (Equation 8)

[0210] Finally, Equation 1 can be substituted into Equation 7, giving:

[0211] P 2C = P 1C + GV x G (Equation 9.1)

[0212] P 2C = P 1C + SHA-256(M) x G (Equation 9.2)

[0213] Thus, given knowledge of the first node master public key (P 1C ) and the message (M), the corresponding first node secondary public key (P 2C ) can be obtained. The second node 7 can have this knowledge, and thus determine the first node secondary public key (P 2C ) independently, as will be discussed in further detail below with respect to method 400.

[0214] Generating first signed message (SM1) 350 based on message and first node secondary private key

[0215] Method 300 further comprises generating a first signed message (SM1) 350 based on the message (M) and the determined first node secondary secret key (V 2C ). Generating a signed message comprises applying a digital signature algorithm to digitally sign the message (M). In one example, this comprises applying the first node secondary secret key (V 2C ) to the message in an elliptic curve digital signature algorithm (ECDSA) to obtain the first signed message (SM1).

[0216] Examples of ECDSA include ECDSA based on the ECC system with secp256kl, secp256rl, secp384rl, se3cp521rl.

[0217] The first signed message (SM1) can be utilised with the corresponding first node secondary public key (P 2C) verification. This verification of the first signed message (SM1) can be used by the second node 7 to authenticate the first node 3, as will be discussed below in method 400.

[0218] Determining second node secondary public key 370

[0219] The first node 3 can then determine a second node secondary public key (P 2S ), 370. As discussed above, the second node secondary public key (P 2S ) can be based at least on the second node primary public key (P 1S ) and the generator value (GV). In this example, because the public key is determined 370' using an elliptic curve point multiplication of the private key with a base point (G), the second node secondary public key (P 2S ) can be expressed in a similar manner to equation 6 as follows:

[0220] P 2S = V 2S x G (equation 10.1)

[0221] P 2S = P 1S + GV x G (equation 10.2)

[0222] The mathematical proof for equation 10.2 is the same as described above for the first node secondary public key (P 2C ) used to derive equation 9.1. It will be appreciated that the first node 3 can determine the second node secondary public key 370 independently of the second node 7.

[0223] Determining common secret at first node 3 380

[0224] The first node 3 can then determine a common secret (CS) 380 based on the determined first node secondary private key (V 2C ) and the determined second node secondary public key (P 2S ). The common secret (CS) can be determined by the first node 3 by:

[0225] S = V 2C x P 2S (equation 11)

[0226] Method 400 performed at second node 7

[0227] A corresponding method 400 performed at the second node 7 will now be described. It will be appreciated that some of these steps are similar to the steps discussed above performed by the first node 3.

[0228] The method 400 includes receiving a message (M) from the first node 3 via the communications network 5 410. This message can comprise the message (M) sent by the first node 3 at step 315. The second node 7 then determines a generator value (GV) based on the message (M) 420. 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 described above. In this example, the second node 7 performs this determination step 420 independently of the first node 3.

[0229] The next step includes determining a first node secondary public key (P 1C ) based on the first node primary public key (P 2C ) and the generator value (GV) 430. In this example, because the public key is determined 430' using an elliptic curve point multiplication of the private key with a base point (G), the first node secondary public key (P 2C ) can be expressed in a similar manner to equation 9 as follows:

[0230] P 2C = V 2C x G (equation 12.1)

[0231] P 2C = P 1C + GV x G (equation 12.2)

[0232] The mathematical proof for equations 12.1 and 12.2 is the same as that discussed above for equations 10.1 and 10.2.

[0233] Second node 7 authenticates first node 3

[0234] The method 400 can include steps performed by the second node 7 to authenticate that the purported first node 3 is the first node 3. As discussed previously, this includes receiving a first signed message (SM1) from the first node 3 440. The second node 7 can then confirm the signature on the first signed message (SM1) using the first node secondary public key (P 2C ) determined at step 430 450.

[0235] The digital signature can be verified according to the Elliptic Curve Digital Signature Algorithm (ECDSA) as discussed above. Importantly, the first signed message (SM1) signed with the first node secondary private key (V 2C ) should only be correctly verified with the corresponding first node secondary public key (P 2C ) because V 2C and P 2C form a cryptographic pair. Because these keys are for the first node primary private key (V 1C) and the first node master public key (P 1C ) is deterministic, so the verification of the first signed message (SM1) can be used as a basis to authenticate that the purported first node that sent the first signed message (SM1) is the same first node 3 during registration. Thus, the second node 7 can further perform the step of authenticating (460) the first node 3 based on confirming (450) the result of the first signed message.

[0236] The above authentication can be adapted to scenarios where one of the two nodes is a trusted node and only one of the nodes needs to be authenticated. For example, the first node 3 can be a client and the second node 7 can be a server that is trusted by the client, e.g. a wallet provider. Thus, the server (second node 7) can need to authenticate the client’s (first node 3) credentials in order to allow the client to access the server system. The server can not need to authenticate the server’s credentials to the client. However, in some scenarios, both nodes can need to authenticate each other, e.g. in a peer-to-peer scenario.

[0237] Second node 7 determines common secret

[0238] The method 400 can further comprise the second node 7 determining a second node secondary private key (V 1S ) based on the second node master private key (V 2S ) and the generator value (GV) 470. Similar to the step 330 performed by the first node 3, the second node secondary private key (V 2S ) can be based on a scalar addition of the second node master private key (V 1S ) and the generator value (GV) according to the following equation:

[0239] V 2S = V 1S + GV (Equation 13.1)

[0240] V 2S = V 1S + SHA-256(M) (Equation 13.2)

[0241] The second node 7 can then determine a common secret (CS) 480 based on the second node secondary private key (V 2S ) and the first node secondary public key (P 2C ) independently of the first node 3 based on the following equation:

[0242] S = V 2S x P 2C (Equation 14)

[0243] Proof of common secret (CS) determined by first node 3 and second node 7

[0244] The common secret (CS) determined by the first node 3 is the same as the common secret (CS) determined at the second node 7. A mathematical proof that equations 11 and 14 provide the same common secret (CS) will now be described.

[0245] Referring instead to the common secret (CS) determined by the first node 3, equation 10.1 can be replaced by equation 11 as follows:

[0246] S = V 2C x P 2S (Equation 11)

[0247] S = V 2C x (V 2S x G)

[0248] S = (V 2C x V 2S ) x G (Equation 15)

[0249] Referring instead to the common secret (CS) determined by the second node 7, equation 12.1 can be replaced by equation 14 as follows:

[0250] S = V 2S x P 2C (Equation 14)

[0251] S = V 2S x (V 2C x G)

[0252] S = (V 2S x V 2C ) x G (Equation 16)

[0253] Because the ECC algebra is commutative, equations 15 and 16 are equivalent because:

[0254] S = (V 2C x V 2S ) x G = (V 2S x V 2C ) x G (Equation 17)

[0255] Common secret (CS) and secret key

[0256] The common secret (CS) can now be used as a secret key, or as the basis for a secret key in a symmetric key algorithm, for secure communication between the first node 3 and the second node 7. This communication can be used to communicate a portion of a private key, a representative or identifier of a private key, or a mnemonic for a private key. Thus, once the present application has been used during setup of, for example, a digital wallet or other controlled resource, secure communication between the parties can be performed next.

[0257] The common secret (CS) can be in the form of an elliptic curve point (x S ,y S ). The form can be converted to a standard key format using a standard public known operation agreed upon by the nodes 3, 7. For example, the x S value can be a 256-bit integer, which can be used as a key for AES 256 encryption. The x S value can also be converted to a 160-bit integer using RIPEMD 160 for use in any application requiring a key of this length.

[0258] The common secret (CS) can be determined as required. Importantly, the first node 3 does not need to store the common secret (CS) as it can be re-determined based on the message (M). In some instances, the message (M) used can be stored in the data store 13, 17, 19 (or other data store) without the same level of security as required for the first node master private key (V 1C ). In some instances, the message (M) can be publicly available. However, depending on the application, the common secret (CS) can be stored in the first data store (X) associated with the first node if it is kept as securely as the first node master private key (V 1C ).

[0259] It should be noted that the above-mentioned embodiments illustrate rather than limit the application, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the application as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of elements or steps other than those listed in a claim or specification. In the present specification, the word 'comprising' means 'including at least the elements or steps listed in the claim or specification'. Singular references do not exclude the plural and plurals do not exclude the singular. By'means of' is meant 'either literally by the means or by equivalent means'. The mere fact that different features are recited in mutually different dependent claims does not indicate that multiple patents can be directed at an apparatus or a method having the same novelty.

Claims

1. A computer-implemented method comprising: determining a first entity secondary private key for a first node in a network based on at least a first entity master private key and a generator value; determining a second entity secondary public key for a second node in the network based on at least a second entity master public key and the generator value; determining a common secret at the first node in the network based on the first entity secondary private key for the first node in the network and the second entity secondary public key for the second node in the network; and transmitting at least one share of a verification element, which has been split into a plurality of shares, to the second node using the common secret; wherein the verification element is computable from a threshold number of the shares; and wherein the common secret is determinable at the second node of the network by determining a second entity secondary private key for the second node based on at least a second entity master private key and the generator value, determining a first entity secondary public key for the first node based on at least a first entity master public key and the generator value, and determining the common secret based on the second entity secondary private key for the second node and the first entity secondary public key for the first node. the verification element comprises:

2. The method of claim 1, wherein, a representation of an encryption key, wherein the representation is different from the encryption key; or one or more elements that can be used to obtain an encryption key. transmitting the at least one share of the verification element using the common secret comprises:

3. The method of claim 1, wherein, generating an encryption key using the common secret; and transmitting the at least one share of the verification element in an encrypted format using the encryption key.

4. The method of claim 1, wherein: the at least one share of the verification element comprises at least three shares of the verification element; and the method further comprises storing the at least three shares of the verification element at different locations from each other. a first share of the at least three shares is stored in a storage facility different from one or more other storage facilities in which other shares of the at least three shares are stored.

5. The method of claim 4, wherein, the verification element is an encryption key.

6. The method of claim 1, wherein, the verification element can be used to control access to a resource.

7. The method of claim 1, wherein, the resource is a digital wallet.

8. The method of claim 7, wherein, the verification element is split into the plurality of shares such that the verification element is recoverable or reproducible from two or more of the plurality of shares, wherein no individual share of the plurality of shares is sufficient to recover or reproduce the verification element.

9. The method of claim 1, further comprising: a Shamir secret sharing scheme is used as part of splitting the verification element into the plurality of shares.

10. The method of claim 9, wherein, 11. A computer-implemented system arranged to control access to a digital wallet, the computer-implemented system being operable to: determine a first entity secondary private key based on at least a first entity master private key and a generator value; determine a second entity secondary public key based on at least a second entity master public key and the generator value; the same common secret being determinable at the second entity based on a second entity secondary private key and a first entity secondary public key; and determining a public secret at the first entity based on the first entity secondary private key and the second entity secondary public key, wherein ​ to transmit, using the common secret, at least one share of a verification element that has been split into a plurality of shares to the second entity, the verification element being for controlling access to a digital wallet; wherein the verification element is computable from a threshold number of the shares; wherein: the first entity secondary public key is based on at least the first entity primary public key and the generator value, the second entity secondary private key is based on at least the second entity primary private key and the generator value.

12. The system of claim 11, wherein: the generator value is based on a message; and the system is further operable to: generate a first signed message based on the message and the first entity secondary private key; and transmit the first signed message to the second entity, wherein the second entity can verify the first signed message using the first entity secondary public key to authenticate the first entity. the common secret is determined independently of each other at the first entity and the second entity, such that the common secret does not need to be transmitted over a communication channel between the first entity and the second entity.

13. The system of claim 11, wherein, the common secret is only accessible by the first entity and the second entity.

14. The system of claim 13, wherein, the first entity secondary public key and the second entity secondary public key are according to an ECC system agreed by the first entity and the second entity and use a base point.

15. The system of claim 11, wherein, 16. A method of controlling access to a digital wallet, the method comprising: determining a first entity secondary private key based on at least a first entity primary private key and a generator value; determining a second entity secondary public key based on at least a second entity primary public key and the generator value; determining a common secret at the first entity based on the first entity secondary private key and the second entity secondary public key, wherein the same common secret is determinable at the second entity based on a second entity secondary private key and a first entity secondary public key; and transmitting, using the common secret, at least one share of a verification element that has been split into a plurality of shares to the second entity, the verification element being for controlling access to a digital wallet; wherein the verification element is computable from a threshold number of the shares; wherein: the first entity secondary public key is based on at least the first entity primary public key and the generator value, the second entity secondary private key is based on at least the second entity primary private key and the generator value.

17. The method of claim 16, wherein: the generator value is based on a message; and the method further comprises: generating a first signed message based on the message and the first entity secondary private key; and transmitting the first signed message to the second entity, wherein the second entity can verify the first signed message using the first entity secondary public key to authenticate the first entity. the common secret is determined independently of each other at the first entity and the second entity, such that the common secret does not need to be transmitted over a communication channel between the first entity and the second entity.

18. The method of claim 16, wherein, the common secret is only accessible by the first entity and the second entity.

19. The method of claim 16, wherein, the first entity secondary public key and the second entity secondary public key are according to an ECC system agreed by the first entity and the second entity and use a base point.

20. The method of claim 16, wherein, The first entity secondary common key and the second entity secondary common key are based on an ECC system agreed upon by the first entity and the second entity and use a base point. The first entity secondary common key and the second entity secondary common key are based on an ECC system agreed upon by the first entity and the second entity and use a base point. The first entity secondary common key and the second entity secondary common key are based on an ECC system agreed upon by

Images