WO2020051910A1

WO2020051910A1 - Secure hardware cryptographic key storage device with detachable battery and anti-tamper security functionality

Info

Publication number: WO2020051910A1
Application number: PCT/CN2018/105828
Authority: WO
Inventors: Lixin LIU; Shixing MAO; Qiaoping LUO; Yuhan Wang; Xiaoming Yang; Yongan ZHANG; Biao Lu; Changhao Jiang; Dong Chen; Kai Liu; Huazhou WANG; Huiwen CUI
Original assignee: Cobo Global Ltd
Current assignee: Cobo Global Ltd
Priority date: 2018-09-14
Filing date: 2018-09-14
Publication date: 2020-03-19
Anticipated expiration: 2021-03-14

Abstract

A cryptographic key store device comprises an encryption chip to store one or more cryptographic keys. The device further comprises a plurality of magnetic locks distributed on a first surface of an excavated section of the cryptographic key store device. The plurality of magnetic locks coupleable to a second plurality of complementary magnetic locks on a detachable battery. The exterior surface of the detachable battery is continuous with an exterior surface of the key store device when the detachable battery is coupled to the key store device by the plurality of magnetic locks. The device further includes two parallel attachment tracks formed on two opposite sides of the first surface, with each attachment track coupleable to complementary tracks on the detachable battery. The detachable battery is translatable along a longitudinal direction of the two parallel attachment tracks.

Description

SECURE HARDWARE CRYPTOGRAPHIC KEY STORAGE DEVICE WITH DETACHABLE BATTERY AND ANTI-TAMPER SECURITY

FUNCTIONALITY

FIELD OF ART

[0001] The disclosure generally relates to hardware-backed cryptographic key storage, and specifically to a secure hardware cryptographic key storage device with detachable battery and anti-tamper security functionality.

BACKGROUND

[0002] Cryptographic keys are widely used as a means of authenticating a user in an untrusted space, such as on the Internet. These users may in some cases be identifiable by other means, such as using traditional identification methods (e.g., with government databases), or may only be identifiable using these cryptographic keys. Therefore, the cryptographic key may sometimes comprise the only means of identifying and authenticating the individual user. For the user, this means that his or her cryptographic key(s) must be secured in a fashion which prevents all unauthorized accesses, while allowing the extraction of data, such as digital signatures, from the keys, in order to authorize the user for various activities. These activities may include activities on a blockchain, and so on. This is difficult to achieve, as any forward transmission of data using the key may cause an unauthorized backwards malicious intrusion to retrieve the key itself. Therefore, what is needed is a system that provides a secure method of storing a user’s cryptographic keys.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The disclosed embodiments have advantages and features which will be more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings). A brief introduction of the figures is below.

[0004] Figure (FIG.) 1 is a block diagram illustrating a system with a hardware wallet, client device, wallet server system and distributed ledger, according to an example embodiment.

[0005] FIG. 2A illustrates two views of the hardware wallet with detachable battery attached and detachable battery removed, according to an embodiment.

[0006] FIG. 2B illustrates the detachable battery with magnetic locks, according to an embodiment. [0007] FIG. 2C illustrates the hardware wallet with magnetic locks to attach to the detachable battery, according to an embodiment.

[0008] FIG. 3 A is a cutaway view of the hardware wallet with an angled connector to attach the detachable battery to the circuit board of the hardware wallet, according to an embodiment.

[0009] FIG. 3B is an exploded view of the hardware wallet with components of the angled connector, according to an embodiment.

[0010] FIG. 3C is an alternative exploded view of the hardware wallet with components of the angled connector, according to an embodiment.

[0011] FIG. 4A is an exploded view illustration of a case for the hardware wallet with guided release mechanism, according to an embodiment.

[0012] FIG. 4B is an isometric exploded view illustration of the case with guided release mechanism for the hardware wallet showing the interior of the case, according to an embodiment.

[0013] FIG. 4C is an alternative isometric exploded view illustration of the case with guided release mechanism for the hardware wallet showing the exterior of the case, according to an embodiment.

[0014] FIG. 5A is a transactional diagram illustrating a method of verifying the integrity of the hardware wallet on initial use, according to an embodiment.

[0015] FIG. 5B is a transactional diagram illustrating a device serial number specific method of verifying the integrity of the hardware wallet on initial use, according to an embodiment.

[0016] FIG. 5C is a transactional diagram illustrating a shared key method of verifying the integrity of the hardware wallet on initial use, according to an embodiment.

[0017] FIG. 5D is a transactional diagram illustrating an encrypted shared key method of verifying the integrity of the hardware wallet on initial use, according to an embodiment.

[0018] FIG. 6A is a flow chart illustrating a self-check mechanism for the OS layer of the hardware wallet, according to an embodiment.

[0019] FIG. 6B is a flow chart illustrating a self-check mechanism for the encryption layer of the hardware wallet, according to an embodiment.

[0020] FIG. 7 is a transactional diagram illustrating an automated QR code data transfer between the hardware wallet and a wallet interface application, according to an embodiment. [0021] FIG. 8A is a transactional diagram illustrating a method of determining a balance associated with a hierarchal deterministic seed stored in the hardware wallet, according to an embodiment.

[0022] FIG. 8B is a continuation of the transactional diagram of FIG. 8 A illustrating a method of determining a balance associated with a hierarchal deterministic seed stored in the hardware wallet, according to an embodiment.

DETAILED DESCRIPTION

[0023] The Figures (FIGS.) and the following description relate to preferred

embodiments by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of what is claimed.

[0024] Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

HARDWARE WALLET CRYPTOGRAPHIC KEY STORE SYSTEM OVERVIEW

[0025] Figure (FIG.) 1 is a block diagram illustrating a system 100 with a hardware wallet 110, client device 130, wallet server system 140, and distributed ledger 150, according to an example embodiment. Although a certain arrangement of elements is shown here, in other embodiments the elements are arranged differently.

Hardware Wallet

[0026] The hardware wallet 110 provides a secure store of cryptographic keys of a user and is capable of executing requests upon input data using the stored keys. The hardware wallet 110 may include an application (app) layer 116, OS layer 114, and encryption layer 112 with key store 113. The hardware wallet 110 may also include a display 118, an imaging device 120, an input 122, a detachable battery 124, and an anti-tamper circuit 126.

[0027] The encryption layer 112 includes an encryption chip which stores one or more cryptographic keys in a key store 113. These cryptographic keys may be any type of key used in symmetric or asymmetric encryption. For example, the keys could be an Elliptic Curve Digital Signature Algorithm (ECDSA) private key and public key, an RSA key pair, an AES symmetric key, and so on. In one embodiment, the key store 113 stores a hierarchical deterministic (HD) wallet, such as the HD wallet specified in BIP (Bitcoin Improvement Protocol) 44. An HD wallet is defined by a master private key (along with a master public key). This master private key may be used to generate child public and private keys, by hashing (e.g., using HMAC, or hash-based message authentication code) the master private/public key with a deterministic index value or series of index values that can be stored in a tree structure. This allows multiple child keys to be deterministically generated using only a single master key. These child keys may be used for subsequent transactions requiring cryptographic keys, and recovered from knowing the master key only. The master key may also be recovered using a seed value, which may comprise multiple English words chosen from a dictionary (or vice versa). The master key is generated from the seed value using a combination of cryptographic functions. The master key, child keys and their associated index values, and the seed value, may all be stored in the key store 113.

[0028] The encryption chip may not only store these keys, but also generate them upon request by the user (e.g., via the input 122), using the corresponding cryptographic function, such as SHA, ECDSA, MD5, RSA, an HMAC variant, and so on. For example, a master key may be generated from a randomly selected seed value. The seed value may then be provided to the user.

[0029] These keys stored in the key store 113 may be used in various applications. In one embodiment, the keys are used to authenticate distributed ledger transactions.

Distributed ledger transactions are transactions within a distributed ledger, which is a consensus-based approach for distributing a shared set of data across multiple computing devices. Transactions recorded on a distributed ledger can easily be spoofed as no centralized administrator exists to verify all transactions, and therefore a secure

authentication method is necessary to authenticate users who execute transactions which are recorded on the distributed ledger. Each transaction is therefore accompanied by a public key identifying a user (and a public key identifying a recipient if necessary). This public key is paired with a private key, both of which may be stored in the key store 113 of the user’s hardware wallet 110. For example, this key pair may be a child key pair of an HD wallet stored in the key store 113. [0030] Other applications for the hardware wallet 110 may include digitally signing documents, providing keys for encrypting messages for secure transmission (e.g., PGP), generation of certificates, and so on.

[0031] The private keys and symmetric keys stored in the key store 113 are not exposed outside of the encryption layer 112. Any data that necessitates the use of the key is received by the encryption layer 112, which performs the necessary operations upon the data, and then returns the processed data to the external environment. In this fashion, the keys are safe from access by a malicious individual. Although the keys are normally not retrievable, the encryption layer 112 may provide the keys under unique circumstances. For example, a user may be able to provide robust authentication information, such as a special passcode, biometric information, or other secret, upon which the encryption layer 112 may provide an encrypted version of one or more of the keys to the user (e.g., in the form of one or more matrix barcodes via the display 118). Alternatively, these keys can never be retrieved from the encryption layer 112 through any designed means, and may only be recovered through the use of a seed value. For example, by inputting the seed phrase into the hardware wallet 110, the encryption layer 112 is able to generate the keys internally.

[0032] Although a private key in a key pair is normally not exposed outside the encryption layer 112, the encryption layer may readily provide access to the public key of the key pair upon request by an external entity, such as the user, or the wallet interface application 136.

[0033] The encryption layer 112 may also be configured to enter one of three states.

These include a factory state, a safe mode state, and a normal state. The factory state is the state of the encryption layer 112 upon leaving the manufacturing facility. In this state, the encryption layer 112 is set up to receive user authentication information, a seed value, and other configuration information for the initial setup of the encryption layer 112. The safe mode is a mode in which the encryption layer 112 has detected a security compromise of the hardware wallet 110. In this mode, the encryption layer 112 does not allow any access to any stored information, including the keys stored in the key store 113. If the encryption layer 112 enters the safe mode state, it may also securely wipe the data stored within the key store 113 as well (e.g., by writing random numbers or zeros to the entire key store). The third state is a normal state (otherwise known as the“wallet state”). This is the normal operating state of the encryption layer 112, in which requests may be received by the encryption layer 112 to process data using keys stored in the key store 113 or with newly generated keys, to output processed data, to output signatures, hashes, and other cryptographic output, to output public keys, to list non-secret information about stored keys, and so on, using various stored cryptographic routines. These requests may be accompanied by an authentication data (e.g., a PIN), such that the authentication data is needed in order to decrypt or perform any of the requests indicated. The state in which the encryption layer 112 enters may be determined by an initialization process, which may occur when the hardware wallet 110 is turned on. This process is described in more detail below with reference to FIG. 6B.

