Secure multiparty loss-tolerant storage and transfer of encryption key for block chain-based system in conjunction with wallet management system

Abstract

To provide a computer implemented solution for controlling access to resources.SOLUTION: In one or more embodiments, a method includes the steps of: dividing a verification element into a plurality of shares; determining a common secret in two or more nodes in a network; transmitting at least one share of the verification element between the two or more nodes using the common secret; and storing at least three shares of the verification element in locations different from each other.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to computer and data security, and more particularly to secure handling of sensitive data items such as cryptographic keys. The present invention provides an access control mechanism. The present invention is particularly suited for use with, but not limited to, digital (software) wallets. This can include wallets used in connection with cryptocurrencies such as Bitcoin. The present invention provides an advantageous access control mechanism. [Background technology]

[0002] Cryptography involves techniques for the secure storage and communication of sensitive data between two or more nodes in a network. Nodes may include mobile communication devices, tablet computers, laptop computers, desktops, 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, etc. Nodes may be associated with natural persons, groups of people such as employees of a company, systems such as a banking system, or distributed peer-to-peer ledgers (i.e., blockchains), etc.

[0003] Two or more nodes may be linked by an insecure communications network, vulnerable to eavesdropping or interception by unauthorized third parties. Thus, messages transmitted between the nodes are often transmitted in encrypted form. Upon receipt, the intended recipient decrypts the message using a corresponding decryption key or other decryption method. Thus, the security of such communications may rely on preventing third parties from determining the corresponding decryption key.

[0004] One known encryption method involves using a symmetric key algorithm. The keys are symmetric in the sense that the same symmetric key is used to both encrypt plaintext messages and decrypt ciphertext messages. However, the symmetric key must be transmitted to both nodes in a secure manner to prevent unauthorized access to the symmetric key. This may include, for example, physically delivering the symmetric key to the (authorized) node so that it is not transmitted over an insecure communication network. However, physical delivery is not always a practical option. Thus, a problem in such encryption systems is establishing a symmetric key (which may be based on a common secret) between nodes across an insecure electronic network such as the Internet. Thus, this step of providing the symmetric key (common secret) is a potentially serious vulnerability. Because symmetric key algorithms and protocols are simple and widely used, there is a need for the ability for two nodes to determine a symmetric key based on a common secret securely across an insecure network.

[0005] The use of asymmetric keys, also known as public key cryptography, avoids this problem to some extent. The private key is kept secret, whereas the public key can be made publicly available. Interception of the public key in the network is not catastrophic. Existing protocols include the Diffie-Hellman key exchange and the three-pass protocol.

[0006] However, storing a private key raises significant security issues. Consider, for example, a digital wallet, such as a Bitcoin wallet, which includes software that allows a user to connect with other nodes to make transactions with their electronic assets, e.g., to purchase goods and services with Bitcoin funds. Public key cryptography is often used to protect essential information required for such connections and transactions. The private key is stored by the wallet installed on the user's device (the "client side") or by the wallet service provider (the "server side"). However, if the private key is stored only on the client side, it may be lost due to theft, loss, or damage caused to the user's hardware, e.g., computer, mobile phone, etc. Similarly, if a user dies or becomes incapacitated, knowledge of or access to the private key may be lost, thus rendering the funds associated with the wallet inaccessible. Storing the private key on the server side may overcome these issues, but the user must be prepared to trust the service provider to keep their private key secure. A security breach on the server side is a real and significant risk. Summary of the Invention [Problem to be solved by the invention]

[0007] It is therefore desirable to provide a solution that allows for the secure handling of a secret. This secret can be a cryptographic key and / or anything that can provide access to a key. Such an improved solution has now been devised. According to the present invention, an improved solution is provided as defined in the appended claims. [Means for solving the problem]

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

[0009] The present invention may be used during the setup, registration or creation of a digital wallet over an insecure communications channel (such as the Internet) to allow subsequent wallet related operations, such as transactions, to be handled, communicated and / or created securely.

[0010] One or more embodiments of the present invention may include deriving an encryption key from an existing encryption key pair. This may include: determining a second private key of the first entity based on at least the master private key of the first entity and the generator value; determining a second private key of the second entity based on at least the master private key of the second entity and the generator value; determining a common secret (CS) at the first entity based on a second private key of the first entity and a second public key of the second entity, and determining the common secret (CS) at the second entity based on the second private key of the second entity and the second public key of the first entity; Including, The method is such that the first entity's second public key and the second entity's second public key are based on at least the first / second entity's master key and the generator value, respectively.

[0011] Additionally or alternatively, the present invention may include a method of controlling access to a digital wallet, the method comprising: determining a second private key of the first entity based on at least the master private key of the first entity and the generator value; determining a second private key of the second entity based on at least the master private key of the second entity and the generator value; determining a common secret (CS) at the first entity based on a second private key of the first entity and a second public key of the second entity, and determining the common secret (CS) at the second entity based on the second private key of the second entity and the second public key of the first entity; Including, The method is such that the first entity's second public key and the second entity's second public key are based on at least the first / second entity's master key and the generator value, respectively.

[0012] Additionally or alternatively, the method comprises: Dividing the verification factor into a number of shares; determining a common secret at two or more nodes in the network; using the common secret to transmit at least one share of a verification factor from one node to at least one other node in the network; may include.

[0013] The verification element can be a cryptographic key. The verification element can be a private key in an asymmetric cryptographic pair. Additionally or alternatively, the verification element can be a representation of a cryptographic key or any item that can be used to access, calculate, derive, or retrieve a cryptographic key. The verification element can be any secret or value that can be used in the verification process, such as a mnemonic or seed.

