Hardware wallet apparatuses and method of generating cryptographic keys using same

Abstract

The method of generating a child public key with a hardware wallet apparatus having a housing enclosing a cavity and at least one printed circuit board located in the cavity, and a computing device mounted to the at least one printed circuit board, the computing device having a hardware-implemented elliptic curve function, the method generally has: generating a parent public key using the hardware-implemented elliptic curve function of the computing device, a parent private key, and a first number registered in a memory of the computing device; subsequently to said generating the parent public key, resetting the first number in the memory of the computing device; and subsequently to said resetting the first number; generating a child public key using the hardware-implemented elliptic curve function of the computing device, a child private key, and the first number registered in the memory of the computing device.

Description

HARDWARE WALLET APPARATUSES AND METHOD OF GENERATING CRYPTOGRAPHIC KEYS USING SAMEFIELD

[0001] The improvements generally relate to cryptographic hardware wallets and more specifically to hierarchical deterministic hardware wallets.BACKGROUND

[0002] Cryptocurrency wallets are devices or other physical media which are associated to computer-implemented applications and used to store digital keys. Basic functionalities of many cryptocurrency wallets is to generate and store public and private keys for cryptocurrency transactions, although keys may be used in other contexts such as signing information (e.g., for the execution of a smart contract). In other words, in a blockchain context, like Bitcoin or Ethereum, the wallet does not hold the actual currency, but digital keys which allow to perform a transaction on the currency. Different approaches to wallets can be classified in two general families: hot or cold, sometimes alternately referred to as software or hardware. In a “hot” or “software” scheme, the wallet has Internet connectivity, such as by being provided as a web-based application or directly in the memory of a user’s computer, for instance, which can be convenient for the user, but open to certain types of cyberattacks. In the “cold” or “hardware” scheme, an example of which is presented in Fig. 1 , the wallet can be embodied as a standalone electronic device which remains unconnected to the Internet between periods of use. The electronic device can be in the form of a hard drive or USB key for instance, and not have inherent internet connectivity. Internet connectivity can be provided by connecting the electronic device to a computer which has internet connectivity for instance. A cold wallet may provide a natural protection to some types of web-based cyberattacks and may thus provide higher security from that standpoint. In the theoretical case where a user would lose access to his / her keys, he / she may no longer be able to spend cryptocurrencies he / she possesses, and one of the main motivations for the use of cryptocurrency wallets is to provide solutions to this potential problem. As opposed to self-hosted wallets, some service providers will even provide custody service whereby they manage keys on behalf of the users, who can authenticate on their platform. The service provider can restore the keys in the event of a lost password or destruction of an electronic device hosting a cold wallet, for instance.

[0003] A typical use case today involves generating a pair of keys: a public key for receiving cryptocurrency at an address, and a private key for spending cryptocurrency from the address, this scheme is sometimes referred to as asymmetric cryptography and is considered a significant improvement over an alternative option referred to as symmetric key algorithms. In asymmetric cryptography, only the holder of the private key needs to keep his / her key secret for the transaction to be secure, sharing of the public key does not inherently pose a security threat.

[0004] There are different types of technologies which exist to generate pairs of public and private keys. In a blockchain context, transactions and balances are incorporated to public ledgers and can be seen by anyone. This generates a motivation to use many different addresses, and associated keys, per user, such as using different addresses for different transactions, allowing to shield the overall account balance associated to a user from public view for instance. One type of technology is the non-deterministic (ND) wallet. This type of wallet generates each key randomly. The wallet holding these keys needs to store each and every single private key used as an address, as well as a buffer of future keys that may have already been given out as addresses but not received payments yet. This represents a significant “cost” associated to the volume of data required, and perhaps more significantly, there was no upper limit to the amount of data which may be required.

[0005] More recently, hierarchical deterministic (HD) wallets have become significantly more popular than ND wallets, and are proposed in BIP32. In the context of an HD wallet, a single key string generated randomly can be used to generate an entire tree of key pairs with a stratified structure. A modern HD wallet can be backed up by storing a single seed of 64 bytes, and the seed can be represented as a mnemonic phrase of 12 or more words to make it easier for a user to remember it by heart. In an HD wallet, the wallet seed derives a single master key, which can be used to derive child keys, each of which can derive their own grandchildren keys, and so forth. Each child key in the tree can be described by its derivation path, which contains information about a key’s depth and index. The tree is deterministic: a given seed or master key will always generate the exact same tree of children keys. Although existing HD wallet are satisfactory to a certain degree, there always remains room for improvement.SUMMARY

[0006] Existing HD wallets typically include a parent (or master) key generator and a child key generator, each of these including a dedicated set of hardware computing devices communicatively coupled to one another. It was found that by re-using at least some of these hardware computing devices in both the master key and the child key generation schemes, benefits in terms of costs, circuit depth and footprint can be achieved. Broadly described, the parent key generator has a first hardware computing device hashing a random number (or any number) into a parent private key (e.g., a master private key) using a hashing function (e.g., HMAC SHA 512 hash function). The parent key generator also has a second hardware computing device outputting a parent public key based on the parent private key using an elliptic curve function (e.g., SECP256K1 elliptic curve function). In the proposed hardware wallet, the child key generator includes a parent-dependent number generator, the first hardware computing device and also the second hardware computing device. However, after the uses of the first and second hardware computing devices in the parent key generator, the memory systems of the first and second hardware computing devices are reset to their original values or memory states, and then re-used in the child key generator. More specifically, the first hardware computing device generates a child private key and a child chain code based on a parent-dependent number and on the parent chain code. Further, the second hardware computing device generates a child public key based on the child private key. It was found that by resetting the first and second hardware computing devices, these hardware components can be effectively re-used in different master key and child key generation schemes as frequently as necessary. In some embodiments, the master private key can be reinitialized by resetting the memory systems of the first and second hardware computing devices and generating new keys based on a new random number.

[0007] In accordance with a first aspect of the present disclosure, there is provided a method of generating a child public key with a hardware wallet apparatus having a housing enclosing a cavity and at least one printed circuit board located in the cavity, and a computing device mounted to the at least one printed circuit board, the computing device having a hardware-implemented elliptic curve function, the method comprising: generating a parent public key using the hardware-implemented elliptic curve function of the computing device, a parent private key, and a first number registered in a memory of the computing device;subsequently to said generating the parent public key, resetting the memory of the computing device to the first number; and subsequently to said resetting the memory of the computing device to the first number; generating a child public key using the hardware-implemented elliptic curve function of the computing device, a child private key, and the first number registered in the memory of the computing device.

[0008] Further in accordance with the first aspect of the present disclosure, the hardware- implemented elliptic curve function can for example involve one of: elliptic curve point addition (ECPA), elliptic curve point doubling (ECPD), and elliptic curve point multiplication (ECPM).

[0009] Still further in accordance with the first aspect of the present disclosure, the hardware-implemented elliptic curve function can for example be a SECP256K1 elliptic curve function.

[0010] Still further in accordance with the first aspect of the present disclosure, subsequently to said generating the child public key, resetting the memory of the computing device to the first number.

[0011] Still further in accordance with the first aspect of the present disclosure, the child private key can for example be a first child private key and the child public key can for example be a second child public key, the method can for example further comprise generating a second child public key using the hardware-implemented elliptic curve function of the computing device, a second child private key, and the first number registered in the memory of the computing device.

[0012] Still further in accordance with the first aspect of the present disclosure, the parent public key can for example be a first parent public key and the parent private key can for example be a first parent private key, the method can for example further comprise: generating a second parent public key using the hardware-implemented elliptic curve function of the computing device, a second parent private key, and the first number registered in the memory of the computing device.

[0013] Still further in accordance with the first aspect of the present disclosure, the computing device can for example include a Field Programmable Gate Array (FPGA) device.

[0014] Still further in accordance with the first aspect of the present disclosure, the computing device can for example include a microcontroller.

[0015] Still further in accordance with the first aspect of the present disclosure, the master private key can for example include X number of bits, and the master public key can for example include X / 2 number of bits.

[0016] Still further in accordance with the first aspect of the present disclosure, the X number of bits can for example be 512.

[0017] In accordance with a second aspect of the present disclosure, there is provided a hardware wallet apparatus comprising: a housing enclosing a cavity; at least one printed circuit board located in the cavity; a parent key generator having a computing device mounted to the at least one printed circuit board, the computing device having a hardware-implemented elliptic curve function, and a first number registered in a memory of the computing device, the computing device operable to generate, using the hardware-implemented elliptic curve function, a parent public key based on a parent private key and on the first number; a resetter operable to reset the computing device to the first number; and a child key generator having the computing device operable to generate, using the hardware-implemented elliptic curve function, a child public key based on a child private key and the first number.

[0018] Further in accordance with the second aspect of the present disclosure, the hardware-implemented elliptic curve function can for example involve one of: elliptic curve point addition (ECPA), elliptic curve point doubling (ECPD), and elliptic curve point multiplication (ECPM).

[0019] Still further in accordance with the second aspect of the present disclosure, the hardware-implemented elliptic curve function can for example be a SECP256K1 elliptic curve function.

[0020] Still further in accordance with the second aspect of the present disclosure, subsequently to said generating the child public key, resetting the memory of the computing device to the first number.

[0021] Still further in accordance with the second aspect of the present disclosure, the child private key can for example be a first child private key and the child public key can for example be a second child public key, the method can for example further comprise a second child public key using the hardware-implemented elliptic curve function of the computing device, a second child private key, and the first number registered in the memory of the computing device.

[0022] Still further in accordance with the second aspect of the present disclosure, the parent public key can for example be a first parent public key and the parent private key can for example be a first parent private key, the method can for example further comprise: generating a second parent public key using the hardware-implemented elliptic curve function of the computing device, a second parent private key, and the first number registered in the memory of the computing device.

[0023] Still further in accordance with the second aspect of the present disclosure, the computing device can for example include a Field Programmable Gate Array (FPGA) device.

[0024] Still further in accordance with the second aspect of the present disclosure, the computing device can for example include a microcontroller.