[0034] In order to access the encryption layer 112 for performing operations on data, and for retrieving public keys, the hardware wallet 110 further includes the OS layer 114 and the app layer 116, which provide additional software components to allow for access to the encryption layer 114 in a human-accessible format.

[0035] The OS layer 114 is any low resource operating system with a tiered access privilege architecture. A low resource operating system is an operating system that can operate on devices having mobile or embedded hardware characteristics, such as the hardware wallet 110. Such operating systems may be designed to execute on mobile systems on a chip (SoC’s), such as processors using the ARM instruction set. Such operating systems may also implement various power saving features, such as having a kernel which frequently places system components in a deep sleep mode (e.g., a low power mode) and which has a scheduling system for batching scheduled system operations and application process activities to reduce power usage. An example of such an operating system is Android®.

[0036] The OS layer 114 may be an off-the-shelf mobile operating system, and thus have the necessary executable code for interfacing with common mobile device elements, such as a processor, and such as the display 118, imaging device 120, and so on, of the hardware wallet 110. The OS layer 114 may also be further modified, to remove certain components, and to add additional components. The components that may be removed include those that are not used by the hardware wallet 110 hardware, such as drivers for any wireless communications, cloud-based account management, app stores, speech recognition systems, and so on, as these components may provide additional attack vectors for malicious users to gain unauthorized access to the system. The OS layer 114 may also include additional executable code, such as drivers and application programming interfaces (APIs), for access to functionality of the encryption layer 112, such as for signing of data, for requesting of public keys, and for generation of new keys management, etc.

[0037] The OS layer 114 includes a privilege system, such that privileged operations are not accessible to a user interfacing with the hardware wallet 110. Such hardware operations may only be performed by a process with“root” privileges. These root processes may be executing in the kernel space of the operating system of the OS layer 114. Operations which access the encryption layer 114, may require root privileges to execute. However, operations which interface externally may execute without elevated privileges, i.e., they are non- privileged. Privileged operations may have access to all features and functions of the OS layer 114, while non-privileged operations are restricted. For example, non-privileged operations may not be able to request any access to the encryption layer 112 directly. In order for a non-privileged operation to access a function of the encryption layer 112, it may need to request access via a privileged operation. This allows the privileged operation to act as a gatekeeper to the encryption layer 112. If the request from the non-privileged operation is malformed or does not have the proper authentication or authorization parameters, then the request can be denied. A malformed request may be performed by a malicious attacker. Proper authentication or authorization parameters may include a user password, biometrics, or some other form of authentication.

[0038] The OS layer 114 may also include an initialization process. This process occurs every time the hardware wallet 110 is initialized, e.g., powered up. The initialization process may check for a signature of the app layer 116, whether the OS layer 114 has been“rooted,” i.e., privilege escalation has occurred, and so on. Any errors encountered during this initialization process may cause the OS layer 114 to enter a safe mode, and to cause the encryption layer 112 to enter a safe mode as well. Additional details regarding the initialization process is described below with regards to FIGs. 6A.

[0039] The app layer 116 includes executable code that provides the interface between the OS layer 114 and encryption layer 112 and to the user via the various I/O functions of the hardware wallet 110, such as the display 118, imaging device 120, input 122, and so on. In one embodiment, the app layer 116 is a software package executing on the OS layer 114, such as an Android APK (or Android PacKage). Such a software package may comprise a package name with an archive file containing metadata, such as a manifest and a certificate with a signature of the application package, as well as the application code, which may be in the form of a bytecode to be executed by a virtual machine component of the OS layer 114 or to be converted by the OS layer 114 to native code.

[0040] The app layer 116 provides various functionalities for the hardware wallet 110. These may include a factory setup process, the transmission and receipt of data by generation of matrix barcodes (e.g., QR code), signing of data using one or more keys, display of processed data, web authentication, biometric or other user authentication, security checking, and so on. [0041] The factory setup process is a process which may occur when the hardware wallet 110 detects during the initialization process that it is in a factory state. This factory state may be determined based on a flag in the encryption chip of the encryption layer 112, based on the lack of user credentials and/or keys stored in the key store 113, or some other method. The app layer 116 may initialize a routine to request from the user various authentication data, such as a fingerprint, iris information, a secret (e.g., a password, PIN, and/or pattern), a face print, and so on. This information may be received via one of the input mechanisms, such as the input 122, display 118, imaging device 120, and so on, and may be transferred to the encryption layer 112. The app layer 116 may also request that the user provide a seed value. As noted, this seed value may be used to generate the master keys of an HD wallet by the encryption layer 112. These seed value may be transmitted by the app layer 116 to the encryption layer 112 via privileged operations in the OS layer 114, upon which the

encryption layer 112 generates a master keys. Alternatively, the user may instruct the app layer 116 to generate a new seed value. In such a case, the encryption layer may randomly generate a new seed value, and then generate the master keys for an HD wallet using this seed value. The seed value is then transmitted to the app layer 116 for presentation to the user (e.g., in plaintext, encrypted text, or as a matrix barcode).

[0042] In one embodiment, the app layer 116 may also request the user to input any other private keys or symmetric keys, or other cryptographic key data for which the user may wish to store.

[0043] Any keys stored in the encryption layer 112 may also be further encrypted, hashed, or otherwise modified by the authentication data (e.g., the HD wallet keys may be encrypted using a PIN number provided by the user).

[0044] During this initial factory setup process, the app layer 116 may generate, or be requested to generate, one or more public keys to which a user can direct any transactions for which the user has a private key in the distributed ledger 150. This allows the user to transfer any balance from the distributed ledger to be associated with keys stored in the hardware wallet 110. The private keys associated with these public keys (i.e., the keys that can be used to transact the transferred balance) are not exposed outside the encryption layer 112 using this method.

[0045] The transmission and receipt of data, such as the seed value, data to be processed, or authentication data, may be accomplished by the app layer 116 via the transfer of matrix barcodes between the hardware wallet 110 and the client device 130. The app layer 116 may be able to decode data from, and encode data to, matrix barcodes of various data capacities and types. The matrix barcodes may be received via the imaging device 120, and output via the display 118. Examples of matrix barcodes include QR Code, Data Matrix, Aztec Code, and so on. As the data to be sent or received may exceed the capacity of an individual matrix barcode, the app layer 116 may generate multiple matrix barcodes to transfer data automatically. This type of transfer may occur for data which is too large to efficiently input by hand using any input means on the hardware wallet 110. Additional details regarding this automated transfer of this data is described below with reference to FIG. 7.

[0046] After the initial factory setup process, the app layer 116 may be requested to process data, e.g., sign or encrypt data, using one or more of the keys stored in the key store 113. The app layer 116 may present a graphical user interface or other interface to the user via the display 118, or receive instructions via matrix barcodes which are scanned by the imaging device 120, to process data via a selected key in the key store 113. These instructions may include the authentication data, or the app layer 116 may additionally request the authentication data from the user. The app layer 116 receives the data, decodes it if necessary, and transmits the data to the encryption layer 112 via the OS layer 114 along with an instruction of what type of processing is requested. The encryption layer 112 processes the data according to the instructions, and outputs the processed data or other cryptographic output, which is received by the app layer 116. The app layer 116 may then encode the data, e.g., as matrix barcodes, and output the data, e.g., via the display 118.

[0047] The instructions that the app layer 116 may receive may include, but are not limited to: 1) signing of transaction or other data using a selected key to generate a signature as output, 2) generation of one or more new keys, 3) retrieval of a selected public key, 4) retrieval of non-secret information about stored keys (e.g., a number of keys stored), 5) encryption of input data using a selected key to generate an encrypted output, 6) verifying a digital signature for a chunk of data, and 7) generation of a new key pair, inserting the public key of the key pair into received transaction data at a particular instructed location, signing of the modified transaction data by the private key of the key pair, and returning the signature and the modified transaction data.

[0048] The app layer 116 may also include instructions to initiate a web authentication process. This process allows the app layer 116 to authenticate with a key on the wallet server system 140 using a key stored in the key store 113 during the manufacturing process, in order to verify that the hardware wallet 110 has not been tampered between the point of manufacturer and the receipt of the hardware wallet 110 by the user. Additional details regarding this web authentication process is describe below with reference to FIG. 5A-5D. [0049] In one embodiment, the above layers may also be implemented in a single microcomputer chip, such as a SoC system.

[0050] To support the functions described above, the hardware wallet 110 may include one or more physical components that may be used for input and output and for security. These may include a display 118, an imaging device 120, an input 122, a detachable battery 124, and an anti-tamper circuit 126.

[0051] The display 118 is a low power display capable of display matrix barcodes. It may be an organic light emitting diode (OLED) display, liquid crystal display (LCD), light emitting diode (LED) display, electronic paper (e.g., an electrophoretic) display, or any other display technology. The display may satisfy various requirements. It may be capable of displaying in black and white or color depending upon whether color or black and white matrix barcodes are used. It may have sufficient resolution to display a matrix barcode of a threshold data capacity, e.g., a Version 3 QR code. It may have a refresh rate capable of display the matrix barcodes sequentially at a particular barcode refresh frequency. The parameters of the display 118 may be optimized for long battery life, such that a display technology with low power draw, using black and white images, and having a low refresh rate, and having a low resolution are selected that meet the threshold requirements indicated above. In one embodiment, the display 118 includes a touchscreen input.

[0052] The imaging device 120 is a device that captures one or more images within a field of view. It may be a standard camera, or may be a barcode scanner, such as a laser scanner, LED scanner, and so on. It may be capable of processing matrix barcodes of a specific data capacity, and may be capable of error correction internally. It may be capable of scanning barcodes at the barcode refresh frequency noted above.

[0053] The input 122 may be any type of user input. The input 122 may be used to enter authentication information, such as PIN number, pattern, password, or so on. The input 122 may be a type of biometric authentication system, such as a fingerprint reader, an iris scanner, a voiceprint identifier, a face scanner, and so on. The input 122 is therefore able to provide authentication data to the app layer 116 as described above. Note that the input 122 may not include an electronic coupling, such as a wireless or wired data input, as this would expose the hardware wallet 110 to potential malicious attacks against its software.

[0054] The detachable battery 124 may be any type of device capable of storing an electrical charge and delivering it to the hardware wallet 110 to power the components of the hardware wallet 110. The detachable battery 124 may include, for example, one or more lithium-ion cells, lithium polymer cells, nickel cadmium cells, alkaline cells, etc. The detachable battery 124 has a housing which fits flush to the surface of the hardware wallet 110 housing when installed, such that no discontinuities exist along the exterior surface of the combined hardware wallet housing and detachable battery. As the detachable battery 124 can be removed from the hardware wallet 110, it can be replaced once its charge capacity degrades. This allows continued use of the hardware wallet 110, instead of having to replace the hardware wallet 110 as in the case of devices storing keys that have integrated batteries.