[0014] Thus, one aspect of the invention may relate to splitting a secret, such as a private key, into (unique) shares. A verification factor may be split into multiple shares such that the verification factor can be recovered or recreated from two or more of the shares. Shamir's secret sharing method may be used to split the verification factor into multiple shares.

[0015] These shares can be divided such that they have no value on their own, meaning that the (original, undivided) verification factor cannot be reached using any single share. This division can be done such that the verification factor can only be restored by combining a given number of shares. In one embodiment, any two shares are sufficient to restore the verification factor.

[0016] Another aspect of the invention may relate to secure handling or storage of each share. These shares may be transmitted to and stored by different parties, some or all of which may be nodes on the network. In one embodiment, the method may include storing at least three shares of the verification element in different locations relative to each other.

[0017] At least one of the shares may be stored in a backup or "safe storage" facility, which may be separate, independent, and / or distinct from any other locations that store shares. This provides an important advantage because it allows for restoration of the verification element in the event that one of the other shares becomes unavailable. In such circumstances, the share may be retrieved from the safe storage facility.

[0018] A verification process may occur prior to recovery of the verification element using the share. The verification process may include verifying the identity of a given or designated individual and / or computing resource.

[0019] Another aspect of the invention relates to the secure distribution of one or more of the shares. The method may include creating an encryption key using a common secret, which is used to encrypt at least one share of the verification element, or a message including said at least one share.

[0020] The common secret can be determined independently at at least two nodes. Thus, each node can determine or create the secret by itself, without input from or communication with the other nodes or other parties. This means that the common secret does not need to be transmitted over a communication channel. This provides increased security, since it cannot be intercepted by unauthorized parties. The common secret can be common only to (i.e. shared only by) the at least two nodes. The common secret can then be used to generate an encryption key, which can be used for the secure transmission of the shares. Other data can also be transmitted using the encryption key.

[0021] The method may include a step of determining, at a first node (C), a common secret (CS) common to the first node (C) and the second node (S), the first node (C) determining a master private key (V 1C ) and the master public key (P 1C ) and a second node (S) is associated with a first asymmetric crypto pair having the second node's master private key (V 1S ) and the master public key of the second node (P 1S ) and the method further comprises: - At least the master private key of the first node (V 1C ) and the generator value (GV) based on which the second private key (V 2C ) - At least the master public key (P 1S) and the generator value (GV) based on the second public key (P 2S ) - The second private key of the first node (V 2C ) and the second node's second public key (P 2S determining a common secret (CS) based on the Further comprising: The second node (S) receives the second public key (P 2C ) and the second node's second private key (V 2S ) and the first node's second public key (P 2C ) contains at least the master public key (P 1C ) and the generator value (GV), the second node's second private key (V 2S ) contains at least the master private key of the second node (V 1S ) and Generator Value (GV).

[0022] The generator value (GV) is based on the message (M). The method is carried out by combining the message (M) and the second private key (V 2C ) and transmitting the first signed message (SM1) to a second node (S) via a communication network, the first signed message (SM1) including a second public key (P) of the first node (C) for authenticating the first node (C). 2C ) can be used to check the validity.

[0023] The method also includes receiving, via the communication network, a second signed message (SM2) from a second node (S) and a second public key (P 2S), and authenticating the second node (S) based on the result of validating the second signed message (SM2), the second signed message (SM2) including the message (M) or the second message (M2) and a second private key (V 2S ) was generated based on

[0024] The method may further include generating the message (M) and transmitting the message (M) to a second node (S) over a communication network. Alternatively, the method may include receiving the message (M) from the second node (S) over the communication network. In yet another alternative, the method may include receiving the message (M) from another node over the communication network. In yet another alternative, the method may include receiving the message (M) from a data store and / or an input interface associated with the first node (C).

[0025] The first node's master public key (P 1C ), the master public key of the second node (P 1S ) is the master private key (V 1C ) and the master private key of the second node (V 1S ) and a generator (G).

[0026] The method includes transmitting a master public key (P 1S ) and storing the master public key (P) of the second node in a data store associated with the first node (C). 1S ) storing the

[0027] The method includes, at a first node (C), generating a master private key (V 1C ) and the master public key (P 1C), and transmitting a master public key (P 1C ) to the second node (S) and / or other nodes; and storing the master private key (V) of the first node in a first data store associated with the first node (C). 1C ) may further comprise the step of storing the

[0028] The method may also include transmitting, via the communication network, a notification to the second node indicating that a common Elliptic Curve Cryptography (ECC) system is used with the base point (G) for the method of determining a common secret (CS). 1C ) and the master public key (P 1C The step of creating a master private key (V) of the first node based on a random integer in an allowable range specified in the common ECC system 1C ) and the following formula: P 1C =V 1C ×G The master private key of the first node (V 1C ) and the base point (G) based on the elliptic curve point multiplication of the first node’s master public key (P 1C ).

[0029] The method may further include determining a generator value (GV) based on determining a hash of the message (M), and a second private key (V 2C ) is determined by the following formula: V 2C =V 1C +GV The master private key of the first node (V 1C ) and the Generator Value (GV).

[0030] The step of determining a second public key (P2S) of the second node may include: P 2S =P 1S+GV×G The master public key of the second node (P 1S ), but can be based on the public key plus elliptic curve point multiplication of a generator value (GV) and a base point (G).