[0025] Still further in accordance with the second aspect of the present disclosure, the master private key can for example include X number of bits, and the master public key can for example include X / 2 number of bits.

[0026] Still further in accordance with the second aspect of the present disclosure, the X number of bits can for example be 512.

[0027] In accordance with a third aspect of the present disclosure, there is provided a hardware wallet apparatus comprising: a parent key generator having a first hardware computing device generating, with a first given number registered in a memory thereof, a parent private key and a parent chain code based on a random number; and a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating, with a second given number registered in a memory of the second hardware computing device, a parent public key based on the parentprivate key; and a child key generator having a parent-dependent number generation device generating a parent-dependent number based on the parent private key and on the parent public key; the first hardware computing device communicatively coupled to the parentdependent number generation device, the first hardware computing device generating, with the memory of the first hardware computing device reset to the first given number, a child private key and a child chain code based on the parent-dependent number and on the parent chain code; and the second hardware computing device generating, with the memory of the second hardware computing device reset to the second given number, a child public key based on the child private key.

[0028] Further in accordance with the third aspect of the present disclosure, the hardware wallet apparatus can for example further comprise a random number generation device communicatively coupled to the first hardware computing device, the random number generate device generating the random number.

[0029] Still further in accordance with the third aspect of the present disclosure, the random number generation device can for example be a quantum random number generation device.

[0030] Still further in accordance with the third aspect of the present disclosure, the parentdependent number can for example be a first parent-dependent number, the parentdependent number generation device generating a second parent-dependent number based on the child private key and on the child public key.

[0031] Still further in accordance with the third aspect of the present disclosure, the first hardware computing device can for example generate, with the memory of the first hardware computing device reset to the first given number, a second child private key and a second child chain code based on the second parent-dependent number and on the child chain code.

[0032] Still further in accordance with the third aspect of the present disclosure, the second hardware computing device can for example generate, with the memory of the second hardware computing device reset to the second given number, a second child public key based on the second child private key.

[0033] Still further in accordance with the third aspect of the present disclosure, the random number can for example be a first random number, the first hardware computing device can for example generate, with the first given number registered in the memory thereof, a second parent private key and a second parent chain code based on a second random number different from the first random number.

[0034] Still further in accordance with the third aspect of the present disclosure, the second hardware computing device can for example generate, with the second given number registered in the memory thereof, a second parent public key based on the second parent private key.

[0035] Still further in accordance with the third aspect of the present disclosure, at least one of the first hardware computing device and the second hardware computing device can for example be a Field Programmable Gate Array (FPGA) device.

[0036] Still further in accordance with the third aspect of the present disclosure, at least one of the first hardware computing device and the second hardware computing device can for example be a microcontroller.

[0037] In accordance with a fourth aspect of the present disclosure, there is provided a method for generating cryptographic keys using a hierarchical deterministic hardware wallet, the method comprising: a first hardware computing device generating, with a first given number registered in a memory thereof, a parent private key and a parent chain code based on a random number; a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating, with a second given number registered in a memory of the second hardware computing device, a parent public key based on the parent private key; generating a parent-dependent number based on the parent private key and on the parent public key; resetting the memory of the first hardware computing device to the first given number and resetting the memory of the second hardware computing device to the second given number; the first hardware computing device generating a child private key and a child chain code based on the parent-dependent number and on the parent chain code; and the second hardware computing device generating a child public key based on the child private key.

[0038] Further in accordance with the fourth aspect of the present disclosure, the parentdependent number can for example be a first parent-dependent number, the method can for example further comprise generating a second parent-dependent number based on the child private key and on the child public key.

[0039] Still further in accordance with the fourth aspect of the present disclosure, the method can for example further comprise: repeating said resetting; the first hardware computing device can for example generate a second child private key and a second child chain code based on the second parent-dependent number and on the child chain code; and the second hardware computing device generating a second child public key based on the second child private key.

[0040] Still further in accordance with the fourth aspect of the present disclosure, the random number can for example be a first random number, the method can for example further comprise: repeating said resetting, the first hardware computing device can for example generate a second parent private key and a second parent chain code based on a second random number different from the first random number; and the second hardware computing device generating a second parent public key based on the second parent private key.

[0041] In accordance with a fifth aspect of the present disclosure, there is provided a hardware wallet apparatus comprising: a first hardware computing device generating a parent private key and a parent chain code based on a random number; and a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating, with a given number registered in a memory of the second hardware computing device, a parent public key based on the parent private key; a parent-dependent number generation device generating a parent-dependent number based on the parent private key and on the parent public key; a third hardware computing device communicatively coupled to the parent-dependent number generation device, the third hardware computing device generating a child private key and a child chain code based on the parent-dependent number and on the parent chain code; and the second hardware computing device generating, with the memory of the second hardware computing device reset to the given number, a child public key based on the child private key.

[0042] Further in accordance with the fifth aspect of the present disclosure, the first hardware computing device and the third hardware computing device can for example correspond to a same hardware computing device.

[0043] In accordance with a sixth aspect of the present disclosure, there is provided a hardware wallet apparatus comprising: a first hardware computing device generating, with a first given number registered in a memory thereof, a parent private key and a parent chain code based on a random number; and a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating a parent public key based on the parent private key; and a parent-dependent number generation device generating a parent-dependent number based on the parent private key and on the parent public key; the first hardware computing device communicatively coupled to the parent-dependent number generation device, the first hardware computing device generating, with the memory of the first hardware computing device reset to the first given number, a child private key and a child chain code based on the parent-dependent number and on the parent chain code; and a third hardware computing device generating a child public key based on the child private key.

[0044] Further in accordance with the sixth aspect of the present disclosure, the second hardware computing device and the third hardware computing device can for example correspond to a same hardware computing device.

[0045] In this disclosure, the term “hardware-implemented” refers to a network of transistors in a chip implementing a function. The function can be set either at fabrication (at the chip factory), or by hardcoding (post fabrication, using hardware and / or software tools), so as to automatically produce a given set of outputs associated to the function based on a given set of inputs, and that occurrences of the function can be repeated based on the same configuration of transistors implementing the function.

[0046] All technical implementation details and advantages described with respect to a particular aspect of the present invention are self-evidently mutatis mutandis applicable for all other aspects of the present invention.

[0047] Many further features and combinations thereof concerning the present improvements will appear to those skilled in the art following a reading of the instant disclosure.DESCRIPTION OF THE FIGURES

[0048] In the figures,

[0049] Fig. 1 is a schematic view of an example of a “cold” blockchain wallet configuration, in accordance with one or more embodiments;

[0050] Fig. 2 is a schematic view of a first example of a hierarchically deterministic hardware wallet apparatus, shown with a parent key generator and a child key generator each using a hardware-implemented elliptic curve function, in accordance with one or more embodiments;

[0051] Fig. 3 is a schematic view of a second example of a hierarchically deterministic hardware wallet apparatus, shown with a parent key generator and a child key generator each including first and second hardware computing devices, in accordance with one or more embodiments;

[0052] Fig. 4A is a schematic view of an example of a parent key generator including a quantum random number generator, a first hardware computing device and a second hardware computing device, in accordance with one or more embodiments;

[0053] Fig. 4B is a schematic view of an example of a child key generator including a parentdependent number, and the first and second hardware computing devices of Fig. 4A, in accordance with one or more embodiments;

[0054] Fig. 4G is a schematic view of the second hardware computing device of Fig. 4A, in accordance with one or more embodiments;

[0055] Fig. 5 is a schematic view of an example of a hardware wallet apparatus including the parent key generator of Fig. 4A and the child key generator of Fig. 4B, in accordance with one or more embodiments;

[0056] Fig. 6 is a schematic view of an example of a hardware computing device, in accordance with one or more embodiments;

[0057] Fig. 7A is a flow chart of an example of a first method for generating cryptographic keys using a hierarchical deterministic hardware wallet, in accordance with one or more embodiments;

[0058] Fig. 7B is a flow chart of an example of a second method for generating cryptographic keys using a hierarchical deterministic hardware wallet, in accordance with one or more embodiments;

[0059] Fig. 8 is a schematic view of an example cryptocurrency (crypto) physical wallet signing transactions in an offline environment, in accordance with one or more embodiments;

[0060] Fig. 9 is a block diagram showing an example of high-level architecture of a hierarchically deterministic (HD) crypto wallet, in accordance with one or more embodiments;

[0061] Fig. 10 is a schematic view of an example of an HD wallet structure as outlined by Bitcoin improvement proposal (BIP)-32 standards, in accordance with one or more embodiments;

[0062] Fig. 11 is a schematic view of an example of a password-based key derivation function-2 (PBKDF2) using a SHA-512 hash function, in accordance with one or more embodiments;

[0063] Fig. 12 is a graph showing elliptic curve point addition (ECPA) as the addition of two points (P and Q) on an elliptic curve, showing the addition resulting in a point R which is a reflection along the x-axis of the point where a straight line through P and Q intersects with the elliptic curve, in accordance with one or more embodiments;

[0064] Fig. 13 is a graph showing elliptic curve point doubling (ECPD) as the addition of a point P on an elliptic curve with itself, showing the addition resulting in a point R which is a reflection along the x-axis of the point where a straight line tangent to the curve at P intersects with the elliptic curve, in accordance with one or more embodiments;

[0065] Fig. 14 is a schematic view of another example of a HD wallet apparatus, showing a master key generator and a child key generator, in accordance with one or more embodiments;

[0066] Fig. 15 is a schematic view of the master key generator of Fig. 14, in accordance with one or more embodiments;

[0067] Fig. 16 is a schematic view of a hardware architecture embodying the elliptic curve point addition of Fig. 12, showing ECPA for the complete projective point addition on the elliptic curve, in accordance with one or more embodiments;

[0068] Fig. 17 is a schematic view of a hardware architecture embodying elliptic curve point multiplication (ECPM) on an elliptic curve, in accordance with one or more embodiments;