As the hardware wallet 110 does not likely need constant upgrades, and as key transfer to a new device is a tedious task, the use of the detachable battery 124 is advantageous.

[0055] The detachable battery 124 may be attached via magnetic locks to the hardware wallet 110. The housing and locking mechanism are described with additional detail below with regards to FIGs. 2A-2C. The detachable battery 124 is connected to the hardware wallet 110 via an angled connector. This angled connector allows for a secure connection to the detachable battery 124 without the use of additional locking tabs or other locking

mechanisms. The angled connector also provides a level of water resistance, and can be easily replaced if damage occurs. Additional details regarding the angled connector are described below with reference to FIGs. 3A-3C.

[0056] The anti-tamper circuit 126 is a circuit that detects whether the hardware wallet 110 has been physically tampered with. In one embodiment, the anti-tamper circuit 126 includes one or more circuits located on the interior of the housing of the hardware wallet 110. If the hardware wallet 110 is opened or tampered with, the anti-tamper circuit 126 maybe activated, e.g., it may become an open circuit due to a gap in the circuit caused by the opening of the housing of the hardware wallet 110. In such a case, the hardware wallet 110 may know that tampering has occurred, and can respond accordingly, such as by entering the safe mode described above. The anti-tamper circuit 126 may include other features, in addition to or in place of the one described above. For example, the anti -tamper circuit 126 may detect an amount of ambient light entering the housing, may use infrared sensors to detect changes in the dimensions of the interior of the housing, may use a switch to detect an opening of the housing, may detect the intrusion of external electromagnetic fields due to the opening of the housing, and so on. In any of these types of anti-tamper circuits 126, any physical tampering with the hardware wallet 110 by attempting to open the hardware wallet 110 may trigger the anti -tamper circuit 126 and indicate the hardware wallet 110 has been tampered.

[0057] Although some aspects of the above description were made in relation to a distributed ledger, the hardware wallet 110 described here may be used for storing of any cryptographic keys or other secure information, and is not limited to the field of distributed ledger transactions.

Client Device and Wallet Interface Application

[0058] The client device 130 may interface with the hardware wallet 110 via the use of matrix barcodes. The client device 130 may be any type of computing device, such as a wearable, smart home device, PC, tablet, or smartphone. The client device 130 includes an imaging device 132, display 138, and in some embodiments a user authenticator 134. The client device 130 also includes a wallet interface application 136 to make requests to the hardware wallet 110 for processing data using the cryptographic keys stored in the hardware wallet 110. There is not electrical connection or communication, wireless or otherwise, between the client device 130 and the hardware wallet 110. Instead, data is transferred between the hardware wallet 110 and the client device 130 solely via matrix barcodes or via the user. This“air gap” affords the hardware wallet 110 a certain level of security against malicious attackers which may attempt to attack the hardware wallet 110 via the network 110.

[0059] The imaging device 132 is a camera or other device capable of capturing the matrix barcodes presented by the hardware wallet 110. The imaging device 132 may be integrated into the hardware of the client device 130, such as in the case of a smartphone camera, or may be a separate component that can be connected to the client device 130. The imaging device 132 may be capable of capturing the matrix barcodes at a sufficient resolution and/or quality in order to have the matrix barcodes be decoded, and at a frequency that exceeds the barcode refresh frequency.

[0060] The display 138 is a component of the client device 130 that presents matrix barcodes for the hardware wallet 110 to scan. In addition, the display 138 presents the interface provided by the wallet interface application 136, and the interface for other functions of the client device 130, e.g., a graphical user interface provided by the operating system of the client device 130. The display may be similar to the display 118 of the hardware wallet 110.

[0061] The user authenticator 134 generates authentication data to allow the user to authenticate themselves with the client device 130, and in some cases with the hardware wallet 110. As noted above, the authentication data may include one or more methods of biometric scanning and or secret-based authentication. The biometric scanning may include any of the biometric scanning options described above for the hardware wallet 110. For example, the user authenticator 134 may include a fingerprint scanner, iris scanner, or face scanner, and may also be a password, pattern lock, or PIN lock system.

[0062] The wallet interface application 136 is a software package executing on the client device 130 that interfaces with the hardware wallet 110 using matrix barcodes in order to execute requests made by a user. This may include a factory setup process when the hardware wallet 110 is in a factory state, as well as other requests when the hardware wallet 110 is in a normal state.

[0063] During the factory setup process, the wallet interface application 136 may request that the user choose an authentication method. Once selected, the user provides the authentication data matching this method to the user authenticator 134, and the wallet interface application 136 may transmit this information to the hardware wallet 110 for storage via matrix barcodes. Alternatively, during the factory setup process, the wallet interface application 136 may instruct the user to input the authentication data directly into the hardware wallet 110 via the input 122. During the factory setup process, the wallet interface application 136 may also ask the user for the seed value and any other data that the user may wish to store in the hardware wallet 110. This information may be transmitted to the hardware wallet 110 via matrix barcodes. Subsequently, the wallet interface application 136 transmits a request to the hardware wallet 110 to enter a normal state.

[0064] In the normal state, every time the user wishes to perform a request against the hardware wallet 110, the user may first provide an input to the hardware wallet 110, e.g., via the input 122, to notify the hardware wallet 110 to start scanning for matrix barcodes. The wallet interface application 136 may request user authentication from the user authenticator 134 each time the user wishes to perform a request. The authentication data received from the user authenticator 134 may be combined with the data to be processed for the request and is sent to the hardware wallet 110 via matrix barcodes. For example, the authentication data may be used to sign or encrypt the data to be processed for the request, along with the instructions for the request, and this combined data may be transmitted to the hardware wallet 110 to execute the request. The hardware wallet uses stored authentication data verify that the data received is authenticated. Alternatively, this authentication data is entered into the hardware wallet directly before any data is received from the wallet interface application 136.

[0065] The requests from the wallet interface application 136 to the hardware wallet 110 may include an instruction, data to be processed, and/or the authentication data. As noted above, the hardware wallet 110 may support various requests. For example, the hardware wallet 110 may support a request to insert a newly generated public key into and to sign a chunk of transaction data for the distributed ledger 150 with a newly generated corresponding private key, and to output the signature and the modified transaction data. Such a request would involve the wallet interface application 136 presenting a series of matrix barcodes to the hardware wallet 110 encoding the input instructions of the request and the data to be processed, and the hardware wallet 110 presenting a series of matrix barcodes encoding the output.

[0066] The wallet interface application 136 may provide a graphical user interface to instruct the user on the above steps. The wallet interface application 136 forms the instructions for the request and the data to be processed by the hardware wallet 110 automatically based on parameters set by the user via the graphical interface. The wallet interface application 136 communicates with the wallet server system 140 or search the distributed ledger 150 (directly or via a cached copy) to request data that may be used as part of a request.

[0067] In one embodiment, the wallet interface application 136 receives an input from the user to determine the user’s total balance of accounts in the distributed ledger 150. The wallet interface application 136 may transmit a request to the hardware wallet 110 (via matrix barcodes) for a master public key. The wallet interface application 136 generates child public keys using the master public key (using a standard cryptographic protocol, such as HMAC- SHA), and transmits batches of such addresses to the wallet server system 140, which responds with a balance for these addresses. This process may be repeated until no new child public addresses with balances can be found. Additional details regarding this process are described below with reference to FIG. 8A-8B and with reference to the wallet server system 140.

[0068] In one embodiment, the hardware wallet 110 also includes an option for a firmware upgrade. This may occur via the receipt of QR codes encoding encrypted and signed data which can then be verified and decrypted by the encryption layer 112 on the hardware wallet 110 and flashed to the firmware store of the hardware wallet 110.

Wallet Server System

[0069] The wallet server system 140 communicates with the wallet interface application 136 of the client device 130 to perform certain requests made by the user. In one

embodiment, the wallet server system 140 includes a ledger cache 142, an account balance calculator 144, and an account store 146. [0070] The ledger cache 142 is a cache/local copy of the distributed ledger 150. The contents of the ledger that has been cached in the ledger cache 142 has already be verified to be accurate (i.e., the validity of the transactions in the ledger have been verified using cryptographic functions according to the specification of the distributed ledger). The ledger cache 144 may store a cache of more than one system of distributed ledger (i.e., more than one type of cryptocurrency).

[0071] The account balance calculator 142 determines the balance of rounds of public addresses received from the wallet interface application 136 as part of an account balance computation request. Upon receiving a predetermined number of generated public addresses from the wallet interface application 136, the account balance calculator 142 may check the distributed ledger 150 or the ledger cache 142 for transactions having recipient public addresses matching one of the received addresses. The account balance calculator 142 may then determine whether that balance is still non-zero, after which it accumulates the total sum of the non-zero balances. This value, along with the public addresses associated with nonzero balances, may be stored in the account store 146 for the user associated with the wallet interface application 136 which created the request. This value is returned to the wallet interface application 136. Additional details regarding this account balance computation process is described below with reference to FIGs. 8A-8B.

[0072] The account store 146 stores various account-related data for the distributed ledger 150. It may store a list of unspent balances in the distributed ledger 150, and may store unspent balances for users who are registered with the wallet server system 140, or who have interfaced with the wallet server system 150 using the wallet interface application 136.

It may store other user information, such as user login data, which may be used by users to login to a web interface of the wallet server system 140 to manage account information, access customer service, or perform other requests.

Distributed Ledger and Network

[0073] The distributed ledger 150, as noted above, may be any type of network where data is distributed across multiple computers, and where the authenticity of the ledger may be verified using cryptographic functions and developed by a consensus of users. Examples of such distributed ledgers include various cryptocurrencies. In a cryptocurrency system, nodes in a distributed network for the cryptocurrency select user transactions or other data (e.g., executable bytecode such as smart contracts) from an unverified pool and attempt to place them into blocks in a block chain, which is a ledger recording all transactions for the cryptocurrency. Blocks are added to a globally distributed block chain by nodes in the system which complete a proof of work (or proof of stake) operation. Typically, the proof of work operation comprises the brute force selection of a nonce which, when combined with data from the previous block in the chain, along with the transactions selected for the current block, can be hashed using a specific hash function (e.g., SHA) to generate a hash value that meets a target difficulty level (e.g., has a certain number of leading zeros in the hash). The nodes which find the proper nonce the fastest receive the opportunity to add their block to the block chain, and to receive as compensation a transaction fee or newly generated units of the cryptocurrency. Examples of cryptocurrencies include Bitcoin, Ethereum, Litecoin, Monero, Ripple, Zcash, Dogecoin, and so on.