[0031] The generator value (GV) may be based on determining a hash of a previous generator value (GV).

[0032] The first asymmetric cryptographic pair and the second asymmetric cryptographic pair are based on functions of the respective previous first asymmetric cryptographic pair and previous second asymmetric cryptographic pair.

[0033] In other words, the present invention provides: Dividing the validation element into a number of shares; creating, at a first node, a derived (or second) private encryption key based on the first master asymmetric key pair; using the derived private key for encryption and / or secure transmission of at least one share of the verification factor; A method can be provided that includes:

[0034] The method may also include creating, at the second node, the same derived private key, which is created independently of the first node using the second master asymmetric key pair.

[0035] The derived private key may be part of an asymmetric key pair that includes a private key and a public key. The first and / or second node may create the private key (and its corresponding public key) using Elliptic Curve Cryptography (ECC).

[0036] The method comprises: agreeing between the first node and the second node on a standard ECC system using a basepoint (G); and / or creating a public / private key pair at the first and / or second node using an agreed standard ECC system and publishing the public key, which means making the public key publicly available; and / or The master public key of the first node (P MC ) at the second node or elsewhere, and / or register the master public key (P MC ) at the first node or at another location; and / or sending a message (M) from the first node to the second node and / or vice versa and generating a hash of the message, which message may be signed with a derived private key, which may represent the only transmission needed to 1) establish a shared secret between the nodes and 2) initiate secured communications between them, the first node or the second node using the received message M to create its own derived (secondary) public / private key pair, from which the node may calculate the derived public key of the other node; and / or receiving this message and independently computing a hash of the message M (e.g., SHA-256(M)); and / or Master Key (P MC ) that can be derived from the public key (P 2c ) and / or Calculated P 2C Signing (Sig-V 2C ), may include.

[0037] The derived private key may be deterministically derived from the master public key of the first node or the second node.

[0038] The present invention may also comprise a computer-implemented system arranged and configured to perform any embodiment of the above method. The system may comprise or utilize a blockchain network or platform. Additionally or alternatively, the system may comprise a digital wallet provider or management system.

[0039] Any feature described above in relation to one aspect or embodiment of the invention may also be used in relation to any other aspect or embodiment, for example features described in relation to the method may be applied to the system and vice versa.

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

[0041] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0042] [Figure 1] FIG. 1 is a schematic diagram of an exemplary system for determining a common secret for a first node and a second node that can be used in accordance with the present invention for secure transmission of highly sensitive information, such as sharing a private key. [Diagram 2] 1 is a flow chart of a computer-implemented method for determining a common secret such as may be used in accordance with the present invention for secure transmission of highly sensitive information, such as sharing a private key. [Diagram 3] 1 is a flowchart of a computer-implemented method for registering a first node and a second node. [Figure 4] 4 is another flow chart of a computer-implemented method for determining a common secret that may be used in accordance with the present invention for secure transmission of sensitive information, such as shares of a private key. [Diagram 5]1 is a flowchart of a computer-implemented method of secure communication between a first node and a second node. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] As explained above, there is a need for improved storage and / or exchange of secrets, such as cryptographic keys, or secrets that can be used to generate keys. The secrets can be seeds for wallet mnemonics, or other security-related items. The present invention provides such a solution. One embodiment is described below for purposes of understanding, this embodiment using the context of a digital wallet implemented on a blockchain. However, the present invention is not limited to such implementations and can be implemented in relation to any computer-implemented network or system.

[0044] As mentioned above, public key cryptography is often used in connection with digital wallets. If the end user (referred to as the "client" or simply "user") is responsible for storing his or her private key, problems may arise when the user or the user's hardware becomes unavailable, as this would render the private key, and therefore the wallet funds, inaccessible. However, storage of the key at the wallet provider's side (which may be referred to as the "server side") requires a level of trust in the provider and its security mechanisms. For this reason, the private key needs to be stored in such a way that it cannot be obtained by unauthorized parties, but can also be regenerated when necessary. The term "user" may refer to a human user or a computer-implemented resource.

[0045] One known cryptographic algorithm known as "Shamir's Secret Sharing" (4S) teaches splitting a secret into unique parts or shares, which are then distributed to different parties. The shares can then be used to reconstruct the secret. Each individual share is worthless and useless 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 needs of the situation. In some cases, all the shares may be needed, while in other cases, only a sufficient number are needed. This is known as a threshold scheme, where any k of the shares are sufficient to reconstruct the original secret.

[0046] In this exemplary embodiment, 4S is used to split a secret, such as a private key or mnemonic seed, into multiple parts. 4S is then also used to recreate the key or mnemonic seed from a fixed number of parts. The use of mnemonics is known in conjunction with digital wallets. A mnemonic is a human-friendly code or group of words that can be made into a binary seed for the creation of a wallet or data.

[0047] In this specification, the following terms are used: · A "Secret" (S) is a secret (e.g., a number or value) that needs to be shared securely between parties. A "share" is a piece of a secret. The secret is divided into pieces, and each piece is called a share. Shares are calculated from a given secret. To recover the secret, you need to obtain a certain number of shares. · The “threshold” (k) is the minimum number of shares needed to recreate or recover the secret. The secret can only be recreated with at least k shares. "prime" (p) is a random prime number.