[0069] Fig. 18 is a schematic view of an example hardware architecture for calculating z-1 , which converts projective coordinates to affine coordinates, in accordance with one or more embodiments;

[0070] Fig. 19 is a schematic view of an example of a first hardware computing device, in accordance with one or more embodiments; and

[0071] Fig. 20 is a schematic view of the child key generator of Fig. 14, in accordance with one or more embodiments.DETAILED DESCRIPTION

[0072] Fig. 1 shows an example of a “cold” blockchain wallet embodiment. In the example presented in Fig. 1 , keys 112 are stored in an electronic device 120 which may be physically distinct from the computer 18 used by the user to perform a blockchain transaction. The electronic device 120 hosting the “cold wallet” 110 may be devoid of any communication feature other than a wired connectivity to the computer 18 used by the user to perform a blockchain transaction, and may therefore be entirely partitioned from the Internet 16 when the wired connection is physically disconnected. The electronic device 120 may have a housing 121 enclosing a cavity 123, one or more printed circuit board(S) 125 located within the cavity 123 and a hardware wallet apparatus 127 mounted to the printed circuit board(s) 125. The hardware wallet apparatus 127 can have some integrated computer functionality, such as an application allowing to generate, store and retrieve keys in response to a user request, and optionally rely more or less on processes running on the computer 18 used by the user to perform a blockchain transaction (e.g., an authentication process).

[0073] Fig. 2 shows an example of the hardware wallet apparatus 127 of the electronic device 120, in accordance with an embodiment. In some embodiments, the computing device is provided in the form of a Field Programmable Gate Array (FPGA) device. In certain embodiments, the computing device is provided in the form of a microcontroller. As shown, the hardware wallet apparatus 127 has a parent key generator 102, a child key generator 104, and a resetter 103. The hardware wallet apparatus 127 has a hardware-implemented elliptic curve function 129. In some embodiments, the hardware-implemented elliptic curve function 129 can involve an elliptic curve point addition (ECPA), an elliptic curve point doubling (ECPD), and / or an elliptic curve point multiplication (ECPM). For instance, in some embodiments, the hardware-implemented elliptic curve function is a SECP256K1 elliptic curve function. During use, the parent key generator 102 is operable to generate, using the hardware-implemented elliptic curve function 129, a parent public key based on a parent private key and on a first number registered in a memory 131 of the computing device. The hardware wallet apparatus 127 also has a resetter 103 which is operable to reset the memory 131 of the hardware wallet apparatus 127 to the first number. Once the memory 131 of the hardware wallet apparatus 127 has been reset to the first number, the child key generator 104 is operable to generate, using the hardware-implemented elliptic curve function 129, a child public key based on the based on a child public key and on the first number.

[0074] Fig. 3 shows an example of a hardware wallet apparatus 200, in accordance with a detailed embodiment. As depicted, the hardware wallet apparatus 200 has a parent key generator 202 and a child key generator 204 sharing at least some hardware computing device(s). In this embodiment, the parent key generator 202 has a first hardware computing device 206 generating, with a first given number registered in a memory thereof, a parent private key and a parent chain code based on a random number. This generation can involve a hashing function (e.g., HMAC SHA 512 hash function) embedded into the first hardware computing device 206. The first hardware computing device 206 can be a field-programmable gate array (FPGA), a microcontroller, or an equivalent and / or combination thereof. The random number can be generated by a random number generator 205. In some embodiments, true random numbers may be generated by quantum mechanical means, sometimes referred to as Quantum Random Number Generator (QRNGs), which offer a more secure alternative. In recent years, technologies have been developed allowing to generate truly random numbersfrom a quantum source at a relatively high throughput, such as via the use of a quantum tunnelling barrier and deterministic noise removal, for instance. In other embodiments, the random number generator can involve the use of pseudo-random algorithms. The parent key generator also has a second hardware computing device 208 which is communicatively coupled to the first hardware computing device 206. Such a communicative coupling can be a wired coupling, a wireless coupling or a combination thereof. Typically, as the first and second hardware computing devices 206 and 208 are on-chip components, the coupling is wired through a printed-circuit board, for instance. As illustrated, the second hardware computing device 208 generates, with a second given number registered in a memory of the second hardware computing device 208, a parent public key based on the parent private key. This latter generation can involve the use of an elliptic curve function (e.g., SECP256K1 elliptic curve function).

[0075] The child key generator 204 is communicatively coupled to the parent key generator 202. More specifically, the child key generator 204 has a parent-dependent number generator 210 generating a parent-dependent number based on the parent private key and on the parent public key. In some embodiments, the parent-dependent number will depend on the parent private key. In some other embodiments, the parent-dependent number will depend on the parent public key. In certain embodiments, the parent-dependent number will factor in the depth of the child keys being generator (e.g., depth 1 - child, depth 2 - grandchild, and so forth). It is noted that the parent-dependent number is generated based on hierarchically deterministic purposes, so that with the same initial random number, parent keys, and depth, the same child keys are generated. The child key generator 204 includes the first hardware computing device 206 of the parent key generator 202. The first hardware computing device 206 is communicatively coupled to the parent-dependent number generation device 210. As shown, the first hardware computing device 206 generates, with the memory of the first hardware computing device 206 reset to the first given number, a child private key and a child chain code based on the parent-dependent number and on the parent chain code. It is intended that the first hardware computing device 206 performs the same hashing function as described above with respect to the parent key generator 202. Moreover, the child key generator 204 includes the second hardware computing device 208 of the parent key generator 202. The second hardware computing device 208 generates, with the memory ofthe second hardware computing device 208 reset to the second given number, a child public key based on the child private key. Again, the second hardware computing device 208 performs the same elliptic curve function as described above with respect to the parent key generator 202. It is understood that since the first and second hardware computing devices 206 and 208 are used in a parent key generation scheme, reset to corresponding default memory states, and then re-used in a child key generation scheme, then the resulting hardware wallet apparatus 200 can achieve considerable costs, circuit depth and footprint savings, which can be highly desirable.

[0076] In some embodiments, the parent-dependent number is a first parent-dependent number. In these embodiments, the parent-dependent number generation device 210 can generate a second parent-dependent number based on the child private key and on the child public key. In this way, the first hardware computing device 206 can generate, with the memory of the first hardware computing device 206 reset to the first given number, a second child private key and a second child chain code based on the second parent-dependent number and on the child chain code. Furthermore, the second hardware computing device 208 can generate, with the memory of the second hardware computing device 208 reset to the second given number, a second child public key based on the second child private key. Such a child key generation scheme can be repeated on demand to generate new child keys of a further depth.

[0077] In some embodiments, new parent keys (also referred to as master keys) can be generated. In these embodiments, the first hardware computing device 206 can generate, with the first given number registered in the memory thereof, a second parent private key and a second parent chain code based on a second random number different from the first, original random number. In certain embodiments, the second hardware computing device 208 can generate, with the second given number registered in the memory thereof, a second parent public key based on the second parent private key.

[0078] Fig. 4A shows an example parent key generator 302 made in accordance with BIP- 32. As shown, the parent key generator 302 has a quantum random number generator 305, a first hardware computing device 306 receiving a 256-bit random number from the quantum random number generator 305 and generating a 512-bit parent private key (256 bits) andparent chain code (256 bits). A second hardware computing device 308 receives the master private key from the first hardware computing device 306 and generates a master public key (also 256 bits).

[0079] Fig. 4B shows an example child key generator 304, in accordance with an embodiment. As depicted, the child key generator 304 shares the first and second hardware computing devices 306 and 308 of the parent key generator 302. More specifically, the first hardware device 306 receives either the parent private key or the parent public key via a first multiplexer 312. The first multiplexer 312 decides whether the parent private key or the parent public key is inputted into the first hardware computing device 306. When the parent private key is used, hardened keys may be generated. When the parent public key is used, normal keys may be generated. This decision can be based on the number of child index generation, and can influence the resulting security, for instance. This can be alluded to in Fig. 4C. The parent-dependent number generator 310 inputs a parent-dependent number (32 bits) into the first hardware computing device 308. As such, the first hardware computing device generates, with the memory of the first hardware computing device reset to the first given number, a child private key and a child chain code based on the parent-dependent number and on the parent chain code. The second hardware computing device (not shown in Fig. 4B) can then generate, when its the memory has been reset to the second given number, a child public key based on the child private key. Fig. 5 shows an example of an HD wallet apparatus incorporating the parent key generator of Fig. 4A and the child key generator of Fig. 4B. Fig. 5 not only illustrates the reuses of both the first and second hardware computing devices 306 and 308 in the parent and first child key generation schemes, but also the reuses of both the first and second hardware computing devices 306 and 308 in grandchild key generation schemes. It is understood that the multiplexers 312, 312a and 312b shown in Fig. 5 can be controlled by a controller 313 in communicative coupling therewith. The parent-dependent number generation device 310 includes a comparator 314 which compares an index of the child key generation scheme to a given reference number (e.g., 2A(31 -1)) to decide whether the parent private key or the parent public key is used as input of the first hardware computing device 306 used in the child key generation scheme. A concatenator 316 is also used to concatenate the parent private key or the parent public key to the parent-dependent number (e.g., the index or depth).

[0080] The first and second hardware computing devices can be provided in the form of FPGAs, microcontrollers, or a combination thereof. The hardware computing devices can be implemented in the form of a computing device 600, an example of which is described with reference to Fig. 6. The computing device 600 can have a processor 602, a memory 604, and I / O interface 606. Instructions 608 for generating cryptographic keys using a HD hardware wallet can be stored on the memory 904 and accessible by the processor 602.

[0081] The processor 602 can be, for example, a general-purpose microprocessor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field- programmable gate array (FPGA), a reconfigurable processor, a programmable read-only memory (PROM), a programmable logic controller (PLC), or any combination thereof.

[0082] The memory 604 can include a suitable combination of any type of computer- readable memory that is located either internally or externally such as, for example, randomaccess memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable readonly memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM) or the like.

[0083] Each I / O interface 606 enables the computing device 600 to interconnect with one or more input devices or with one or more output devices.