[0074] The network 110, which can be wired, wireless, or a combination thereof, enables communications between the client device 130 (or client devices), the distributed ledger 150, and the wallet server system 140, and may include the Internet, a local area network (LAN), virtual LAN (VLAN) (e.g., with VPN), wide area network (WAN), or other network. In one embodiment, the network 110 uses standard communications technologies and/or protocols, such as Hypertext transfer Protocol (HTTP), Transmission Control Protocol/Intemet Protocol (TCP/IP), Uniform Resource Locators (URLs), and the Doman Name System (DNS). In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.

HARDWARE WALLET DETACHABLE BATTERY LOCKING MECHANISM

[0075] FIG. 2 A illustrates two views of the hardware wallet 110 with detachable battery

124 attached and detachable battery 124 removed, according to an embodiment.

[0076] The hardware wallet 110 includes a detachable battery 124 as shown in FIG. 2A. FIG. 2A presents both a view of the hardware wallet 110 with detachable battery 124 attached, and the hardware wallet 110 with the detachable battery 124 removed. As can be seen when the detachable battery 124 is removed, the hardware wallet 110 includes an excavated portion 208 which is of the same size as the detachable battery 124. When the detachable battery 124 is placed in the hardware wallet 110, the exterior surface of the hardware wallet 110 is flush, i.e., continuous, with the exterior surface of the hardware wallet 110. This creates a smooth and visually appealing device, and can allow for a water resistant or waterproof seal between the detachable battery 124 and the hardware wallet 110. This is in contrast to a device whereby the battery is inserted into the system, with an external cover that is locked over the battery, which is less visually appealing as it needs a locking mechanism, is more difficult to remove and replace, and may not be water resistant. In addition, as the detachable battery 124 can degrade over time, while the hardware wallet 110 does not need to be frequently upgraded as it only acts as a key store, it is advantageous to be able to replace the battery once it reaches a certain degraded level. FIG. 2A also shows the imaging device 120 of the hardware wallet 110, as well as the angled connector 206 to couple the electrical connections of the detachable battery 124 to the hardware wallet 110.

[0077] FIG. 2B illustrates the detachable battery 124 with magnetic locks 202, according to an embodiment. The magnetic locks are distributed near the perimeter of the detachable battery 124, along the surface of the detachable battery 124 which will make contact with the hardware wallet 110 when connected to the hardware wallet 110. For example, the magnetic locks 202 are located a maximum of 2cm from the perimeter of the detachable battery 124, or are located a 5% of the total width/length of the detachable battery from the perimeter. The magnetic locks 202 may be distributed such that each magnetic lock is at least a threshold distance (e.g., lOcm) from each other. Although for magnetic locks 202 are illustrated, in other embodiments the detachable battery 124 may have a greater or fewer number of the magnetic locks 202.

[0078] Each magnetic lock may have a sufficient grade and dimensions such that the combined holding force of the magnetic logs 202 cause the detachable battery 124 to stay adhered to the hardware wallet 110 after an impact of a specified force. For example, if the hardware wallet 110 were approx. l50g, when dropped from lm, the impact force would be approx. 14 N (on a hard surface). Therefore, the holding force should exceed this impact force. This could be achieved, for example, by six rare earth magnets each with a holding force of 2.3 N. The size of these rare earth magnets may be approx. 1.5cm x 1 cm x .5 cm each (with a grade of N45). Note that this is just an example configuration, and the magnetic locks 202 may be configured in any other configuration to produce a sufficient holding force between the hardware wallet 110 and the detachable battery 124.

[0079] The magnetic locks 202 may be made of any material capable of producing a magnetic field, including permanent magnets, such as composite (e.g., ferrite), rare earth (e.g., neodymium), and electromagnets.

[0080] The magnetic locks 202 may be slightly depressed within the casing of either the detachable battery 124 or the hardware wallet 110 so as to prevent damage to the magnetic locks 202. In addition, the magnetic locks 202 on either the detachable battery 124 or on the hardware wallet 110 may be able to move along an axis passing through both the hardware wallet 110 and the detachable battery 124. Therefore, when the detachable battery 124 is attached to the hardware wallet, the magnetic locks 202 on the detachable battery 124 may move towards counterpart magnetic locks on the hardware wallet 110. The magnetic locks 202 may further protrude from the surface of the detachable battery 124 in this case and fit within shallow extrusions within the hardware wallet 110. This may allow the magnetic locks 202 to further act as a physical locking mechanism to lock the detachable battery 124 to the hardware wallet 110.

[0081] In addition to the magnetic locks 202, the detachable battery 124 includes an attachment track 204. The attachment track 204 may be used to guide the battery along the surface of the hardware wallet, such that it can slide into the angled connector 206 of the hardware wallet 110 without being physically impeded due to a mismatched angle between the angled connector 206 and the opening for the angled connector 206 in the detachable battery 124. The attachment track 204 may include a tongue that extends for the length of the attachment track 204, and which fits in a groove in a complementary track in the hardware wallet 110, or vice versa. The tongue may be coated with a low friction material (e.g., Teflon). Such a groove and tongue assembly may help to further secure the detachable battery 124 to the hardware wallet 110. Alternatively, the attachment track 204 may include a ball bearing rail which may attach to a complementary rail on the hardware wallet 110. The attachment track 204 may also contain a sealant or other rubberized or water-resistant material. This allows the attachment track 204 to serve as a means of aligning the detachable battery 124 during install, to secure the detachable battery 124 to the hardware wallet 110, and to act as a water resistant barrier. Although various features of the attachment track 204 are described here, they may not all be present at once.

[0082] FIG. 2C illustrates the hardware wallet 110 with magnetic locks to attach to the detachable battery 124, according to an embodiment. The hardware wallet 110 includes both magnetic locks 212 on the larger horizontal surface to which it contacts the detachable battery 124 when installed, and magnetic locks 210 on a smaller vertical edge which includes the angled connector 206, to which the detachable battery 124 is connected. The complementary edge of the detachable battery 124 also contains magnetic locks that couple to the magnetic locks 210. The magnetic locks 212 and 210 may be similar to the magnetic locks 202 of the detachable battery 124. In one embodiment, they are made of a different material than the magnetic locks of the detachable battery 124. For example, while the magnetic locks 202 of the detachable battery 124 are made of a permanent magnet, the magnetic locks of the hardware wallet 110 may be made of a ferrous metal (e.g., stainless steel), as the metal is more durable compared to the magnets. [0083] The hardware wallet 110 also includes the attachment tracks 214. These attachment tracks 214 have a complementary shape to the attachment tracks 204 of the detachable battery 124, such that the attachment tracks 204 of the detachable battery conform or mesh in physical shape with the attachment tracks 214 of the hardware wallet 110.

[0084] The detachable battery 124 (or hardware wallet 110) may have a button or other interface mechanism which, when pressed or interacted with, unlocks the magnetic locks of the detachable battery. As noted above, the magnetic locks 202 of the detachable battery 124 may have limited movement. By pressing the button, these magnetic locks 202 may be caused to move into the detachable battery 124, causing the holding force between the detachable battery 124 and the hardware wallet 110 to decrease and allowing easy removal of the battery. The button or other mechanism, when interacted with, may also physically push the battery away from the angled connector 206 to allow for easy removal. The detachable battery 124 may include a grip or other textured material as well to allow for easy removal of the detachable battery from the hardware wallet 110.

[0085] Although magnetic locks are described here, in other embodiments the detachable battery 124 may be attached to the hardware wallet using other locking mechanisms, such as a physical clip with unlock tab on the exterior surface of the detachable battery 124.

Alternatively, the detachable battery may have physical latches which slide into slit or gap on the hardware wallet 110.

ANGLED CONNECTOR FOR A DETACHABLE BATTERY

[0086] FIG. 3 A is a cutaway view of the hardware wallet 110 with an angled connector 302 to attach the detachable battery 124 to the circuit board 316 of the hardware wallet 110, according to an embodiment. The angled connector 302 is used to electrically couple the detachable battery 124 to the hardware wallet 110, as well as to physically secure the detachable battery 124 to the hardware wallet 110.

[0087] The angled connector 302 fits with tight tolerances into an opening in the compartment of the detachable battery 124. This, along with the locks described with reference to FIG. 2A-2C, help to secure the detachable battery to the hardware wallet 110. Additionally, the tight tolerances increase the water resistance of the hardware wallet 110, prevent water from contacting any of the electrical contacts of the angled connector 302. The angled connector 302 may further include waterproofing modifications, such as a having a gasket at the point where it contacts the detachable battery 124. This is in contrast to a battery contact design where the battery simply couples to a device using contact plates. Such a design can commonly be seen in mobile phones with removable batteries. These contact plates do not help to secure the battery, and are not water resistant, easily allowing water ingress and potential electrical short circuit risks.

[0088] The angled connector 302 is not soldered to the circuit board 316. Instead, it is attached via various locking mechanisms, which will be described below, and is coupled to the circuit board 316 via a spring contact 312. This allows it to be easily removed and replaced without having to replace the circuit board 316 itself. As cryptographic keys are stored on the encryption layer, which may reside as an encryption chip on the circuit board 316, replacing the circuit board 316 would involve a complicated transfer of data from the encryption chip, and may result in loss of data, leakage of data, and other security vulnerabilities. As connection to the battery is subject to the most physical forces in the hardware wallet 110, the connector is the most likely component to fail, and so having a modular connector is advantageous.

[0089] The angled connector 302 is connected to the detachable battery 124 via pogo pin contacts 304. The male pogo pin contacts 304 may be placed on the detachable battery 124, with the angled connector 302 including the female contact points. These pogo pin contacts 304 allow for continuous contact between the detachable battery 124 and the angled connector 302 even if the detachable battery 124 is moved slightly, such as during an impact event, or as part of normal use. A ground pin on the pogo pin contact 304 may extend slightly longer than a power pin, to allow a ground to be contacted first, before the power is contacted.

[0090] The detachable battery may be charged using a charging device that also includes an angled connector 302.

[0091] Although the angled connector 302 is shown to have a circumference that is smaller at the point where it may be inserted into the detachable battery 124, the exact shape and size of the angled connector 302 may vary depending upon the type of opening in the detachable battery 124, as well as the number of electrical contacts that are needed. Each electrical contact in the angled connector 302 may be transmitted through a separate wire, with each wire being parallel to each other along a plane that curves in the direction of the bend of the angled connector 302. Although two electrical contacts are shown here, more contacts (e.g., for battery health data communication, etc.) may also added to the angled connector 302. Although the angled connector 302 has a bend of 90 degrees in FIG. 3 A, in other embodiments the angle may differ, depending on the configuration of the circuit board and the detachable battery. [0092] The angled connector 302 may be made of any polycarbonate, plastic, metal, or other durable material that does not easily deform due to physical forces, temperature, and/or moisture.