[0048] From a broad perspective, an exemplary embodiment may include a method as follows: In this example, a "2-of-3" scheme is used (ie, k=2). A user registers with a wallet provider and creates and sets up a new wallet associated with that user. In this example, the wallet is a blockchain-enabled Bitcoin wallet. A public-private key pair is created and associated with the user’s wallet. The private key is split into shares using 4S. One share of the private key is sent to the user via secure transmission. Another share of the private key is held by the service provider and stored on the server. · Another share is sent by secure transmission to a remote location for safe storage. The term "remote" does not imply a specific geographic distance or location. Instead, as used herein, it means that the shares are held in, at or on a secure storage facility or resource that is in some sense independent from the wallet provider or the user, preferably both. "Independent" includes being physically, logically, financially, politically, and / or organizationally independent. For example, the secure storage could be outsourced to a commercial entity that offers secure storage services in exchange for a fee, or could be held by the user's attorney, or by other elected (and trusted) parties that accept the role of storing and supplying the shares on demand when necessary. The wallet provider can destroy some or all copies of the complete private key because they are no longer needed. If the private key is needed for subsequent authentication of the user (e.g. because the user next wants to make a transaction), the key can be reconstructed from the user's share, which the user provides to the wallet provider as needed, and the wallet provider's share.

[0049] The advantage of this is that even if the wallet provider's security is compromised, unauthorized parties cannot gain access to the user's private key, since the private key is not stored anywhere in the wallet provider's system and the wallet provider's system alone does not contain enough shares to allow reconstruction of the private key. This same advantage applies in situations where the client's security is compromised.

[0050] Another advantage is that by storing the shares in a secure storage location, the private key can be reconstructed by retrieving the shares from the secure storage and combining them with the wallet provider's shares. Thus, if the user dies or becomes incapacitated, or if the user's hardware (and therefore the shares) is lost, damaged, or stolen, the funds in the wallet can still be accessed. In such a situation, the identity of the user is verified. In some instances, the identity of a proven, trusted party, such as an estate administrator or lawyer, is verified. This is accomplished, for example, during the creation of documents such as death certificates, passports, legal documents, or other forms of identification. Once the authorized identity is verified, the private shares are retrieved from the secure storage. The secure storage thus serves as a kind of backup facility that can be used in exceptional or prescribed circumstances.

[0051] Thus, the present invention provides an advantageous combination of improved system / data security and convenience.The present invention provides a simple, effective and secure solution to access control.

[0052] Note that in the above example, the private key is created by the wallet service provider and each part is sent to the user and the secure storage resource. However, this may not be the case in other embodiments. It is also important to note that the transmission of parts between the parties, referred to as "nodes", must be done in a secure manner, since any unauthorized interception of multiple shares may allow the interceptor to reconstruct the secret (e.g., mnemonic or key). As will be explained below, this problem of secure exchange is also addressed by the present invention.

[0053] Further detailed aspects of the present invention are described for purposes of illustration. It should be noted that Shamir's secret sharing is a technique known in the art and one of ordinary skill in the art would recognize, understand and use it. Thus, the following is provided for completeness only.

[0054] Splitting a secret into multiple shares Given a secret S, the number of participants n, a threshold number k, and a prime number p, the following polynomial is constructed using the constant term S: y=f(x) of degree k-1 (modulo prime p)

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

[0056] 1.Conversion to Integer For the 4S algorithm, the secret needs to be an integer. Therefore, if the secret is in some other form (e.g. a string, a hexadecimal number, etc.), it must first be converted to an integer. If the secret is already an integer, this step can be omitted. For this example, let S=1234.

[0057] 2. Determining the number of shares (n) and the threshold (k) Note that k parts are needed to recreate the secret, so choose S and k such that we always have k parts available while recovering the secret. In this example, n=6 and k=3.

[0058] 3. Polynomial Generation I need to generate a polynomial of the form y=f(x) mod p. i. Determining the constant term and degree of the polynomial f(x)=a 0 +a 1 x+a 2 x 2 +a 3 x 3 +...+a k-1 x k-1 - constant term a 0 =S - Polynomial degree = k-1

[0059] Therefore, for k=3 and S=1234, the degree 2 and a 0 = 1234. f(x)=1234+a 1 x+a 1 x 2

[0060] ii. Determination of coefficients Choose k-1 random numbers (using a random (pseudo-random) number generator) such that: 0 n a 1 =166;a 2 =94. Therefore, f{x)=1234+166x+94x 2 It is.

[0061] iii. Random Prime Selection Choose a random prime number (p) such that: p>max(S,n) Let p=1613.

[0062] ​​iv. Final polynomial y=f(x)mod p y=(1234+166x+94x 2 )mod 1613

[0063] Creating a Share To divide a scenario into n shares, it is necessary to construct n points (shares) using a polynomial. y=(1234+166x+94x 2 )mod 1613

[0064] For this example, n=6, so we will have 6 points. Note that we start at x=1, not x=0.

[0065] For x=1 to 6, the six points are as follows. (1,1494);(2,329);(3,965);(4,176);(5,1188);(6,775)

[0066] Of these n(6) points, any k(3) points can be used to recreate the private key.

[0067] Reconstructing a secret from a given number of shares i. Obtaining the secret integer To reconstruct the secret, we need the following information: n=6, k=3, p=1613, k shares (x0,y0)=(1,1494);(x1,y1)=(2,329);(x2,y2)=(3,965)

[0068] Armed with the above information, techniques such as Lagrange interpolation, known in the art and readily understood by those skilled in the art, can be used to reconstruct the entire polynomial. The coefficients can be calculated according to the following formula: a i (x)=[Σ k-1 i=0 y i Π0≦j≦k-1,j≠i (xx j ) / (x i -x j )]mod p However, S=a 0 Therefore, a 0 =a 0 You just need to get (0).