[0084] Each I / O interface 606 enables the controller to communicate with other components, to exchange data with other components, to access and connect to network resources, to server applications, and perform other computing applications by connecting to a network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fibre optics, satellite, mobile, wireless (e.g., Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, and others, including any combination of these.

[0085] The computing device 600 and any software application that can be run by the computing device 600 are meant to be examples only. Other suitable embodiments of the controller can also be provided, as it will be apparent to the skilled reader.

[0086] Fig. 7 shows an example of a first method 700 for generating cryptographic keys using a hierarchical deterministic (HD) hardware wallet. As depicted, the HD hardware wallet can be similar or identical to the ones described above with reference to Figs. 1-5. As described above, the method 700 is performed using a hardware wallet apparatus having a housing enclosing a cavity and at least one printed circuit board located in the cavity, and a computing device mounted to the at least one printed circuit board. The computing device has a hardware-implemented elliptic curve function such as a SECP256K1 elliptic curve function, for instance.

[0087] At step 702, a parent public key is generated using the hardware-implemented elliptic curve function of the computing device, a parent private key, and a first number registered in a memory of the computing device.

[0088] At step 704, subsequently to said step 702 of generating, the memory of the computing device is reset to the first number.

[0089] At step 706, subsequently to said step 704 of resetting, a child public key is generated using the hardware-implemented elliptic curve function of the computing device, a child private key, and the first number registered in the memory of the computing device.

[0090] In some embodiments, the hardware-implemented lliptic curve function involves one of: elliptic curve point addition (ECPA), elliptic curve point doubling (ECPD), and elliptic curve point multiplication (ECPM). In some embodiments, the hardware-implemented elliptic curve function is a SECP256K1 elliptic curve function.

[0091] Depending on the embodiment, the step 706 can be performed prior to the generation of another parent key or prior to the generation of another child key. For instance, after the steps 704 and / or 706 the memory of the computing device can be reset to the first number. In some embodiments, the method 700 includes a further step of generating another second child public key using the hardware-implemented elliptic curve function of thecomputing device, a corresponding child private key, and the first number registered in the memory of the computing device. In some other embodiments, the method can for example include a step of generating another parent public key using the hardware-implemented elliptic curve function of the computing device, a corresponding parent private key, and the first number registered in the memory of the computing device. In certain embodiments, the master private key includes X number of bits, and the master public key includes X / 2 number of bits.10. Depending on the embodiment, the X number of bits can be 512 in some embodiments.

[0092] Fig. 8 shows an example of a second method 800 for generating cryptographic keys using a hierarchical deterministic (HD) hardware wallet. As depicted, the HD hardware wallet can be similar or identical to the ones described above with reference to Figs. 1-5.

[0093] At step 802, a first hardware computing device generates a parent private key and a parent chain code based on a random number. The step 802 is performed while a memory of the first hardware computing device registers a first given number. The first given number can equivalently correspond to a first given memory state of the memory of the first hardware computing device, depending on the embodiment. The random number can be generated by a random number generator. Examples of such random number generators can include, but are not limited to, quantum random number generators, pseudo-random number generators, and the like.

[0094] At step 804, a second hardware computing device generates a parent public key based on the parent private key. It is intended that the second hardware computing device is communicatively coupled, via wired communication, wireless communication or a combination thereof, to the first hardware computing device. The step 804 is performed while a memory of the second hardware computing device registers a second given number. In some embodiments, the second given number is different from the first given number. However, in some other embodiments, the first and second given numbers can correspond to a common given number. The second given number can equivalently correspond to a second given memory state of the memory of the second hardware computing device.

[0095] At step 806, a parent-dependent number is generated based on the parent private key and on the parent public key. The parent-dependent number can correspond to either the parent private key or the parent public key, or derivations thereof. In some embodiments, the parent-dependent number can factor in also a depth of the child keys to be generated (e.g., child keys, grandchild key, great-grandchild keys, and so forth).

[0096] At step 808, the memory of the first hardware computing device and the memory of the second hardware computing device are reset to their original (and / or former) memory states. For instance, the memory of the first hardware computing device is reset to the first given number, and the memory of the second hardware computing device is reset to the second given number.

[0097] At step 810, the first hardware computing device generates a child private key and a child chain code based on the parent-dependent number and on the parent chain code. This step involves the reutilization of the first hardware computing device in the generation of a further private key.

[0098] At step 812; the second hardware computing device generates a child public key based on the child private key. This step involves the reutilization of the second hardware computing device in the generation of a further public key.

[0099] It is intended that the method 800 can be performed a first time to generate first master private and public keys, and first child private and public keys. However, steps 806 through 812 can be performed another time to generate first grandchild private and public keys, and so forth. Alternately or additionally, the method 800 can be performed a second time to generate second master private and public keys, and second child private and public keys, and so forth, if necessary, so that Xth master private and public keys, and corresponding Xth child private and public keys. In this latter iteration of the method 800, the private and public keys are based on a different random number. During all those full or partial iterations of the method 800, the first and second hardware computing devices are reset and re-used, thereby reducing the overall cost, circuit depth and footprint, for an arguably insignificant latency reduction.

[0100] Example - Ethereum Cold Wallet: Hardware Architecture and Implementation

[0101] Cryptocurrency blockchain networks safeguard digital assets using cryptographic keys, and cryptographic wallets play a critical role in generating, storing, and managing these keys. The diverse flavors of the wallets, generally categorized as hot and cold, offer varying degrees of security and user convenience. Nevertheless, these wallets are software running on microcontroller units. Software applications comprise potential security vulnerabilities, such as being susceptible to malware attacks, that could be averted by utilizing hardware. This example proposes a hardware architecture for an Ethereum hierarchically deterministic cold cryptocurrency wallet. In doing so, we also propose hardware architectures of algorithms that are key to an Ethereum wallet. Notable algorithms include the elliptic curve point addition algorithm, the Montgomery ladder algorithm, the binary inversion algorithm, the HMACSHA- 512 hash function, the child key derivation function, the password-based key derivation function-2, and the Ethereum checksum algorithm. Also, this example presents and discusses implementation results for an FPGA, illustrating the feasibility of the approach. We show that the algorithms of the proposed Ethereum hardware wallet exhibit an area reduction of at least 23% and a 44.1 % increase in operation frequency compared to the existing literature. Conversely, latency and throughput degrade. Despite the trade-offs in latency and throughput, the proposed wallet’s throughput is sufficient to facilitate transactions on the current Ethereum blockchain. Moreover, the wallet consumes under 20% of available resources on a Xilinx Zynq Ultrascale MPSoC. We also hope that this example can serve as a blueprint for future cryptocurrency wallet development in hardware.

[0102] Cryptographic keys play a vital role in securing user assets within the blockchain ecosystem. They provide a robust layer of security by enabling authentication, identity verification, and data integrity. Moreover, cryptographic keys facilitate safe user interaction within the network, limiting the access and modification of sensitive data to authorized users only. Blockchain networks, such as Ethereum and Bitcoin, extensively use public-private cryptographic keys to protect user assets. Furthermore, while anyone can access public keys, the secrecy of private keys is paramount since they are used to prove ownership, notably giving the owner access to all the crypto. Accordingly, a compromised private key can lead toextensive losses where an attacker will virtually own all of the crypto assets in the associated account.

[0103] Blockchain users utilize crypto wallets to store and track the keys securely, crypto wallets are devices or programs that generate, store, and manage public and private cryptographic keys, crypto wallets can either be hot or cold. Hot wallets are online, and users utilize them to sign transactions, buy and sell crypto assets, as well as generate and store cryptographic keys. Some notable examples of hot wallet applications include MetaMask, Coinbase, and Edge. On the other hand, cold crypto wallets generate, store, and manage keys offline. Also, the wallets do not directly interact with the user’s requests to sign transactions; instead, they exchange keys with hot wallets, which in turn interact with the user’s requests. Consequently, cold wallets are considered the safest type of crypto wallets. Fig. 8 shows a common cold physical crypto wallet. This figure illustrates that the wallet communicates with a hot wallet during utilization. Some common physical crypto wallets and brands include Trezor T by Satoshi Labs, Ledger Nano S by Ledger, and KeepKey by ShapeShift.

[0104] The crypto wallets discussed above can either be nd or hd. The former type generates one pair of corresponding private and public keys, while the latter uses one master key to generate almost infinite public and private keys, hd wallets are currently the most popular type in the market due to their better key management property.

[0105] As previously discussed, crypto keys, stored in crypto wallets, are vital in securing user assets on the blockchain network. Consequently, the ability of crypto wallets to securely generate, store, and manage crypto keys is equally crucial. Several techniques in the literature propose different methods of enhancing the security of crypto wallets. For instance, CryptoVault is a platform that generates and maintains keys inside an Intel software guard extension (SGX) enclave, allowing users to utilize private keys in a process highly isolated from other processes executing in the same environment. Additionally, CryptoVault presents a secure approach for storing and retrieving a backup key from an external repository. Likewise, the secure blockchain lightweight wallet based on TrustZone (SBLWT) is also a crypto wallet that utilizes isolation to safeguard private keys. The wallet is designed to secure simplified payment verifications (SPV) used in mobile devices that store partial blockchainsdue to resource constraints. Also, various crypto wallets in the industry, such as Ellipal Titan and COLDCARD, claim to utilize isolation (air-gap) technology to secure the keys. On the other hand, the hot-cold hybrid decentralized exchange (HCHDEX) method involves locally storing crypto wallet data on personal devices. It enables direct transactions between two devices without dependence on a central server system. Furthermore, the HCHDEX method employs a secure two-way authentication technique, utilizing robust handshaking between e- wallets and lightweight distributed ledger technology (DLT) nodes.

[0106] It is worth noting that conventional crypto wallets are software implementations running off mcu. This observation is also true for various market-leading crypto wallets. For instance, COLDCARD, Ledger Nano X, and Trezor Model T use an STM32 mcu. Therefore, the risk of malware attacks is often persistent. Furthermore, the literature has reported various security breaches in some commercially available crypto wallets. For example, a sea extracted private keys from Ledger Nano S, Keepkey, and Trezor crypto wallets. Also, sea successfully attacked the STM32 mcu. Moreover, an adversarial attack was modeled to extract private keys from an isolated (air-gapped) wallet within seconds by infecting it with malicious code. Hence, a hardware architecture-based crypto wallet may provide added benefits that could improve the security of crypto wallets.

[0107] This example proposes the first complete hardware architecture and a fpga implementation of an Ethereum hd cold wallet. In doing so, we propose hardware architectures of key algorithms utilized in an Ethereum wallet. Most notably, those of:

[0108] • The ECPA using complete addition formulas.

[0109] • The Montgomery ladder algorithm using the ECPA and the ECPD to performECPM.

[0110] • The bia used to convert projective to affine coordinates.

[0111] • The hmac-sha-512.

[0112] • The ckd function utilized by the hd wallet to generate child keys.

[0113] • The Ethereum checksum algorithm used to compute the Ethereum checksumed address.

[0114] • The pbkdf used to generate mnemonics in hd wallets.

[0115] The security of an fpga architecture could be argued through its immutability property. Immutability refers to the difficulty of changing the core functionality of an implementation, fpga devices are designed to function on a physical level, where configurations are essentially embedded into the hardware, resembling a hard-wired setup. This makes it very challenging for an attacker to alter the configuration of an fpga implementation in a structured and predictable manner. However, while fpga implementations are not as immutable as asic, they still exhibit a higher degree of immutability compared software.

[0116] Therefore, despite hardware and software being vulnerable to various attacks such as the sea, hardware is intrinsically more accessible to protect against. This is because the designer controls each bit and clock cycle, which is often critical when modeling high-level security devices resistant to attacks such as sea. Also, while hardware is not impervious to all attacks, it may provide robust countermeasures against specific vulnerabilities, such as malware attacks, that can otherwise be detrimental to software solutions.

[0117] This section describes the mechanism of an Ethereum hd wallet and the key algorithms utilized to help the reader understand how the Ethereum hd wallet works. Furthermore, we discuss the role of each algorithm in the wallet. Table 1 shows the notation used in this example.

[0118] Table 1 : Notation00119] This subsection highlights the functionality and structural arrangement of an Ethereum hd crypto wallet. The Ethereum hd crypto wallet can be described by four primary processes. These are: the random number generation process using a rng, the mnemonic generation process, also called bip-39 standard, the child key derivation process, which consists of bip-32 and bip-44 standards, and the address generation process using the Keccak hash function. A hash function is a cryptographic algorithm that converts an input of any size into an irreversible alphanumeric random number of a given size, known as a hash digest.