[0093] FIG. 3B is an exploded view of the hardware wallet 110 with components of the angled connector 302, according to an embodiment. Here, the angled connector 302 is secured to the hardware wallet housing 306 of the hardware wallet 110 via a restrictor plate 308, which abuts the angled connector 302 on the opposite side the angled connector 302 at which it contacts the detachable battery 124. The restrictor plate 308 prevents a lateral movement of the angled connector 302. This allows a user to exert a significant force upon the detachable battery 124 and the angled connector 302 when installing the detachable battery 124 without the angled connector 302 moving. The restrictor plate 308 may be metal, plastic, or other material that has a high yield strength. As shown, restrictor plate 308 makes contact with a large surface area of the angled connector 302. The restrictor plate 308 is secured to the hardware wallet housing 306 via the locking pins 310, which may be screws or other fasteners. Although two locking pins 310 are shown, additional locking pins may be included, and additional restrictor plates 308 may also be used.

[0094] FIG. 3 C is an alternative exploded view of the hardware wallet with components of the angled connector, according to an embodiment. FIG. 3C shows a profile view of the components shown n FIG. 3B. As can be more clearly seen, the restrictor plate 308, which is to be fastened to the case via the locking pins 310, restricts the movement of the angled connector 302. The angled connector 302 is placed through the opening 314, and can be electrically coupled to the detachable battery 124. The angled connector 302 includes the spring contacts 312, which are used to electrically couple the angled connector 302 to the circuit board 316 (not shown).

CASE WITH GUIDED RELEASE MECHANISM

[0095] FIG. 4A is an exploded view illustration of a case 400 for the hardware wallet 110 with guided release mechanism, according to an embodiment. This case 400 may be used to house the hardware wallet 110 and detachable battery 124. The case 400 includes an ingress cover 402, an internal frame 406, rails 410, a support structure 412, a spring 408, a main housing 414, and a rear cover 404. Although a certain number, order, and design of the components are shown here, in other embodiments, the number of each component, order of assembly, and design may differ. The materials used in the case 400 may include any plastic, metal, or other durable material. [0096] The ingress cover 402 has a cross sectional profile that is slightly larger than the cross sectional profile of the hardware wallet 110. In particular, the ingress cover 402 is a frame through which the hardware wallet 110 may pass to be placed in the case 400, and therefore the cross section of the interior hollow portion of the frame of the ingress cover 402 should be at least the size of the hardware wallet 110. The ingress cover 402 may include two (spring loaded) flaps which open inwards to the interior of the case 400. When the hardware wallet 110 is inserted, the flaps are pushed aside to allow for entry of the hardware wallet 110. The flaps will be described with more detail below with reference to FIG. 4B.

[0097] The internal frame 406 has a width that is the same as the width of the ingress cover 402, and is larger than the width of the hardware wallet 110. The internal frame 406 may be a flat plane of material, with a cut out section matching the top portion of the support structure 412 as shown. The combined length of the internal frame 406 with the support structure 412 placed within the cutout section may be equal to or less than the length of the hardware wallet 110. However, the length of the case 400 as a whole may be greater than the length of the hardware wallet 110. Additional details for the internal frame 406 will be described below with reference to FIG. 4C.

[0098] The rails 410 are connected to opposite sides of cutout section of the internal frame 406, at the end of the internal frame 406 that is opposite the ingress cover 402.

Although two rails 410 are shown, greater or fewer number of rails may be used in other embodiments. The rails 410 may be coated with a low surface energy material, such as Teflon, or may use other methods, such as ball bearings, to lower the friction of the surface of the rails 410.

[0099] The support structure 412 is a structure that supports the hardware wallet 110 when placed in the case 400. The support structure 412 includes a flat planar section that is in the same plane as the internal frame 406. The support structure 412 also includes, at a point opposite to the ingress cover 402, a planar platform that is orthogonal to the flat planar section. The hardware wallet 110 and detachable battery 124 may rest upon this orthogonal platform when placed in the case 400. The support structure 412 has channels 422 that enclose portions of the rails. These channels 422 may be chamfered or beveled at their ends. The tolerance between the diameter of the rails 410 and the interior diameter of the channels 422 may be very small. These features allow the channels, and thus the support structure 412, to smoothly traverse along the rails 410.

[00100] The spring 408 provides a force in the direction of the ingress cover 402 when the support structure 412 is moved in a direction opposite the ingress cover 402. The spring 408 is attached on one end to the internal frame 406, and on another end to the support structure 412. When the main body of the hardware wallet 110 is placed in the case 400, the act of pushing the hardware wallet 110 into the case 400 causes a force to be exerted upon the support structure 412, which causes hardware wallet 110 to move towards the rear cover 404 of the case 400. However, the further the support structure 412 moves, the stronger the force exerted by the spring 408 in the opposite direction. When the user decides to remove the hardware wallet 110, the user opens up the case 400 at the ingress cover, and the spring 408 exerts a force upon the support structure 412 to cause it to move along the rails towards the ingress cover 402, and allows the user to easily remove the hardware wallet 110. In contrast to other systems, which only have a compressed spring push a component out of a

compartment, the use of the rails 410 allows for a smooth motion to the support structure 412, reducing the chance that the hardware wallet 110 would be pushed at a slight angle out of the case 400, which may cause the hardware wallet 110 to jam within the case. Although a single spring 408 is shown here, multiple springs may be used. In addition, the spring 408 may be comprised of various materials, such as metal, rubber, polymer, and could be of many types, such as an elastic band, a leaf type spring, a gas spring, and so on.

[00101] The main housing 414 covers the entire case 400, and protects it from the outside environment. It is attached to the ingress cover 402. It may also have sufficient structural resistance to survive after a typical drop. The main housing 414 may be coated on the exterior with a water resistant coating and/or shock adsorbing materials, such as rubber.

[00102] The rear cover 404 covers the rear of the case 400, and is attached to the main housing 414. It may be similar in cross section to the ingress cover 402, but includes no flaps or any method of being able to access the inside of the case 400.

[00103] FIG. 4B is an isometric exploded view illustration of the casing with guided release mechanism for the hardware wallet showing the interior of the case, according to an embodiment.

[00104] The ingress cover 402 is shown in FIG. 4B with flaps 426. Each flap 426 has a width that is the same as the ingress cover 402, has a length that is not the full length of the ingress cover 402. In one embodiment, one of the flaps 426 has a length that is a thickness of the hardware wallet 110, and the other flap 426 has a length equal to the thickness of the detachable battery 124. The flaps 426 are hinged on opposite sides of the ingress cover 402, and open into the case 400. The flaps 426, in combination with the inner frame of the ingress cover 402, may be coated or have a seal or gasket such that the flaps 426 resist the ingress of water when they are closed. The flaps 426 may lock in place when closed, and may unlock by a mechanical switch on the case 400. The flaps 426 may also lock in place via magnetic locks.

[00105] The ingress cover 402 is attached to the main housing 414 using fasteners 418. Although two fasteners 418 are shown, in other cases the number of fasteners 418 may differ. In another embodiment, no fasteners are used, and instead the ingress cover 402 is glued or welded to the main housing 414 to improve water resistance. The same applies for the fasteners 420 of the rear cover 404.

[00106] As shown more clearly in the isometric view of FIG. 4B, the support structure 412 has channels 422 that enclose portions of the rails 410. The orthogonal platform 424 of the support structure 412 can also be more clearly seen. This orthogonal platform 424 is the platform upon which the hardware battery 110 rests.

[00107] The main housing 414 interior may include multiple guides, notches, grooves, and other components in order to attach the internal frame 406, rails 410, and other components securely to the main housing 414. The main housing 414 may include a groove which is of the correct shape allow the long sides of the internal frame 406 to fit into. This secures the internal frame 406 from moving within the main housing 414. The main housing 414 may include additional guides to fit the hardware wallet 110 when the hardware wallet 110 is inserted.

[00108] FIG. 4C is an alternative isometric exploded view illustration of the casing with guided release mechanism for the hardware wallet showing the exterior of the case, according to an embodiment. In FIG. 4C, the hardware wallet 110 and detachable battery 124 can be seen in the exploded view. The hardware wallet 110 is inserted into the case 400 on one side of the internal frame 406, while the detachable battery 124 is inserted on the other side. The support structure 412, interior of the main housing 414, and/or the internal frame 406 may have one or more locking mechanisms, such as a magnetic lock, to lock the hardware wallet 110 or detachable battery 124 in place when they are inserted, and a switch or other means of releasing the locks. When the user opens the case 400, the flaps 426 in the ingress cover 402 may press against the hardware wallet 110 and detachable battery 124, causing them to be pushed further inside into the case 400. When the flaps 426 are moved to their most open positions, they may sit flush with the main housing 414, allowing for the hardware wallet 110 and detachable battery 124 to be removed from the case 400. At this point, the spring 408 causes the support structure 412 to push the hardware wallet 110 and detachable battery 124 towards the ingress cover 402. A portion of the hardware wallet 110 and detachable battery 124 may emerge from the case 400 as well. The movement of the hardware wallet 110 and detachable battery 124 out of the case 400 is smooth, and they do not become jammed within the case 400, as the motion of the support structure 412 is controlled via the rails 410.

[00109] The separation of the hardware wallet 110 and the detachable battery 124 prevents the battery from leaking or causing damage to the hardware wallet 110. It reduces drain on the detachable battery 124. Furthermore, as the hardware wallet 110 is unpowered while in the case 400, it is less vulnerable to side-channel attacks against the electronics of the hardware wallet 110 (e.g., via detection of coil whine, etc.). The main housing 414 may also include a metallic shield to help prevent against such attacks.

WEB BASED AUTHENTICATION PROCESS TO PROTECT AGAINST SUPPLY CHAIN ATTACK OF A HARDWARE WALLET

[00110] FIG. 5A is a transactional diagram illustrating a method of verifying the integrity of the hardware wallet on initial use, according to an embodiment. Although the operations are illustrated in a particular order in FIGs. 5A-5D, this is not to imply a particular order of operations in practice. In addition, the operations may be performed by elements that differ from those which are illustrated.

[00111] During an initial setup of the hardware wallet 110, such as when the hardware wallet 110 is in the factory mode, the hardware wallet 110 may require that the user proceed through a web based authentication with the wallet server system 140. The user may be instructed to open a web authentication resource of the wallet server system 140, either via a web browser, or via the wallet interface application 136. For example, the web