number

[0069] Those skilled in the art will appreciate that in the above, the exponent -1 represents taking the reciprocal. Most programming languages ​​include built-in packages that perform mathematical operations such as reciprocal.

[0070] ii. Converting the integer to the desired format If step 1 was performed to convert a particular format to an integer, the reverse procedure is followed to convert the integer back to the desired format.

[0071] Securely Send Shares As mentioned above, it is important that the shares of the secret are transmitted to their respective recipients in a secure manner to prevent unauthorized parties from reconstructing the secret. In a preferred embodiment, secure transmission can be achieved as described below.

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

[0073] The two parties can be any two of a wallet service provider, a user, a secure storage resource, or any other legitimate parties. Hereinafter, for convenience, they are referred to as a first node (C) and a second node (S). The objective is to generate a common (CS) secret that is known to both nodes, but is not transmitted over the communication channel, thus eliminating the possibility of unauthorized discovery. The secret splitting and secure storage techniques, in combination with the secure transmission techniques as described below, provide a secure key management solution.

[0074] The secure transmission technique of the present invention involves the CS being generated in an independent manner at the end of each transmission, so that while both nodes know the CS, it did not have to be transported over 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 use for subsequent communications. This has particular advantages for the transmission of split private keys from one party to another during the wallet registration process.

[0075] 1 shows a system 1 comprising a first node 3 in communication with a second node 7 over a communication network 5. The first node 3 has an associated first processing device 23 and the second node 5 has an associated second processing device 27. The first node 3 and the second node 7 may include electronic devices such as computers, phones, tablet computers, mobile communication devices, 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 of a digital wallet provider.

[0076] The first node 3 receives the master private key (V 1C ) and the master public key (P 1C) The second node (7) is associated with a first asymmetric crypto pair having the second node's master private key (V 1S ) and the master public key of the second node (P 1S ) in the second asymmetric cryptographic pair having a unique public key-private key pair. In other words, the first node and the second node each possess a respective public key-private key pair.

[0077] The first and second asymmetric crypto pairs for the first node 3 and second node 7, respectively, may be created during a registration process, such as registering a wallet. The public key of each node may be publicly shared, for example via the communication network 5.

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

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

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

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

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

[0083] The method 300, 400 may include an additional step. The method 300 comprises: 2CThe method 300 may further include creating a signed message (SM1) based on a second public key (P ) of the first node. The method 300 may further include sending (360) the first signed message (SM1) to a second node 7 over the communication network. Meanwhile, the second node 7 may receive 440 the first signed message (SM1). The method 400 may further include receiving 440 the first signed message (SM1) based on a second public key (P ) of the first node. 2C ) and authenticating (460) the first node 3 based on the validation of the first signed message (SM1). Advantageously, this allows the second node 7 to authenticate that the purported first node (where the first signed message was created) is the first node 3. This is because only the first node 3 has the master private key (V 1C ), and therefore only the first node 3 has access to the second private key (V 2C ) can be determined. It will be appreciated that a second signed message (SM2) can be created 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.

[0084] Sharing of the message (M) between the first node and the second node can be accomplished in a variety of ways. In one example, the message can be created at the first node 3, which is then sent to the second node 7 over the communication network 5. Alternatively, the message can be created at the second node 7, which is then sent to the second node 7 over the communication network 5. In yet another example, the message can be generated at the third node 9, which is then sent to both the first node 3 and the second node 7. In yet another alternative, the user can enter a message through the user interface 15, which is received by the first node 3 and the second node 7. In yet another example, the 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 sent over an insecure network 5.

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

[0086] Advantageously, a record enabling reconstruction of the common secret (CS) can be kept without the record itself having to be privately stored or securely transmitted. This is advantageous when a large number of transactions take place at the first node 3 and the second node 7, making it impractical to store all the messages (M) at the nodes themselves.

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

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

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