[0120] As shown in Fig. 9, in an Ethereum hd crypto wallet, an rng is first used as a source of entropy to generate a random N which will be used to create the master key. An rng with a very high source of entropy is desired to generate N. This corresponds to a more secure master key. Secondly, the bip-39 protocol uses the random number N to generate random mnemonic phrases as well as a 512-bit seed number, bip-39 uses the pbkdf, which is a function based on hmacsha-512 and sha-256 hash algorithms. As defined in bip-39, the mnemonic phrases are 12 or 24 random words used for backup and recovery of hd wallet keys and addresses. Thirdly, the hmacsha-512 function is used to generate the master key. Moreover, in accordance with the bip-32 and bip-44 standards, the ckd function, based on the hmacsha-512 and SECP256K1 algorithms, use the master key to generate the child private and public keys. Finally, the address-generation process uses the Keccak hash function to generate the check-marked Ethereum addresses.

[0121] The bip-32 standard is the backbone of all hd wallets. It defines a structure to generate child private and public keys using a single master key in a deterministic manner. Fig. 10 depicts the structure of bip-32 (hd wallet). In the figure, hmacsha-512 (denoted by a) uses a random number N at depth zero of the hierarchical tree to generate the master key m.Moreover, a ckd function is used to generate the other nodes of the hierarchical tree from depth one to three. The nodes at depth three are blockchain addresses. On the other hand, bip-44 is an application of the bip-32 standard. It defines a path containing a series of constants and variables that are sequentially executed in bip-32. The path consists of six levels that are unique to different cryp, hence allowing bip-44 to be used by different crypto.The six levels of the bip-44 path are master private key andaddressindexis a 32-bit long variable that defines the index of the key generated by the wallet. The remaining levels are 32-bit constants that are unique to different crypto. For example, m o'Ethereum uses -2- . The apostrophe on some of the path’s constants indicates that addressindex the bip-32 hardened derivation method is used in the ckd function. Hardened and nonhardened key derivation techniques are methods used in bip-32 to allow users the flexibility of various trade-offs, including security, backup and recovery, and transaction convenience. This method defines numbers > 231as hardened and those < 231as non-hardened or normal. Fig. 10 also shows that the path discussed above can be used to locate a specific address on the blockchain network. The next subsections discuss key algorithms utilized in the Ethereum wallet.

[0122] The pbkdf is a widely utilized cryptographic hash algorithm for generating secure keys given a password. The algorithm takes a user-defined password and other variables to generate a unique key dkoutas follows:

[0123] dkout= PBKDF2pRFPwd,Slt, c, dkLen), (1)

[0124] where Pwd is the user-defined password, Sit is a salt variable used to further strengthen the security of the key, PRF is the preferred cryptographic hash function such as sha-256 or sha-512, c is the number of iterations, and dkLenis the desired size of the output. Fig. 11 illustrates how to compute pbkdf. In the figure, i is the resulting quotient after dividing the desired size of output dkLenby the output size of PRF. Hence, in the case where PRF is sha-512 and the desired output size is 512, j=1. Sit is concatenated with i and used as theinput to the first instance of hmacsha-512. From the second instance to instance c - 1, the previous hmacsha-512 digest is used as the input to the current instance. The algorithm uses Pwd as the second input to all the hmacsha-512 computations. Moreover, it calculates the exclusive OR (®) of the output of each hmacsha-512 digest and concatenates the output of each i operation to get dkout. bip-39 uses pbkdf with c = 2048 to compute the seed used in the hd wallet.

[0125] SECP256K1 is a particular ec among the diverse variants used in ecc. These variants include the Weierstrass, Edwards, Hessian, and Koblitz curves. Moreover, ecc is a form of public key cryptography based on an ec over a finite gf. There are two main types of finite fields commonly used in ecc: prime fields are denoted by, where p is a large prime number and binary extension fields, denoted by GF(F2™), where 2mis the number of elements in the field and m is a positive integer. The ec is defined by the cubic equation:

[0126] y2+ xy = x3+ ax + b, (2)

[0127] where x and y are coordinates on the ec, and a and b are constants that define the curve. After a linear change of variables, (2) is transformed into (3), expressed in standard short Weierstrass form. It returns a public key solution comprising (x,y) for variables a, b

[0128] y = x3+ ax + b. (3)

[0129] ECPA and ECPD are arithmetic operations used to compute public keys on the ec. ECPA defines adding two points on the curve, as shown in Fig. 12. Given points P = (x0,y0) and Q = (%i,yi) on the ec, ECPA comprises two processes. First, draw a straight line through points P and Q. The line intersects with the curve at point — R = (,x2,y2)- Second, reflect the point — R by the x-axis to obtain the results of the ECPA as shown in (4):

[0130] R = P + Q. (4)