authentication resource may be a web page served by the wallet server system 140, or an interface within the wallet interface application 136. The user uses the information provided in the web authentication resource, along with the hardware wallet 110, to verify the integrity of the hardware wallet 110, i.e., that the hardware wallet 110 has not been tampered with prior to being received by the user. This tampering may include a supply chain attack, where a malicious attacker intercepts the hardware wallet 110 product before it reaches the user, and performs a malicious modification with it. For example, the malicious attacker may reprogram the hardware wallet 110 to disable the encryption layer 112 and to generate private keys which are not secret but which are known by the malicious individual. The following transactional diagrams present different embodiments of methods to authenticate the hardware wallet 110 via the wallet server system 140 to determine whether the hardware wallet 110 is genuine or has been potentially tampered with. [00112] Referring to the transactional diagram in FIG. 5A, the wallet server system 140 generates 502 a random number. This may be in response to a request from the user to begin a web authentication process. The random number may be of suitable length, e.g., 32 bits. The wallet server system 140 encrypts 504 this random number with the wallet public key. The wallet public key is part of a key pair which is stored on the hardware wallet 110 within the encryption layer at the time of manufacture. The wallet key pair may use any asymmetric key pair standard, such as an ECDSA or RSA key pair. The encryption algorithm may be any asymmetric encryption scheme, such as RSA or ElGamal. The wallet server system 140 signs 506 the encrypted random number with the server’s private key to generate a digital signature. The digital signature may be generated using any standard digital signature method, such as by generating an RSA key pair. The wallet server system 140 generates 508 a matrix barcode, such as a QR code, with the encrypted random number and the digital signature, and presents this to the user at the web authentication resource. This may be either a web page, the wallet interface application 136, or other method of displaying a matrix barcode.

[00113] The displayed matrix barcode 510 is scanned 512 by the hardware wallet 110.

The hardware wallet 110 verifies 514 the digital signature with the server’s public key, which may be stored in the encryption layer of the hardware wallet. This verification may be performed by requesting a signature verification from the encryption layer using the stored public key. If this generates an error, the hardware wallet 110 may abort and enter the safe mode, or present an alert to the user. If the verification is successful, the hardware wallet 110 decrypts 516 the encrypted random number with the wallet’s private key, stored in the encryption layer. The hardware wallet 110 presents 518 the now decrypted random number to the user. The wallet server system 140 also presents 520 the random number to the user at the web authentication resource. The user may now verify if both of these random numbers match. If they do, this means the hardware wallet 110 has not likely been tampered with. However, if the numbers do not match, then it may be possible that the hardware wallet 110 has been compromised, as the hardware wallet 110 was not able to use the correct wallet private key to decrypt the random number. This may indicate that the hardware wallet 110 is not properly accessing the encryption layer 112, and implies that potential tampering has occurred. The user may then be allowed to put the hardware wallet 110 in safe mode, and/or to notify the wallet server system 140 that the hardware wallet 110 presented a non-matching random number. [00114] FIG. 5B is a transactional diagram illustrating a device serial number specific method of verifying the integrity of the hardware wallet on initial use, according to an embodiment. In contrast to FIG. 5A, the method shown in FIG. 5B uses a separate wallet private key for each hardware wallet 110. Initially, the wallet server system 140 receives 522 the serial number of the hardware wallet 110. The serial number may be input by the user, or may be input by scanning a matrix barcode encoded with the serial number and provided by the hardware wallet 110 (and scanned by the wallet interface application 136 using the imaging device 132). The wallet server system 140 encrypts 524 a randomly generated number with the serial number (SN) specific wallet public key, and signs 526 the encrypted number. The wallet server system 140 generates 528 the matrix barcode with the encrypted number and signature for transmission to the hardware wallet 110 via a display.

[00115] The displayed matrix barcode 530 is scanned 532 by the hardware wallet 110.

This allows the hardware wallet to receive the encrypted random number and the digital signature encoded within the matrix barcode. Similar to the method in FIG. 5A, the hardware wallet 110 verifies 534 the digital signature, and decrypts 536 the encrypted number, but with a SN-specific wallet private key. This decrypted random number is presented 538 to the user. The wallet server system 140 also presents 540 the random number (not encrypted) to the user. The user may verify that the random numbers from the wallet server system 140 and the hardware wallet 110 match in order to determine that the hardware wallet 110 has not likely been tampered with.

[00116] FIG. 5C is a transactional diagram illustrating a shared key method of verifying the integrity of the hardware wallet on initial use, according to an embodiment. In contrast to FIGs. 5 A and 5B, a shared key is used in the method of FIG. 5C to encrypt the random number, instead of using an asymmetric key encryption scheme.

[00117] The wallet server system 140 generates 542 the random number. The random number is encrypted 544 by the wallet server system 140 using a shared key. This shared key may be any symmetric key, and any symmetric encryption scheme, such as AES may be used to encrypt the random number using the shared key. The shared key was stored in the encryption layer of the hardware wallet 110 at the time of manufacture. The wallet server system 140 generate 546 the matrix barcode (e.g., a QR code) with the encrypted random number encoded therein, and this displayed matrix barcode 548 is scanned 550 by the hardware wallet 110 to retrieve the encoded random number. The hardware wallet 110 decrypts 552 the encrypted random number with the shared key using the encryption layer 112, and presents 554 this decrypted random number to the user, while the wallet server system 140 also presents 556 the random number. The user may verify that the numbers match (or do not match), and take appropriate action.

[00118] FIG. 5D is a transactional diagram illustrating an encrypted shared key method of verifying the integrity of the hardware wallet on initial use, according to an embodiment. In contrast to FIG. 5A-5C, the random number is not encrypted by the wallet server system 140 in FIG. 5D before it is sent to the hardware wallet 110. Instead, the hardware wallet 110 encrypts the random number, and compares this result to an encryption of the random number made by the wallet server system 140.

[00119] The wallet server system 140 generates 560 a random number. The wallet server system 140 generates 562 a matrix barcode encoding this random number, and the displayed matrix barcode 564 with this encoded number is presented to the hardware wallet 110. The hardware wallet 110 scans 566 the matrix barcode to retrieve the random number, and encrypts 570 the random number with a shared key (using the encryption layer 112).

Meanwhile, the wallet server system 140 is also encrypting 568 the random number with the shared key. Both the wallet server system 140 and the hardware wallet 110 present 574 and present 752 the encrypted random number, respectively. A user may compare these numbers to determine whether they are the same. Note that the same encryption algorithm and parameters should be used in both the hardware wallet 110 and the wallet server system 140 to encrypt the random number.

HARDWARE WALLET BOOTSTRAP INITIATION AND SELF-CHECKING ANTI-TAMPER PROCESS [00120] FIG. 6A is a flow chart illustrating a self-check mechanism for the OS layer of the hardware wallet, according to an embodiment. Although the operations are illustrated in a particular order in FIGs. 6A-6B, this is not to imply a particular order of operations in practice. In addition, the operations may be performed by elements that differ from those which are illustrated.

[00121] During an initialization phase, the OS layer 114 and the encryption layer 112 may both perform a security self-check routine. This initialization phase may occur during power- up, as part of a power on boot process, as part of a power on self-test process, when the detachable battery 124 is inserted, or when the device is restarted. This initialization phase may also occur when requested by the user, or when a fault or other system fault is detected, e.g., if the anti-tamper circuit 126 is detected to have been opened. If any of these checks are unsuccessful, the hardware wallet 110 may enter a safe mode, and wipe all secret data, e.g., data stored in the key store 113. The check performed by the OS layer 114 is described in FIG. 6A, while the check performed by the encryption layer 112 is described in FIG. 6B.

The two checks may be performed simultaneously with each other, sequentially, or one check may be started with a slight time delay to the other check process. For example, the OS layer 114 check may begin earlier than the encryption layer 112 check.

[00122] The checking routine described here for the OS layer 114 may be stored in the boot partition of the OS layer 114. For example, if the OS is Android, then the routine may be stored in the“/init” folder in the boot partition, or may be stored as a portion of an initialization script, e.g.,“init.sh” within the boot partition. As the boot partition may be stored in read-only memory, or may have a checksum that is checked during the bootstrap process, it may not be able to be modified without causing a fault in the system. Therefore, any check routine stored in the boot partition may also not be easily modified.

[00123] The OS layer 114 check begins when the OS layer 114 receives 602 an initialization indication. At this point, the OS layer 114 determines 604 if the OS is rooted. The OS is rooted when non-privileged users in the OS may request access to privileged accounts (e.g.,“root access”) without the need for additional security checks, such as a password. The OS layer 114 may check for whether the OS has been rooted by checking if the“su” or superuser command is present in the OS. The OS layer 114 may use the command“which” to search for su, or search the various system and other file system paths (e.g., those listed in the PATH environmental variable) to determine if“su” is present. The OS layer 114 may also check to see if any“su” process has been initialized in the system using a process monitor. The OS layer 114 may also check to see if the build tags of the OS have been modified to indicate that it is rooted (e.g., build tags of“test-keys” in Android may indicate that root access is available). If any of these checks indicate that the OS has been rooted, the OS layer 114 may enter a safe mode and trigger an alert 612. In this safe mode, the OS layer 114 will not continue to boot up, and will restrict access to all functions. In the safe mode, the OS layer 114 may also instruct the encryption layer 112 to wipe any data from the key store 113. The OS layer 114 may also set an invalid flag or other indicator, which can be checked by the encryption layer 112. The OS layer 114 may also display an alert on the display 118 of the hardware wallet 110 indicate that safe mode has been entered, and may provide the reason for entering safe mode (e.g.,“root access detected”).

[00124] If the OS layer 114 does not detect that the OS has been rooted, the OS layer 114 continues the self-check process and checks to see if the application layer 116 application’s package name matches a stored name. The stored name may be a name stored in the boot partition. If the package name has been modified, it will no longer match the stored name, and this may indicate that tampering has occurred. The package name may also adhere to a specific format, based on the version, configuration, and other parameters given to the application layer 116. If the package name does not match, the OS layer 114 once again enters 612 safe mode and may transmit an alert (e.g.,“package name error”).

[00125] If no package name error is detected, the OS layer 114 generates 606 a signature for the application package of the application layer 116. The signature is a hash, digital signature, or other cryptographic function performed on the binary data of the application package. If the binary data of the application package has been changed, then the signature will also change. In one embodiment, the signature that is generated is the same type of signature used in the APK Signature Scheme for Android. In one embodiment, the OS layer 114 also generates a signature for the binary data of the entire OS.

[00126] The OS layer 114 determines 608 if the generated signature matches a stored signature. The stored signature may be stored in the boot partition, or may be stored as part of the metadata/manifest of the application package. The OS layer 114 may also verify the stored signature using a public key to ensure that has not been modified. For example, if the signature is stored within the application package itself, then it should be verified using the public key of the application package creator (e.g., the hardware wallet 110 manufacturer), and then the signature should be used to verify the binary data of the application package. If the generated signature does not match the stored signature, the OS layer 114 may once again enter 612 the safe mode and may generate an alert (e.g.,“package checksum failed”). In one embodiment, the OS layer 114 may also verify a signature of the entire OS with a stored signature.

[00127] If none of these checks results in any fault detected, the OS layer 114 will continue 610 the boot up sequence. For example, the kernel of the OS will proceed with booting up the operating system components.