[0090] In the method 100, 200, this involves the first and second nodes agreeing on a common ECC system and using a base point (G) (110, 210). (Note: the base point is 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 secp256Kl, the ECC system used by Bitcoin. The base point (G) can be selected, randomly created, or assigned.

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

[0092] The method 100 is performed when a first node 3 acquires the master private key (V 1C ) and the master public key of the first node (P 1C The method also includes creating (120) a first asymmetric crypto pair including a master private key (V) of the first node based, at least in part, on random integers in an allowable range specified in the common ECC system. 1C ), which is expressed as P 1C =V 1C ×G (Formula 1) The master private key (V 1C ) and the base point (G) based on the elliptic curve point multiplication of the first node’s master public key (P 1C This also includes determining the

[0093] Thus, the first asymmetric crypto pair includes: V 1C : The master private key of the first node, which is kept secret by the first node. P1C : The master public key of the first node, which is publicly known.

[0094] The first node 3 stores the first node's master private key (V 1C ) and the master public key (P 1C ) can be stored. For security purposes, the master private key (V 1C ) may be stored in a secure portion of the first data store 13 to ensure that the key remains private.

[0095] Method 100 obtains the master public key (P 1C ) to the second node 7 via the communication network 5. The second node 7 transmits (130) the master public key (P 1C ) (220), the first node’s master public key (P 1C ) may be stored 230 in a second data store 17 associated with the second node 7.

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

[0097] Thus, the second asymmetric crypto-pair comprises: V 1S : The master private key of the second node, which is kept secret by the second node. P 1S: The second node’s master public key, known publicly.

[0098] The second node 7 may store the second asymmetric crypto pair in the second data store 17. The method 200 may include storing the master public key (P 1S ) to the first node 3. Meanwhile, the first node 3 transmits (250) the master public key (P 1S ) may be received (140) and stored (150).

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

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

[0101] Session initiation and common secret determination by first node 3 An example of determining a common secret (CS) will now be described with reference to Figure 4. The common secret (CS) may be used for a particular session, time, transaction, or other purpose between the first node 3 and the second node 7, and using the same common secret (CS) may be undesirable or insecure. Thus, the common secret (CS) may be changed between different sessions, times, transactions, etc.

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

[0103] Create a Message (M) 310 In this example, the method 300 performed by the first node 3 includes creating (310) a message (M). The message (M) may be random, pseudorandom, or user defined. In one example, the message (M) is based on Unix time and a nonce (and an arbitrary value). For example, the message (M) may be provided as follows: Message (M) = UnixTime + Nonce (Equation 3)

[0104] In some examples, the message (M) is arbitrary, but it will be appreciated that the message (M) may have optional values ​​(such as Unix time) that may be useful in some applications.

[0105] The method 300 includes sending (315) a message (M) to the second node 7 over the communications network 3. This message (M) can be sent over an insecure network because it does not include information about the private key.

[0106] Determination of Generator Value (GV) 320 The method 300 further includes determining 320 a generator value (GV) based on the message (M). In this example, this includes determining a cryptographic hash of the message. Examples of cryptographic hash algorithms include SHA-256 to generate a 256-bit generator value (GV), i.e.: GV = SHA-256(M) (Equation 4)

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

[0108] Determining 330 the second private key of the first node Additionally, the method 300 may include obtaining the master private key (V 1C ) and the generator value (GV) based on which the second private key (V 2C ), which can be achieved by the following formula: V 2C =V 1C +GV (Equation 5) The master private key (V 1C ) and a generator value (GV).

[0109] Therefore, the second private key of the first node (V 2C ) is not a random value, but is instead derived deterministically from the master private key of the first node. The corresponding public key in the cryptographic pair, i.e., the second public key (P 2C ) have the following relationship: P 2C =V 2C ×G (Formula 6)

[0110] V from Equation 5 2C By substituting into Equation 6, we obtain: P 2C =(V 1C+GV)×G (Formula 7) Here, the “+” operator denotes elliptic curve point addition. Keeping in mind that elliptic curve cryptography algebra is distributive, Equation 7 can be expressed as follows: P 2C =V 1C ×G+GV×G (Formula 8)

[0111] Finally, substituting Equation 1 into Equation 7, we obtain: P 2C =P 1C +GV×G (Formula 9.1) P 2C =P 1C +SHA-256(M)×G (Equation 9.2)

[0112] Therefore, the second public key (P 2C ) is the master public key (P 1C ) and the message (M). With such knowledge, the second node 7 can derive the second public key (P 2C ) can be determined independently.

[0113] Generation 350 of a first signed message (SM1) based on the message and the second private key of the first node. The method 300 receives a message (M) and a determined second private key (V 2C The method further includes creating (350) a first signed message (SM1) based on the first node's second private key (V) in an Elliptic Curve Digital Signature Algorithm (ECDSA). Creating the signed message includes applying a digital signature algorithm to digitally sign the message (M). In one example, this is done using an Elliptic Curve Digital Signature Algorithm (ECDSA) algorithm to digitally sign the message (M). 2C ) to the message to obtain a first signed message (SM1).

[0114] Examples of ECDSA include those based on ECC systems having secp256kl, secp256rl, secp384rl, se3cp521rl.

[0115] The first signed message (SM1) is sent to the second node 7 via a second public key (P 2C ) This verification of the first signed message (SM1) can be used by the second node 7 to authenticate the first node 3, as described below in method 400.

[0116] Determining a second public key of the second node 370' Furthermore, the first node 3 transmits the second public key (P 2S ) can be determined (370). As described above, the second node's second public key (P 2S ) contains at least the master public key (P 1S ) and a generator value (GV). In this example, the public key is determined 370' as a private key by elliptic curve point multiplication with a base point (G), so that the second public key (P 2S ) can be expressed in a manner similar to Equation 6 as follows: P 2S =V 2S ×G (Formula 10.1) P 2S =P 1S +GV×G (Equation 10.2)

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

[0118] Determining the common secret at the first node 3 380 Furthermore, the first node 3 transmits the determined second private key (V 2C) and the determined second public key (P 2S ) a common secret (CS) may be determined (380) based on the first node 3. The common secret (CS) may be determined by the first node 3 according to the following formula: S=V 2C ×P 2S (Formula 11)

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

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

[0121] The next step is to generate the master public key (P 1C ) and the generator value (GV) based on the second public key (P 2C In this example, the public key is determined as a private key by elliptic curve point multiplication with the base point (G) (430′), so that the second public key (P 2C ) can be expressed in a manner similar to Equation 9 as follows: P 2C =V 2C ×G (Equation 12.1) P 2C =P 1C +GV×G (Equation 12.2)

[0122] The mathematical proofs of Equations 12.1 and 12.2 are the same as those explained above for Equations 10.1 and 10.2.

[0123] Authentication of First Node 3 by Second Node 7 The method 400 may include a step performed by the second node 7 authenticating that the alleged first node 3 is the first node 3. As mentioned above, this includes receiving (440) a first signed message (SM1) from the first node 3. The second node 7 then receives the second public key (P ) of the first node determined in step 430. 2C ) may be used to validate (450) the signature in the first signed message (SM1).

[0124] As mentioned above, the verification of the digital signature can be performed according to the Elliptic Curve Digital Signature Algorithm (ECDSA). Importantly, the second private key (V 2C ) is used to send a first signed message (SM1) signed with the second public key (P 2C ) should be correctly verified only by V 2C and P 2C These keys are generated when the first node 3 registers, and are called the master private key (V 1C ) and the master public key (P 1C ), verifying the first signed message (SM1) can be used as a basis for authenticating that the putative first node sending the first signed message (SM1) is the same first node 3 during registration. For this reason, the second node 7 can further perform a step (460) of authenticating the first node 3 based on the result of validating (450) the first signed message.

[0125] The above authentication is suitable for 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 may be a client and the second node 7 may be a server trusted by the client, such as a wallet provider. Thus, the server (second node 7) may need to authenticate the credentials of the client (first node 3) to allow the client access to the server system. There may be cases where the server does not need to authenticate the server's credentials to the client. However, in some scenarios, it may be desirable for both nodes to be authenticated to each other, such as in a peer-to-peer scenario.

[0126] Determination of the Common Secret by the Second Node 7 The method 400 involves a second node 7 transmitting the second node's master private key (V 1S ) and the generator value (GV) based on the second node's second private key (V 2S ) of the second node. Similarly to step 330 performed by the first node 3, the second private key (V 2S ) is expressed as follows: V 2S =V 1S +GV (Equation 13.1) V 2S =V 1S +SHA-256(M) (Formula 13.2) The master private key of the second node (V 1S ) and a generator value (GV).

[0127] Furthermore, the second node 7, independently of the first node 3, derives the second node's second private key (V 2S ) and the first node's second public key (P 2C ) a common secret (CS) can be determined (480). S=V 2S ×P 2C (Formula 14)

[0128] Proof of a common secret (CS) determined by the first node 3 and the second node 7 The common secret (CS) determined by the first node 3 is the same as the common secret (CS) determined at the second node 7. We now describe a mathematical proof that Equation 11 and Equation 14 result in the same common secret (CS).

[0129] Returning to the common secret (CS) determined by the first node 3, Equation 10.1 can be substituted into Equation 11 as follows: S=V 2C ×P 2S (Formula 11) S=V 2C ×(V 2S ×G) S=(V 2C ×V 2S )×G (Equation 15)

[0130] Returning to the common secret (CS) determined by the second node 7, Equation 12.1 can be substituted into Equation 14 as follows: S=V 2S ×P 2C (Formula 14) S=V 2S ×(V 2C ×G) S=(V 2S ×V 2C )×G (Equation 16)

[0131] Since ECC algebra is commutative, Equation 15 and Equation 16 are equivalent. Therefore, S=(V 2C ×V 2S )×G=(V 2S ×V 2C )×G (Equation 17)

[0132] Common Secret (CS) and Private Key The common secret (CS) can be used as a private key, or as the basis for a private key, in a symmetric key algorithm for source communication between the first node 3 and the second node 7. This communication can be used to convey a portion of the private key, a representation or identifier of the private key, or a mnemonic for the private key. Thus, once the invention is used, for example, during the set-up of a digital wallet or other controlled resource, thereafter secure communication between the parties can take place.

[0133] The shared secret (CS) can take the form of an elliptic curve point (xs, ys). This can be converted to a standard key format using standard publicly known operations agreed upon by nodes 3 and 7. For example, the xs value can be converted to a standard key format using the AES 256 It can be a 256-bit integer that can be used as a key for encryption. It can also be converted to a 160-bit integer using RIPEMD160 for any application requiring a key of this length.

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

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

[0136] It should be noted that the above-described embodiments do not limit the present invention, and that a person skilled in the art can design any alternative embodiment without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be considered as limiting the scope of the claims. The word "comprises" and the like does not exclude the presence of elements or steps other than those recited in any claim or the specification as a whole. In this specification, "comprises" means "includes" or "consists of". The singular reference of an element does not exclude the plural reference of such elements, and vice versa. The present invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means can be embodied by one and the same hardware. The mere fact that several means are recited in mutually different independent claims does not indicate that a combination of these means cannot be used to advantage. [Explanation of symbols]

[0137] 3 First Node 5. Network 7 Second Node 9. The Third Node 11. Wiretaper

Claims

1. 1. A computer-implemented method for controlling access to a resource, the method comprising: Dividing the validation element into a number of shares; determining at least one common secret at at least one node in a network, said at least one common secret being determinable at at least one other node in said network; transmitting at least one of said shares of said verification factor to at least one of said other nodes using at least one of said common secrets; The method includes:

2. The method of claim 1 , wherein at least one of the verification elements is a cryptographic key, a representation of a cryptographic key, or an element that can be used to access, compute, or retrieve the cryptographic key.

3. generating a cryptographic key using at least one of the common secrets; The method of claim 1 or 2, wherein the encryption key is used to encrypt at least one share of the verification element or a message including or associated with the at least one share.

4. storing at least three shares of the verification element in different locations; The method of any of claims 1 to 3, wherein at least one of the three shares is stored in a backup or secure storage facility that is separate, independent and / or remote from the at least two other locations.

5. The method according to any of claims 1 to 4, wherein the resource is a digital wallet or other resource related to any form of currency.

6. the verification element is divided into a plurality of shares such that the verification element can be recovered or regenerated from two or more of the shares; The method according to any one of claims 1 to 5, wherein the verification factor is divided into a number of shares using Shamir's secret sharing scheme.

7. At least one of the shared secrets is i) is determined in at least two nodes independent of each other, so that the common secret does not need to be transmitted over a communication channel between the nodes; and / or ii) is shared only by at least two nodes; The method according to any one of claims 1 to 6.

8. A method according to any preceding claim, comprising the step of configuring, generating or registering a digital wallet, wherein the verification element is associated with the digital wallet.

9. At least one common secret is determined by a first node (C) and a second node (S) in the network, the first node (C) determining a first node master private key (V １Ｃ ) and the first node master public key (P １Ｃ ) and the second node (S) is associated with a first asymmetric cryptographic pair having a second node master private key (V １Ｓ ) and the second node master public key (P １Ｓ ) associated with a second asymmetric cryptographic pair having The method comprises: At least the first node master private key (V １Ｃ ) and the generator value (GV), the first node second private key (V ２Ｃ ) At least the second node master public key (P １Ｓ ) and a second node second public key (P ２Ｓ ) The first node second private key (V ２Ｃ ) and the second node second public key (P ２Ｓ determining the common secret (CS) based on Further comprising: The second node (S) transmits the first node second public key (P ２Ｃ ) and the second node second private key (V ２Ｓ ) the same common secret (S), The first node second public key (P ２Ｃ ) includes at least the first node master public key (P １Ｃ ) and the generator value (GV), The second node second private key (V ２Ｓ ) includes at least the second node master private key (V １Ｓ 9. The method according to claim 1, wherein the generator value (GV) is based on the eigenvalue (Eq. 11).

10. The method of claim 9, wherein the generator value (GV) is based on a message (M).

11. The message (M) and the first node second private key (V ２Ｃ ) generating a first signed message (SM1); sending said first signed message (SM1) to said second node (S) via a communications network; Further comprising: The first signed message (SM1) includes the first node second public key (P ２Ｃ 11. The method of claim 10, wherein the authentication is verifiable by

12. receiving a second signed message (SM2) from said second node (S) via a communications network; The second node second public key (P ２Ｓ ) verifying said second signed message (SM2); authenticating the second node (S) based on a result of verifying the second signed message (SM2); Further comprising: The second signed message (SM2) is generated by combining the message (M) or the second message (M2) and the second node second private key (V ２Ｓ 12. The method according to claim 10 or 11, wherein the generated signal is based on

13. generating a message (M); transmitting said message (M) to said second node (S) via a communications network; The method according to any one of claims 9 to 12, further comprising:

14. receiving said message (M) from said second node (S) via a communications network; The method according to any one of claims 10 to 13, further comprising:

15. receiving said message (M) from another node via a communications network; The method according to any one of claims 10 to 14, further comprising:

16. The first node master public key (P １Ｃ ) and the second node master public key (P １Ｓ ) are the first node master private keys (V １Ｃ ) and the second node master private key (V １Ｓ 16. The method according to claim 9, wherein the elliptic curve dot product of the first point (G) and a base point (G) is based on the elliptic curve dot product of the first point (G) and a base point (G).

17. The second node master public key (P １Ｓ ) and The second node master public key (P １Ｓ ) storing the The method according to any one of claims 9 to 16, further comprising:

18. In the first node (C), the first node master private key (V １Ｃ ) and the first node master public key (P １Ｃ ) The first node master public key (P １Ｃ ) to said second node (S) and / or other nodes; A first data store associated with the first node (C) stores the first node master private key (V １Ｃ ) storing the The method according to any one of claims 9 to 17, further comprising:

19. The method of any of claims 9 to 18, wherein the Generator Value (GV) is based on determining a hash of a previous Generator Value (GV).

20. The method according to any of claims 9 to 19, wherein the first asymmetric cryptographic pair and the second asymmetric cryptographic pair are based on a function of a previous first asymmetric cryptographic pair and a previous second asymmetric cryptographic pair, respectively.

21. A computer-based system configured to carry out the method according to any of claims 1 to 20.

22. 22. The system of claim 21, wherein the resource is a digital wallet or other resource related to any form of currency.

23. A system according to any of claims 21 to 22, wherein the system includes software configured to enable the configuration, creation or registration of a digital wallet, the verification element being associated with the digital wallet.

24. 1. A computer-implemented system configured to control access to a digital wallet, the system comprising: determining a first entity second private key based on at least the first entity master private key and the generator value; determining a second entity second public key based on at least the second entity master public key and the generator value; determining, at the first entity, a common secret (CS) based on the first entity second private key and the second entity second public key, the common secret (CS) being determinable at the second entity based on the second entity second private key and the first entity second public key; It works like this: The first entity second public key and the second entity second public key are based on at least the first entity master private key or the second entity master private key, respectively, and the generator value.

25. 1. A method of controlling access to a digital wallet, the method comprising: determining a first entity second private key based on at least the first entity master private key and the generator value; determining a second entity second public key based on at least a second entity master public key and the generator value; determining a common secret (CS) at a first entity based on the first entity second private key and the second entity second public key, the common secret (CS) being determinable at a second entity based on the second entity second private key and the first entity second public key; Including, The method of claim 1, wherein the first entity second public key and the second entity second public key are based on at least the first entity master private key or the second entity master private key, respectively, and the generator value.

Images