[0131] Conversely, ECPD defines adding a point on the ec with itself, as shown in Fig. 13. Given point P = (x0,y0) on the curve, ECPD also comprises two steps. First, draw a tangential line to the curve at point P. The line intersects with the curve at the point — R = (x^y- . Second, reflect the point — R by the x-axis to obtain the results of the ECPD as shown in (5):

[0132] R = 2P. (5)

[0133] ECPA and ECPD are used to compute the scalar ECPM on the ec. Scalar ECPM is an integral ecc operation as it is the primary process used to calculate the public key. Scalar ECPM has the form k • P. It is the sum of k copies of P, such that:

[0134] R = / c - P = ^=1P, (6)

[0135] where k is a positive integer, and R and P is a points on the curve. This example will use the Montgomery Ladder algorithm to compute ECPM. The following provides further explanations of the Montgomery Ladder algorithm.

[0136] The Koblitz Curve ecc variant over GF(FP), known as seep, is an ec whose a and b parameters of (3) are 0 and 7, respectively. Moreover, other parameters such as the generator P in (6) are specified. SECP256K1 is the core algorithm used by the Ethereum crypto wallet to generate a public key from a private key.

[0137] The bia computes the multiplicative inverse of elements in an ecc’s finite field. In SECP256K1 , for instance, it converts the projective coordinates back to the affine coordinate system. To understand its significance, we analyze the various arithmetic operations performed in the utilized ecc. SECP256K1 executes modular arithmetic operations, including addition, subtraction, multiplication, and division in an affine coordinate system, i.e., GF(Fp) where Fpe (x,y). However, modular inversion / division is the most expensive in complexity, area, and execution time. Nevertheless, transforming the coordinates from affine to projective reduced the number of modular division operations performed by SECP256K1 (i.e., GF(FP) where Fpe (x,y, z)). Therefore, Algorithm 1 depicts a set of equations used to compute the complete ECPA in the projective coordinate system over prime-order elliptic curves. However, SECP256K1 must perform one final modular division to return the final results to affine coordinates, i.e (x,y,z) => (xz-1, yz-1). SECP256K1 utilizes the bia to compute the modular division. The algorithm is based on the eea which calculates the multiplicative inverse of an integer z e Fpby calculating two variables R and q that satisfy:

[0138] zR + pq = gcd(z, p) = 1, (7)

[0139] where gcd is a function used to calculate the greatest common divisor of two numbers.Al^ii ithm 1 Equations for complete, projective point addition for SECP256K 1. All arithmetic operations performed are modulo[npiil: = i .Y- . Yi . Zi i . QhZ* and 6:S= 3 - 6.Output ( '.:. y:. : j = + Q

[0140]

[0141] The Keccak hash function, like many others, is designed to offer robust security by preventing collision attacks and other vulnerabilities. The core of the Keccak hash function is the sponge construction technique, which operates in two phases: absorbing and squeezing. During the absorbing phase, the input message is divided into blocks, and a permutation function iteratively processes these blocks, integrating the input message into the function’s state. In the squeezing phase, the function extracts the output from its state by repeatedly applying the same permutation function until the desired output size is achieved. This flexible sponge construction enables Keccak to produce digests of varying sizes, making it suitable for a wide range of applications.

[0142] The Keccak family includes four primary hash functions, categorized by the size of their digests: Keccak-224, Keccak-256, Keccak-384, and Keccak-512. In blockchaintechnology, different variants of Keccak are utilized in various system components. For example, Stellar employs Keccak-512 in its consensus protocol, while Ethereum uses Keccak- 256 in its address generation process. Specifically, Ethereum generates an address by hashing the public key with Keccak-256. Additionally, Keccak is used to create a checksummed Ethereum address, ensuring greater security and integrity. In this example, we utilize an open-source Keccak-256 hardware implementation provided by the Keccak group.

[0143] The hmac based on sha-512 (hmacsha-512) is an algorithm proposed by the nist to ensure data integrity and authenticity. The hmacsha-512 takes two inputs called key k and message m and outputs a 512-bit digest as follows:

[0145] where H(-) denotes the sha-512 hash function. Moreover, opad is the outer padding, which is 0x36 repeated 64 times, and ipad is the inner padding, which is 0x5C also repeated 64 times, hmac uses ipad and opad to modify the key and message before applying the hash function to enhance security. This example explains that hmacsha-512 is used to create the master seed and mnemonics in an Ethereum hd wallet, and provides further details on the proposed hardware architecture of the hmacsha-512 algorithm.

[0146] This section discusses the architecture of the proposed Ethereum hd cold wallet. Fig. 14 depicts the general datapath structure of the proposed wallet. The proposed architecture executes all the Ethereum hd wallet processes highlighted above.

[0147] The red data path in Fig. 14 indicates the Ethereum address generation process using the Keccak hash algorithm. The other parts of the figure execute the random number generation process, the mnemonic generation process (bip-39), and the child key derivation process. In the proposed architecture, the ckd function consists of SECP256K1 and hmacsha-512. Moreover, the bip-39 process utilizes the sha-256 hash function and the hmacsha-512 hash function inside the ckd function. Also, the architecture uses an rng in the random number generation process. We envision utilizing a qrng in the proposed architecture. When the hd m purpose' coin^ypewallet executes the path discussed above for multiple keys, the partial path account' is changeexecuted again for each additional key. Therefore, to improve the throughput performance, we store the output of the ckd function after executing the partial path in registers and reuse them when calculating the rest of the keys.

[0148] From the Ethereum hd key derivation process, it is clear that some algorithms are used multiple times in different parts of the derivation process (e.g., hmacsha-512 and SECP256K1). This example proposes a hardware architecture that aims to minimize the size of the wallet by reusing instances of algorithms to perform different functions in the wallet. Also, this example proposes minimum area hardware architectures for the utilized algorithms. The following subsection discusses the proposed hardware architecture of the second process in the Ethereum hd cold wallet paradigm: the mnemonic generation process (bip-39).

[0149] bip-39 uses the random number N generated by the rng to compute mnemonics and a seed value. Fig. 15 shows the proposed hardware architecture for bip-39. The figure shows that bip-39 utilizes sha-256, sha-512, and hmacsha-512 hash algorithms. Moreover, the proposed architecture uses the hmacsha-512 algorithm instance inside the ckd function and the sha-512 instance inside the hmacsha-512 algorithm using control signals j and k.

[0150] The MNG module stores the bip-39 English mnemonics wordlist. Moreover, it uses the random number N and the sha-256 digest (eight-bit checksum) to compute a vector of mnemonics. The mnemonics are recorded by the user and are used later in this part to recover the keys. The bip-39 protocol then pads the mnemonics with zeros to create a vector output whose size is a multiple of 128 bytes (The block size of sha-512). The padded output stored in reg3 is divided into two vectors, which are hashed using sha-512, and regO stores hash the digest. This digest is the Pwd variable, and the salt input is the Sit variable shown in Fig. 11. Moreover, salt is the word mnemonics padded with 416 bits that represent the optional personal identification number (PIN) used by the user to further strengthen the security of the generated keys. After regO is updated with the sha-512 digest, pbkdf computation commences. The counter counts 2048 hmacsha-512 operations, and the exclusive OR of each digest is calculated and stored in regl. The seed stored in regl is used in the child key derivation process. The child key derivation process uses the SECP256K1 cryptographic algorithm in various execution stages. The following subsection discusses the proposed hardware architecture of the SECP256K1 hash algorithm.

[0151] As discussed above, SECP256K1 is composed of ECPA, ECPD, and ECPM processes. ECPA calculates the sum of two different points on the ec (i.e. R = P + Q), while ECPD calculates the sum of a point with itself on the curve (i.e. R = 2P). Hence, to compute ECPD, we use ECPA by making the two points common (i.e. R = P + P = 2P). Moreover, scalar ECPM calculates the product of a point on the curve with an integer (i.e. R = k P).

[0152] ECPA and scalar ECPM are therefore, the two main processes executed in SECP256K1. This example uses the equations described in Algorithm 1 to design ECPA on the ec. Moreover, it uses the Montgomery ladder algorithm to propose a minimum area hardware architecture for ECPM.

[0153] We commence by designing the ECPA module, which should be congruent to the complete ECPA formulas presented in Algorithm 1. All operations performed in Algorithm 1 are modulo P, where P is a specific prime number chosen for SECP256K1. Therefore, we first design a malu to perform the modular addition, subtraction, and multiplication. A shift-and-add algorithm is utilized to perform the modular operations. Fig. 15 shows the proposed ECPA hardware architecture implementing the equations depicted in Algorithm 1. The ECPA architecture uses 8 256-bit registers, 2 16-to-1 multiplexers, and the malu. Moreover, the architecture uses a fsm to control the enable, select, and operation (op) signals, which selects the parameters, operations to perform, and the register to write the results depending on the executed equation.?: else : Hi + lb : o - H010: end if1 1: end for12: fi Ho12: return

[0154] -

[0155] The Montgomery ladder algorithm executed by the proposed ECPM architecture is shown in Algorithm 2. Lines 10-10 of the algorithm define the initial loading of registers Roand Rtwith point P and the doubling of point P (i.e., ECPD) respectively. P is a unique point defined by different elliptic curves as the generator point. Lines 10-10 iterate over the bit elements of the multiplier m. Roand Rtare updated with ECPA and ECPD depending on whether in, (j = 254,253,252, ...,0) is a 0 or 1. Each iteration executes the ECPA and the ECPD inside the loop process of the algorithm. This helps to secure the algorithm against sea. Line 10 loads the output register R with the final coordinate point in the projective form.

[0156] Fig. 17 depicts the proposed hardware architecture of the Montgomery ladder algorithm described by Algorithm 2. Comparing the proposed architecture in Fig. 17 to Algorithm 2, it can be observed that the proposed architecture utilizes two modules (PA0 and PA1) running in parallel to perform both ECPA and ECPD as opposed to four used in Algorithm 2. This reduces the overall size of the wallet. The architecture uses an fsm to control the various select signals to the multiplexers, enable signals to the register, and start signals for both PA0 and PA1. Moreover, the final output is stored in R.

[0157] The resultant coordinate R, as shown in (6) and computed by Fig. 17, is in projective coordinate form, i.e., (x,y,z). Therefore, we must convert R to affine coordinates, i.e., (xz-1, yz-1) => (x,y). This is achieved using the bia to calculate z-1.

[0158] Algorithm 3 shows the bia, which takes a variable z and a prime number P and outputs the modular inverse of z as R. It can be seen that the algorithm utilizes additions, subtractions, and shifts to calculate the modular inverse. Also, the algorithm requires 2m iterations to complete, where m is the number of bits of max(z, P). Each iteration truncates at least one bit of either u or v. Fig. 18 depicts the proposed hardware architecture used to execute Algorithm 3. The architecture uses an alu module to perform addition, subtraction, and shifting. Also, the architecture uses 2 eight-to-one multiplexers, 4 two-to-one multiplexers, and 5256-bit registers. The proposed wallet uses this architecture to compute z-1. The wallet then calculates (xz-1, yz-1), hence enabling SECP256K1 to compute a public key given a private key. The following subsection discusses the proposed hardware architecture of hmacsha-512.l“'iL'itli m 3 B inary inversion algorithm ( B IA )[npul: ... 21 : end w hileOutput 22: 22:1 : 24: il .r > 1 / lheii2: 25: ,r - .77: 2ti: else4: 27: ,r2 : end5: w hile rr * 0 do 2 : else(>: w hile i r i Oj = (} d<> 70: r r -7: 11 1 71 : if y,r lheii8: if .?■■ () = 0 then 72: t / -e- .7 - ,r :77: else10: else 74: if 7 + )> — ,r1 1 : 75: end if12: end7ti: end if17: end while 77: end while14: w hile r(() i = 0 di> 78: if rr = I then15: r i— r 1 79: ] nod ■; .<■. p i1 (>: if if', D) = 0 lheii 40: else17:1 41 : r ] nod ; . f < j18: el e 42: end if19: t) ■ t) - pi ] 47: return20: end if

[0159]

[0160] The hardware architecture of the proposed hmacsha-512 designed for a hd crypto wallet. The architecture has two pairs of key (k_0, k_1) and message (m_0, m_1) inputs that enable it to be used in all the stages of a hd wallet where hmacsha-512 is utilized.

[0161] Eq. (8) shows that hmacsha-512 executes sha-512 (denoted by H(-)) twice.However, the proposed hardware architecture shown in Fig. 19 utilizes one instance of sha- 512 during the hmacsha-512 execution process so as to minimize size. Moreover, an above section described that hmacsha-512 is executed multiple times in the Ethereum crypto wallet. Consequently, hmacsha-512 gets two different input sizes for the key and message variables during the key generation process. Hence, we add 2 two-to-one muxs to select the inputs. Fig.19 depicts the architecture of the proposed hardware design. The wallet selects k_0 and m_0 or k_1 and m_1 as inputs for a given operation (e.g., when creating the master key). The pad & chunk module pads the inputs of sha-512 to a multiple of 1024 and chunks them into blocks of 1024 bits long. For example, to calculate the sha-512 hash digest of an input x with 1536bits, x is first padded with zeros to 2048 bits and divided into two blocks of 1024 bits, sha-512 then calculates the hash of the first block and retains internal variables, using them to calculate the hash of the second block. The result is the sha-512 hash digest of x. Moreover, results show that sha-512 hash algorithm is utilized during the mnemonic generation process. Therefore, toSHA512 input shown in Fig. 19 allows the wallet to use the sha-512 hash algorithm inside the hmacsha-512 algorithm.

[0162] hmacsha-512 is one of the algorithms used by the Ethereum wallet inside and outside the ckd function. Therefore, the efficient architecture design of the ckd function is designed to reduce the size of the wallet.

[0163] bip-32 uses the ckd function to generate child private and public keys, as shown in Fig. 10. Moreover, the ckd function utilizes SECP256K1 and hmacsha-512 hash algorithms. Algorithm 4 depicts the ckd function execution process. The inputs y, 8, and A are private key, chain code, and child number, respectively. The private key and the chain code are digests from the hmacsha-512 hash function, where 256 Isb of the digest are the chain code, and 256 msb of the digest are the private key. Lines ckdA:1- ckdA:2 describes how the if condition specifies the creation of hardened keys. It appends xOO at the beginning of y if 8 > 231. The else statement in lines ckdA:3 - ckdA:6 describes how the ckd function creates normal keys. First, SECP256K1 generates a child public key p using y as input. Second, the ckd function executes a serialization function, taking p as input. The serialization process takes 256 msb of the 512-bit long p value as the public key. It then appends %02 if the 256-bit Isb integer p is even or %03 if the value is odd.

[0164] After the if-else statement, the ckd function creates a hardened or normal key, data. Line ckdA:7 creates data by concatenating data and the child number (A). Line ckdA:8 then uses hmacsha-512 with 8 and data as key and message, respectively, to generate L and R. L is the 256 msb of the hmacsha-512 digest while R is the remaining 256 Isb of the digest. Line ckdA:9 performs modulo P addition of L and y where P is the large prime number used in SECP256K1. The ckd function returns 8 and y as child chain code and child private key.Algorithm 4 Child kcv derivation function as described in BIP-. .Input: A AI: if A > 2s 1lheii2: (H)|3: else4: Sli€'E’356K 11 - )?: < r SL R I Al. IZH i6: end if10: .S PL L: return 7 . r>

[0165]

[0166] Nevertheless, the algorithms employed by the ckd function also perform other functions outside the ckd function. For example, hmacsha-512 is used in the pbkdf inside the bip-39 protocol to generate the seed value. Moreover, it is used to create the master private key and master chain code outside the bip-39 protocol and the ckd function. Additionally, the sha-512 algorithm is used inside and outside the pbkdf to compute various digests. Also, the wallet uses SECP256K1 to compute the child public key outside the ckd function after using it in the ckd function to compute regular keys. Therefore, to minimize the size of the device, we reuse the components by modifying the ckd function algorithm and propose the hardware architecture shown in Fig. 13. The proposed design allows the use of each internal algorithm by providing dedicated inputs and output paths. Inputs k0,toSHASH, and msg (message) allow the wallet to employ the hmacsha-512 and sha-512 algorithms outside the ckd function and store the digest in the output registers. Moreover, the output of SECP256K1 is connected to an output register, allowing it to be used by outside processes via input y.

[0167] After using the SECP256K1 in the ckd function to generate a public key, Fig. 14 shows that the wallet generates an Ethereum address by passing the public key through the Keccak-256 hash algorithm. Moreover, the wallet creates a checksummed Ethereum address by employing the same instance of Keccak-256. The following subsection discusses the proposed architecture of the Ethereum checksum algorithm.

[0168] In Fig. 14, Addr defines the Ethereum address without a checksum and checkAddr is the checksummed Ethereum address. Moreover, Algorithm 5 outlines the Ethereum blockchain checksum process. The checksum ensures that the address is free of errors. The algorithm inputs the alphanumeric Ethereum address 8 and the Keccak-256 hash digest of the address o. For each letter element in the address 8, if the corresponding element in the digest o is greater than 7, the letter in 8 is capitalized. Using the function capital^ ), we transform the hexadecimal address to the ascii format to represent uppercase letters in hardware. Therefore, this example uses offsets to map the hexadecimal elements to the corresponding ascii format. For each group of four bits of 8 converted to an integer, we add an offset to map it to the corresponding 8-bit ascii upper or lower case representation.

[0169] The following section examines the implementation results of the proposed Ethereum hd cold wallet architecture.Algorithm 5 Pseudo algorithm for Elliereimi checksum.Input: iT I *-kcccak 256(^iOutput: ctend if9: end if10: end f r L L: return

[0170]

[0171] Table 2 shows the implementation results of the proposed bip-39 architecture, shown in Fig. 15, and those of the ckd function, shown in Fig. 20. Even though bip-39 uses the hmacsha-512 algorithm, its area is not included in calculating the area of bip-39. This is because the hmacsha-512 used is in the ckd function. However, Table 2 indicates that the area of the bip-39 architecture is very close to the area of the ckd function. The large size of bip-39 is due to the MNG module shown in Fig. 15, which stores the English mnemonics wordlist. The MNG module requires 71.4% of the total space utilized by bip-39. A comparative analysis is not done as hardware implementations of this function could not be found in the literature. The following section presents the implementation results of the complete wallet.

[0172] Table 2: Implementation results of bip-39 and the ckd function on Zynq-ultra scale.

[0173] Table 3 presents the resource utilized by the proposed Ethereum hd cold wallet illustrated in Fig. 14. The table indicates that 20% of the lut in the ZYNQ ULTRA-SCALE fpga were utilized. Additionally, 6% of registers and 0.32% of ram were employed. Also, no dsp blocks were utilized, and the wallet runs at a maximum frequency of 166.67 MHz. The latency metric denotes the latency incurred when generating the first key. Also, throughput is estimated by dividing the maximum frequency by the number of cc and multiplying the quotient by the total number of bits generated. However, throughput is calculated using the number of cc utilized when calculating the second private-public key pair. As discussed above, calculating the second pair requires less time than calculating the first. Notably, 3 790 kcc (Equivalent to 22.74 ms) are required to calculate the second key compared to 6 364.49 kcc used to calculate the first key. Fig. 10 shows that the ckd function computes keys using a keyderivation path. The latency used by Trazor One physical wallet to execute the ckd function and generate the master public key is 386.59 ms. Moreover, the ckd function takes 94.30 ms to execute each element in the given path. Therefore, we can estimate the latency ofcalculating the second private-public key pair in Trazor One as 188.60 ms. This is because after calculating the first pair, the second can be calculated by only changing the last element of the key-derivation path. Hence, the latency of generating the second key in the proposed wallet is 87.9% less than that of Trezor one. Moreover, we can estimate the throughput of the Trezor One wallet as 2.71 Mbps (Throughput = 1 H- latency x 512). This suggests that the throughput of the proposed wallet is 88% higher.

[0174] Also, the current Ethereum blockchain network has a transaction rate of 15 to 20 tps. This suggests that a cold wallet signing transaction may have a minimum throughput of 10.4 kbps (Authors estimate Ethereum’s throughput = tps x (public key size + private key size)). Therefore, the 22.52 Mbps throughput of the proposed cold wallet is sufficient to support user transactions in the current Ethereum blockchain.

[0175] Table 3: Implementation results of the proposed Ethereum hd wallet on Zynq ultrascale.

[0176] aThroughput is estimated by authors as (Frequency - cc) x 512.

[0177] SECP256K1 incorporates the architectures of ECPA depicted in Fig. 16, ECPM depicted in Fig. 17, and BIA depicted in Fig. 18. The analysis reveals that our proposed implementation consumes 12.5% more LLITs than existing architectures, albeit utilizing 1 036 fewer LLITs. Moreover, on average, SECP256K1 consumes approximately 48% fewer LLITs compared to existing competing devices.

[0178] In conclusion, this example proposes a hardware architecture of an Ethereum hd cold wallet and further discusses the results of an fpga-based implementation. The implementation results indicate that the building blocks of the proposed design are smaller than analogous implementations in literature, suggesting a compact size for the proposed wallet. However, the implementation results also indicate that the compact size comes at the expense of high latency, leading to low throughput. Nevertheless, we have shown that the throughput of the proposed wallet is sufficient to support user transactions on the current Ethereum blockchain. Moreover, the throughput of the proposed wallet is higher than that of the Trazor One wallet, while the latency is lower. In addition, the proposed architecture achieves a high frequency, signaling that the wallet can achieve higher throughput if pipelining is employed. Furthermore, the proposed wallet is bip-32, bip-39, and bip-44 compliant, which are features that are widely desired by blockchain users. In the future, we aim to add an nd wallet option and enable support for more crypto.

[0179] As can be understood, the examples described above and illustrated are intended to be exemplary only. For instance, in some embodiments, only the first hardware computing device can be re-used. More specifically, in these embodiments, the hardware wallet apparatus generally has a first hardware computing device generating a parent private key and a parent chain code based on a random number; and a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating, with a given number registered in a memory of the second hardware computing device, a parent public key based on the parent private key; a parentdependent number generation device generating a parent-dependent number based on the parent private key and on the parent public key; a third hardware computing device communicatively coupled to the parent-dependent number generation device, the thirdhardware computing device generating a child private key and a child chain code based on the parent-dependent number and on the parent chain code; and the second hardware computing device generating, with the memory of the second hardware computing device reset to the given number, a child public key based on the child private key. In these latter embodiments, the first hardware computing device and the third hardware computing device can correspond to a same hardware computing device. Moreover, only the second hardware computing device can be re-used in some other architectures. In such embodiments, the hardware wallet apparatus has a first hardware computing device generating, with a first given number registered in a memory thereof, a parent private key and a parent chain code based on a random number; and a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating a parent public key based on the parent private key; and a parent-dependent number generation device generating a parent-dependent number based on the parent private key and on the parent public key; the first hardware computing device communicatively coupled to the parentdependent number generation device, the first hardware computing device generating, with the memory of the first hardware computing device reset to the first given number, a child private key and a child chain code based on the parent-dependent number and on the parent chain code; and a third hardware computing device generating a child public key based on the child private key. In these latter embodiments, the second hardware computing device and the third hardware computing device can correspond to a same hardware computing device. The scope is indicated by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method of generating a child public key with a hardware wallet apparatus having a housing enclosing a cavity and at least one printed circuit board located in the cavity, and a computing device mounted to the at least one printed circuit board, the computing device having a hardware-implemented elliptic curve function, the method comprising : generating a parent public key using the hardware-implemented elliptic curve function of the computing device, a parent private key, and a first number registered in a memory of the computing device; subsequently to said generating the parent public key, resetting the memory of the computing device to the first number; and subsequently to said resetting the memory of the computing device to the first number; generating a child public key using the hardware-implemented elliptic curve function of the computing device, a child private key, and the first number registered in the memory of the computing device.

2. The method of claim 1 wherein the hardware-implemented elliptic curve function involves one of: elliptic curve point addition (ECPA), elliptic curve point doubling (ECPD), and elliptic curve point multiplication (ECPM).

3. The method of claim 1 or 2 wherein the hardware-implemented elliptic curve function is a SECP256K1 elliptic curve function.

4. The method of any one of claims 1 to 3 wherein subsequently to said generating the child public key, resetting the memory of the computing device to the first number.

5. The method of claim 4 wherein the child private key is a first child private key and the child public key is a second child public key, the method further comprising generating a second child public key using the hardware-implemented elliptic curve function of the computing device, a second child private key, and the first number registered in the memory of the computing device.

6. The method of claim 4 wherein the parent public key is a first parent public key and the parent private key is a first parent private key, the method further comprising: generating a second parent public key using the hardware-implemented elliptic curve function of the computing device, a second parent private key, and the first number registered in the memory of the computing device.

7. The method of any one of claims 1 to 6 wherein the computing device includes a Field Programmable Gate Array (FPGA) device.

8. The method of any one of claims 1 to 7 wherein the computing device includes a microcontroller.

9. The method of any one of claims 1 to 8 wherein the master private key includes X number of bits, and the master public key includes X / 2 number of bits.

10. The method of claim 9 wherein the X number of bits is 512.11 . A hardware wallet apparatus comprising: a housing enclosing a cavity; at least one printed circuit board located in the cavity; a parent key generator having a computing device mounted to the at least one printed circuit board, the computing device having a hardware-implemented elliptic curve function, and a first number registered in a memory of the computing device, the computing device operable to generate, using the hardware-implemented elliptic curve function, a parent public key based on a parent private key and on the first number; a resetter operable to reset the computing device to the first number; and a child key generator havingthe computing device operable to generate, using the hardware- implemented elliptic curve function, a child public key based on a child private key and the first number.

12. The hardware wallet apparatus of claim 11 wherein the hardware-implemented elliptic curve function involves one of: elliptic curve point addition (ECPA), elliptic curve point doubling (ECPD), and elliptic curve point multiplication (ECPM).

13. The hardware wallet apparatus of claim 11 or 12 wherein the hardware-implemented elliptic curve function is a SECP256K1 elliptic curve function.

14. The hardware wallet apparatus of any one of claims 11 to 13 wherein subsequently to said generating the child public key, resetting the memory of the computing device to the first number.

15. The hardware wallet apparatus of claim 14 wherein the child private key is a first child private key and the child public key is a second child public key, the method further comprising a second child public key using the hardware-implemented elliptic curve function of the computing device, a second child private key, and the first number registered in the memory of the computing device.

16. The hardware wallet apparatus of claim 14 wherein the parent public key is a first parent public key and the parent private key is a first parent private key, the method further comprising: generating a second parent public key using the hardware- implemented elliptic curve function of the computing device, a second parent private key, and the first number registered in the memory of the computing device.

17. The hardware wallet apparatus of any one of claims 11 to 16 wherein the computing device includes a Field Programmable Gate Array (FPGA) device.

18. The hardware wallet apparatus of any one of claims 11 to 17 wherein the computing device includes a microcontroller.

19. The hardware wallet apparatus of any one of claims 11 to 18 wherein the master private key includes X number of bits, and the master public key includes X / 2 number of bits.

20. The hardware wallet apparatus of claim 19 wherein the X number of bits is 512.21 . A hardware wallet apparatus comprising: a parent key generator having a first hardware computing device generating, with a first given number registered in a memory thereof, a parent private key and a parent chain code based on a random number; and a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating, with a second given number registered in a memory of the second hardware computing device, a parent public key based on the parent private key; and a child key generator having a parent-dependent number generation device generating a parentdependent number based on the parent private key and on the parent public key; the first hardware computing device communicatively coupled to the parent-dependent number generation device, the first hardware computing device generating, with the memory of the first hardware computing device reset to the first given number, a child private key and a child chain code based on the parent-dependent number and on the parent chain code; andthe second hardware computing device generating, with the memory of the second hardware computing device reset to the second given number, a child public key based on the child private key.

22. The hardware wallet apparatus of claim 21 further comprising a random number generation device communicatively coupled to the first hardware computing device, the random number generate device generating the random number.

23. The hardware wallet apparatus of claim 22 wherein the random number generation device is a quantum random number generation device.

24. The hardware wallet apparatus of any one of claims 21 to 23 wherein the parentdependent number is a first parent-dependent number, the parent-dependent number generation device generating a second parent-dependent number based on the child private key and on the child public key.

25. The hardware wallet apparatus of claim 24 wherein the first hardware computing device generating, with the memory of the first hardware computing device reset to the first given number, a second child private key and a second child chain code based on the second parent-dependent number and on the child chain code.

26. The hardware wallet apparatus of claim 25 wherein the second hardware computing device generating, with the memory of the second hardware computing device reset to the second given number, a second child public key based on the second child private key.

27. The hardware wallet apparatus of any one of claims 21 to 26 wherein the random number is a first random number, the first hardware computing device generating, with the first given number registered in the memory thereof, a second parent private key and a second parent chain code based on a second random number different from the first random number.

28. The hardware wallet apparatus of claim 27 wherein the second hardware computing device generating, with the second given number registered in the memory thereof, a second parent public key based on the second parent private key.

29. The hardware wallet apparatus of any one of claims 21 to 28 wherein at least one of the first hardware computing device and the second hardware computing device is a Field Programmable Gate Array (FPGA) device.

30. The hardware wallet apparatus of any one of claims 21 to 29 wherein at least one of the first hardware computing device and the second hardware computing device is a microcontroller.

31. A method for generating cryptographic keys using a hierarchical deterministic hardware wallet, the method comprising: a first hardware computing device generating, with a first given number registered in a memory thereof, a parent private key and a parent chain code based on a random number; a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating, with a second given number registered in a memory of the second hardware computing device, a parent public key based on the parent private key; generating a parent-dependent number based on the parent private key and on the parent public key; resetting the memory of the first hardware computing device to the first given number and resetting the memory of the second hardware computing device to the second given number; the first hardware computing device generating a child private key and a child chain code based on the parent-dependent number and on the parent chain code; andthe second hardware computing device generating a child public key based on the child private key.

32. The method of claim 31 wherein the parent-dependent number is a first parentdependent number, the method further comprising generating a second parentdependent number based on the child private key and on the child public key.

33. The method of claim 32 further comprising: repeating said resetting; the first hardware computing device generating a second child private key and a second child chain code based on the second parent-dependent number and on the child chain code; and the second hardware computing device generating a second child public key based on the second child private key.

34. The method of one of claims 31 to 33 wherein the random number is a first random number, the method further comprising: repeating said resetting, the first hardware computing device generating a second parent private key and a second parent chain code based on a second random number different from the first random number; and the second hardware computing device generating a second parent public key based on the second parent private key.

35. A hardware wallet apparatus comprising: a first hardware computing device generating a parent private key and a parent chain code based on a random number; and a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating, with a given number registered in a memory of the second hardware computing device, a parent public key based on the parent private key; a parent-dependent number generation device generating a parent-dependent number based on the parent private key and on the parent public key;a third hardware computing device communicatively coupled to the parentdependent number generation device, the third hardware computing device generating a child private key and a child chain code based on the parentdependent number and on the parent chain code; and the second hardware computing device generating, with the memory of the second hardware computing device reset to the given number, a child public key based on the child private key.

36. The hardware wallet apparatus of claim 35 wherein the first hardware computing device and the third hardware computing device correspond to a same hardware computing device.

37. A hardware wallet apparatus comprising: a first hardware computing device generating, with a first given number registered in a memory thereof, a parent private key and a parent chain code based on a random number; and a second hardware computing device communicatively coupled to the first hardware computing device, the second hardware computing device generating a parent public key based on the parent private key; and a parent-dependent number generation device generating a parent-dependent number based on the parent private key and on the parent public key; the first hardware computing device communicatively coupled to the parentdependent number generation device, the first hardware computing device generating, with the memory of the first hardware computing device reset to the first given number, a child private key and a child chain code based on the parent-dependent number and on the parent chain code; and a third hardware computing device generating a child public key based on the child private key.

38. The hardware wallet apparatus of claim 37 wherein the second hardware computing device and the third hardware computing device correspond to a same hardware computing device.

Images