[00128] FIG. 6B is a flow chart illustrating a self-check mechanism for the encryption layer of the hardware wallet, according to an embodiment. The encryption layer 112, e.g., in the encryption chip, also performs a self-check during an initialization phase. The routine for the self-check may be stored in a read-only memory portion of the encryption layer 112 and cannot be easily modified.

[00129] The encryption layer 112 initially receives 622 the initialization indication. This may be a message sent to the encryption layer 112, or may simply be the first electrical signal driven to the encryption layer 112 during power-up. [00130] The encryption layer 112 determines 624 whether an anti-tamper circuit, e.g., the anti-tamper circuit 126, has been modified. As noted above, the anti-tamper circuit 126 may be modified if it is in an open state, or if it detects any other type of tampering. For example, if the anti-tamper circuit 126 enters an open state when the hardware wallet 110 is tampered with, the encryption layer 112 may check the circuit to see if it is closed or open in order to detennine whether the anti -tamper circuit 126 has been modified.

[00131] If the anti-tamper circuit 126 has been modified, the encryption layer 112 wipes

636 all secret data. To wipe the secret data, the encryption layer 112 may erase any secret or sensitive data, such as the key store 113, with random values or zeroes. The encryption layer 112 may trigger an electronic fuse to prevent the key store 113 from being accessed. The encryption layer 112 may cause a circuit to be shorted to destroy the key store 113, may cause an overheat protection to be disabled and for the key store 113 circuity to be overheated and destroyed, or may perform any other operation to permanently destroy the secret data stored in the key store 113. This prevents access to the secret data by a malicious attacker. The encryption layer 112 also enters 638 a safe mode and may alert the OS layer 114. This safe mode may be similar to the safe mode of the OS layer 114, where all functionality, including all requests for encryption operations, is denied. The encryption layer 112 may alert the OS layer 114 as to what caused the trigger for the safe mode, and the OS layer 114 may cause this error to be displayed, while itself also entering safe mode. The encryption layer 112 may also set a flag indicating that it is in the safe mode.

[00132] If the anti-tamper circuit is not modified, the encryption layer 112 determines the current state of the encryption layer 112, i.e., the current state of the encryption chip. If the encryption layer 112 is in the factory state (as described above), the encryption layer 112 waits 634 on further setup instructions or indications from the OS and application layers. The encryption layer 112 may determine that it is in the factory state based on an indicated flag being set or not set (e.g., a factory state flag), when there are no user keys stored in the key store 113 (and the system is not in safe mode), and so on. After the initial set up process is completed, the encryption layer 112 may change any factory mode indicator or flag to indicate that the encryption layer 112 is no longer in the factory mode.

[00133] If the encryption layer 112 is in the safe mode state, the encryption layer 112 enters 638 the safe mode. The encryption layer 112 may determine that it is in a safe mode by checking the status of the key store 113 to see if it has been wiped or is accessible, by checking a safe mode flag or indictor, or by some other means. [00134] The encryption layer 112 may also determine that it is in the normal state

(otherwise known as the“wallet state”). It may determine it is in the normal state if it determines it is not in any of the other states, if a flag is set, or by some other means. If the encryption layer 112 determines that it is in the nonnal state, the encryption layer 112 executes 628 an OS status check routine. This may involve checking if the OS layer 114 self- check is successful, by, for example, checking whether the OS layer 114 has entered safe mode or not, whether the OS layer 114 has set an invalid flag or other indicator, and so on. Alternatively, this may involve performing a checksum, hash, signature verification, or other independent verification of the OS layer 114 components. The encryption layer 112 determines 630 whether the OS check is valid. If not valid (e.g., if OS is in safe mode or invalid flag set), then the encryption layer 112 wipes 636 the secret data and enters 638 the safe mode. Otherwise, if the check is valid, the encryption layer 112 notifies 632 the

OS/application layers that it is ready to receive requests.

AUTOMATED QR CODE TRANSFER OF DATA EXCEEDING QR CODE SIZE LIMITATIONS

[00135] FIG. 7 is a transactional diagram illustrating an automated QR code data transfer between the hardware wallet and a wallet interface application, according to an embodiment. Although the operations are illustrated in a particular order in FIG. 7, this is not to imply a particular order of operations in practice. In addition, the operations may be performed by elements that differ from those which are illustrated.

[00136] During the normal operation of the hardware wallet 110, as noted above, it may be necessary to transfer data to and from the hardware wallet 110. However, to ensure the security of the hardware wallet 110, an“air gap” is maintained between the hardware wallet 110 and any other computing system. This is achieved by removing any wireless or wired electrical communication means from the hardware wallet 110. Instead, the hardware wallet 110 communicates via matrix barcodes, such as QR codes. However, these matrix barcodes can only encode a limited amount of data per barcode, while the data that may need to be transferred, e.g., a distributed ledger transaction, may exceed the capacity of the barcode. For example, a Version 3 QR code may store approx. 61 alphanumeric characters, while a Bitcoin transaction may include 258 bytes or more, which corresponds to over 258 alphanumeric characters. Previously, in order to transfer such large amounts of data via QR codes or other matrix barcodes, a user would have to manually coordinate the transfer of the data via multiple barcodes. For each barcode, the user would have to interface with the sender and recipient devices to notify these devices to be ready to receive the next barcode, and then to display the next barcode, and then to wait for the barcode to be transferred. Each time, the user may have to move the sender and recipient device to one position to interface with them, and then to another position in order to transfer the barcodes. The user would also have to indicate that the transmission of all the barcodes is complete, after ensuring that every barcode is sent. This method is highly inefficient and very tedious for the user. Instead, the method presented here provides a means of automating the process, and for both the sender and recipient to have knowledge of whether the transmission has been completed.

[00137] Although the transactional diagram shown here is in relation to the hardware wallet 110 and the wallet interface application 136, in other embodiments the sender and recipient devices is different. In addition, although the transfer of data related to a distributed ledger for signing transaction data is shown here, in other embodiments other data is transferred between the sender and recipient. Furthermore, although the description below is made with regards to QR codes, any matrix barcodes may be used in this operation.

[00138] To perform this automated data transfer operation, the wallet interface application 136 may receive 702 an instruction to send the transaction data to the hardware wallet 110. The hardware wallet 110 may also receive 704 an instruction to receive transaction data from the wallet interface application 136. This transaction data may be the data that is to be transmitted to the distributed ledger 150, to be entered into the distributed ledger 150, for a transaction of cryptocurrency. The wallet interface application 136 generates, in response to the instruction, a sequence of one or more QR codes that encode the transaction data. The transaction data is divided into portions, with each portion being of a size that can be encoded into a QR code. Each QR code is encoded with one portion of the transaction data. Each QR code is also encoded with its sequence number as well as a total number of QR codes. Each QR code may also be encoded with unique transaction identifier for that sequence of QR codes (i.e., for that transaction). An initial QR code, or other QR codes in the sequence, may be encoded with metadata regarding the transmission, such as sender name, intended recipient, identification of an encryption key or encryption schema, time interval between displaying each QR code (i.e., a barcode refresh frequency), and so on. Finally, some of the QR codes in the sequence may be encoded with checksum data, to ensure that the data transmitted received using the QR codes is accurate. The version of QR code that is used may depend upon the hardware version of the hardware wallet 110 and the detail resolution that the imaging device of the hardware wallet 110 is capable of handling, as well as the QR code decoding capabilities of the hardware wallet 110. An imaging sensor with a higher resolution can capture a higher version of QR code. A higher QR code version can encode more data per code, but has more image detail as well. The hardware wallet 110, in response to receiving the instruction to receive transaction data, scans 706 for QR codes.

[00139] The wallet interface application 136, via the display 138 of the client device 130, displays the sequence of QR codes 710, which are received by the imaging device 120 of the hardware wallet 110. As noted, the initial QR code may include metadata regarding the transmission, including the interval between each QR code, as well as any encryption schema. The hardware wallet 110 may utilize this information to determine how often to scan for QR codes (e.g., it scans at a frequency corresponding to the time interval indicated). However, in some cases, no metadata is transmitted. In such a case, the hardware wallet 110 may continuously scan for QR codes, and record any new QR code that it detects.

[00140] As each QR code includes a sequence number and total number of QR codes in the transaction, the hardware wallet 110 can confirm 712 whether it has received all the QR codes in the sequence when it has recorded that it has QR codes that have encoded within them every sequence number up to the total number of QR codes. After the hardware wallet 110 detects that it has scanned a QR code that is the last QR code in the sequence, or after it does not detect any new QR codes for a set threshold time period (e.g., 10 seconds) it determines whether it has received all the QR codes in the sequence. If there are any missing sequence numbers, the hardware wallet 110 may request to the user (e.g., via the display 138) to request the QR codes using the wallet interface application 136. Alternatively, the hardware wallet 110 may present a QR code itself for the wallet interface application 136 to scan. This QR code encodes the sequence numbers that are missing. In response, the wallet interface application 136 may resend these QR codes.

[00141] The hardware wallet 110 may also check the checksum encoded in the QR codes to determine whether the decoded data from the QR codes, after being combined back together, is accurate. The hardware wallet 110 may use the checksum data to repair any errors, or request that some data be resent, using the method described above.

[00142] The hardware wallet 110 may verify some signature, or decrypt the data encoded in the QR codes, using a known public key of the wallet interface application 136, using a previously agreed upon shared key, or using some key that was encoded within the QR codes that were received. The hardware wallet 110 may also verify a transaction identifier, if present, in the QR codes, to determine whether the QR codes are all part of the same transaction, and may remove any QR codes that are not.

[00143] The hardware wallet 110 may have measured the interval between the display of each QR code by the wallet interface application 136. If that interval is measured not to be a regular interval, or does not match the interval indicated in the metadata that may be encoded in one of the QR codes, the hardware wallet 110 may reject the transaction as erroneous. The intervals between the display of each QR code may also vary based on a secret changing sequence (e.g., sequences from a pseudo random number generator initiated with the same seed) known to the wallet interface application 136 and the hardware wallet 110, and the hardware wallet 110 may determine if the intervals follow this sequence.

[00144] After receiving, validating, decoding, and optionally decrypting or authenticating the transaction data in the QR codes, the hardware wallet 110 generates a signature for the transaction data using a selected private key or a newly generated private key stored in the encryption layer 112 of the hardware wallet 110. The private key may be selected using data indicated in the QR code and selected by the user via the wallet interface application 136, or by a user using an input of the hardware wallet 110.

[00145] The hardware wallet 110 generates a sequence of QR codes 716 in the same fashion as the QR codes 710 generated by the wallet interface application, and displays them via display 118. The wallet interface application 136 (and specifically the imaging device 132 of the client device 130 upon which the wallet interface application 136 is executing) scans for the QR codes in the same fashion as the hardware wallet 110 scanning for the QR codes at 706. The wallet interface application 136 verifies 720 the successful receipt of the signature data, in a similar fashion to the way that the hardware wallet verified the displayed QR codes 710 from the wallet interface application 136. The wallet interface application 136 uses this signature with the transaction data to submit a transaction to the distributed ledger 150 for entry into the ledger (e.g., a blockchain).

[00146] In one embodiment, the communication between the sender and recipient using QR codes may be bi-directional (e.g., full duplex). In such a configuration, both the display and imaging devices of both the sender and recipient face each other, and so QR codes, or other matrix barcodes, can be continuously displayed and immediately scanned between the devices. This may allow for convenient and relatively fast transmission of data between two devices that have an air gap in-between them.

AUTOMATIC VERIFICATION OF PUBFIC KEY ADDRESS STATUS IN DISTRIBUTED LEDGER USING HIERARCHICAL DETERMINISTIC SEED

[00147] FIG. 8A is a transactional diagram illustrating a method of determining a balance associated with a hierarchal deterministic seed stored in the hardware wallet, according to an embodiment. Although the operations are illustrated in a particular order in FIG. 8, this is not to imply a particular order of operations in practice. In addition, the operations may be performed by elements that differ from those which are illustrated.

[00148] In order to check the account balances associated a user, a user may have to take the public key addresses associated with his or her own private key addresses and manually search the distributed ledger 150 ] for these addresses. The user will have to record the amounts of the transactions, and painstakingly determine whether any still have remaining balance. For a user using an hierarchical deterministic (HD) wallet (described above), this can become a very time consuming process as the user may have tens of thousands of key pair combinations that have been used. Furthermore, if the HD wallet was“lost,” i.e., the key pairs were destroyed, the user would have to regenerate the key pairs again using the HD wallet seed, and would have to iterate through many key pairs to ensure that no addresses go unaccounted for. The method described here uses the hardware wallet 110, wallet interface application 136, and the wallet server system 140 to automatically determine the user’s balance using only the seed value of the HD wallet.

[00149] The hardware wallet receives 710 an instruction (e.g., via the wallet interface application 136) to transmit the master public key associated with an HD wallet. The hardware wallet 710 encodes the master public key and displays it as a QR code (or other matrix barcode) for the wallet interface application 136 to receive. If more than one QR code is needed to transmit the key, a method similar to the one described above with reference to FIG. 7 may be used. The wallet interface application 136 has also received 804 an instruction to generate child public key addresses using the master public key.

[00150] The wallet interface application 136 generates 806 a round of (non-hardened) child public key addresses using the master public key, according to the specifications of the HD wallet (e.g., BIP 44 specifications). In general, the wallet interface application 136 may generate the child public keys by hashing the master public key with an index value (and other values) according to the algorithm specified by the HD wallet specifications. The number of child addresses that are generated each round may be specified by a parameter, and may be, for example, 10,000 addresses. The wallet interface application 136 transmits 808 the round of addresses as the transmitted addresses 810 to the wallet server system 140, which, as described below with reference to FIG. 8B, determines the remaining balances of these child addresses on the distributed ledger 150. These returned balances 812 are received by the wallet interface application 136.

[00151] The wallet interface application 136 continues to generate 814 an additional round of child addresses. These are child addresses that follow in sequence from the previously generated round. These addresses 816 are transmitted to the wallet server system 140, and balances 818 are returned. The wallet interface application 136 may generate 820 additional rounds of child addresses and transmit them to the server until the returned balance value is zero, which may indicate that no child addresses beyond the ones generated in the last round were used. The wallet interface application 136 displays 822 the sum of the total balance to the user. The wallet interface application 136 may also request from the wallet server system 140 the list of child addresses with balances, and display those to the user as well.

[00152] FIG. 8B is a continuation of the transactional diagram of FIG. 8 A illustrating a method of determining a balance associated with a hierarchal deterministic seed stored in the hardware wallet, according to an embodiment.

[00153] In FIG. 8B, the wallet interface application 136 has transmitted 808 the round of addresses 810 to the wallet server system 140. The wallet server system 140 searches the distributed ledger 150 (or the local ledger cache 144) to find transactions that have the child addresses as the recipient of the balance in the transaction.

[00154] The wallet server system 140 stores 826 the transaction amounts, along with the corresponding child addresses, and any additional metadata, such as the transaction ID, block number in which the transaction was found, etc., of the transactions in a local database.

[00155] The wallet server system 140 determines 826 which of the child addresses associated with these transactions still have balances that have not been used. To do this the wallet server system 140 may search the distributed ledger to see if the child address was used as a sender address for any other transactions. If so, these child addresses may no longer have a balance. These child addresses are removed from the local database.

[00156] The wallet server system 140 accumulates 830 the non-used transaction amounts from the remaining child addresses to generate a total balance. The wallet server system 140 transmits 832 this total balance to the wallet interface application 136 as the returned balance 818. As noted above, this process may be repeated for multiple rounds of child addresses, after which a total balance is shown to the user. The wallet interface application 136 may also request the individual child addresses that have balances, in which case the wallet server system 140 may return the data stored in the local database.

ADDITIONAL CONSIDERATIONS

[00157] The foregoing description of the embodiments has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Many modifications and variations are possible in light of the above disclosure. [00158] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments is intended to be illustrative, but not limiting, of the scope, which is set forth in the following claims.

Claims

WHAT IS CLAIMED IS: THE CLAIMABLE SUBJECT MATTER INCLUDES, BUT IS NOT LIMITED TO:

1. A cryptographic key store device, comprising:

an encryption chip to store one or more cryptographic keys;

a plurality of magnetic locks distributed on a first surface of an excavated section of the cryptographic key store device, the plurality of magnetic locks coupleable to a second plurality of complementary magnetic locks on a detachable battery, wherein the exterior surface of the detachable battery is continuous with an exterior surface of the key store device when the detachable battery is coupled to the key store device by the plurality of magnetic locks; and

two parallel attachment tracks formed on two opposite sides of the first surface, each attachment track coupleable to complementary tracks on the detachable battery, wherein the detachable battery is translatable along a longitudinal direction of the two parallel attachment tracks.

2. A connector, comprising:

a housing having a first mating surface and a second mating surface, the angle of the second mating surface different from the angle of the first mating surface; a plurality of electrically conductive channels formed within the housing, each

channel of the plurality of electrically conductive channels having an electrically coupleable connection point at the first mating surface and the second mating surface;

wherein each electrically coupleable connection point of the plurality of electrically conductive channels at the first mating surface is a pogo pin connector; and wherein each electrically coupleable connection point of the plurality of electrically conductive channels at the second mating surface is a spring connector.

3. A case, comprising:

a housing containing an opening and one or more cylindrical rails aligned in a

transverse direction to the opening, the cylindrical rails housed within one or more channels of a support structure, the support structure attached to an elastic member; and wherein the elastic member exerts an opposite force to the support structure when the support structure is moved in a direction away from the opening, the support structure capable of accepting a key store device and a detachable battery.

4. A case, comprising:

an ingress cover having a pair of hinged flaps, the hinged flaps hinged on opposite sides to a frame of the ingress cover;

an internal frame attached to the ingress cover, the internal frame being a planar

member with width equal to the width of the ingress cover, and length greater than the width;

a pair of rails attached to the internal frame at a position opposite to the ingress cover, the pair of rails spaced equally across a central axis of the internal frame;

a spring attached to the internal frame at the position opposite to the ingress cover; a support structure having a pair of channels located on opposite sides of the support structure, the channels enclosing portions of the pair of rails, wherein the support structure is coupled to the spring at a position nearest to the ingress cover, wherein the support structure comprises a planar surface along a same plane as the internal frame and an orthogonally aligned surface at a position opposite the internal frame, wherein the support structure is acted upon by the spring with an opposite force when the support structure is translated in a direction along the pair of rails away from the ingress cover;

a housing attached to the ingress cover and housing the internal frame, the pair of rails, the spring, and the support structure, wherein the housing has a cross-sectional profile that is the same as the ingress cover;

a posterior cover attached to the housing at a position opposite that of the ingress

cover; and

wherein the case is capable of housing a cryptographic key store device and a

detachable battery, the cryptographic key store device and detachable battery placed within the case via the ingress cover, the cryptographic key store device placed opposite a first surface of the internal frame and contacting the support structure, and the detachable battery placed opposite a second surface of the internal frame and contacting the support structure, wherein the cryptographic key store device and the detachable battery, when removed from the case, are moved at least a set distance due to the opposite force exerted by the spring against the support structure.

5. A method, comprising:

generating a random number;

encrypting the random number with a public key of a cryptographic key store device; signing the encrypted random number with a private key of the server to generate a signature;

generating one or more matrix barcodes including the signature and encrypted random number;

transmitting the one or more matrix barcodes in a web page to a browser of a client device, wherein the one or more matrix barcodes are scanned by the cryptographic key store device, and wherein the cryptographic key store device:

verifies the signature in the one or more matrix barcodes with the public key of a server;

decrypts the encrypted random number with a private key of the cryptographic key store device to generate the random number;

displays the random number to a user of the cryptographic key store device on a display of the cryptographic key store device; and

transmitting the random number in a web page to a browser of the client device to allow the user to compare the random number with the random number displayed by the cryptographic key store device.

6. A method in a cryptographic key store device, comprising:

determining that operating system (OS) layer does not expose privileged access to a user;

determining that application layer package name matches a stored name;

generating a signature for the application layer package;

determining that the generated signature matches a stored signature for the application layer package;

determining that an anti-tamper circuit of the cryptographic key store device has a signal, the anti-tamper circuit being a circuit of the cryptographic key store device which is opened when the cryptographic key store device is physically tampered with; and

initializing a normal state.

7. A method in a cryptographic key store device, comprising:

receiving an instruction to transmit a data package to client device, the cryptographic key store device having an air gap with the client device, wherein the cryptographic key store device has an electronic display;

computing a total number of matrix barcodes needed to encode the data package; generating one or more matrix barcodes, each one of the one or more matrix barcodes encoding a portion of the data package, and each one of the one or more matrix barcodes also encoding a sequence number and the total number of matrix barcodes; and

instructing the electronic display to present the one or more matrix barcodes

sequentially, each of the one or more matrix barcodes presented for a set interval on the electronic display, wherein the client device continuously scans the presented one or more matrix barcodes using an imaging device to decode the portions of the data package encoded within the one or more matrix barcodes, and wherein the client device verifies receipt of the data package using the sequence number and the total number of matrix barcodes decoded from the one or more matrix barcodes.

8. A method, comprising:

receiving a set of child public addresses generated by a client device using a master public key received by the client device from a cryptographic key store device; searching a block chain for candidate transactions indicating any one of the set of child public addresses as a transaction recipient;

storing candidate transactions in a working database;

for each candidate transaction, determining if transacted balance is still valid for use; for each candidate transaction which a valid transacted balance, accumulating

transacted balance amount to a total balance value; and

transmit the total balance value to client device.