Access control system and method for crypto wallets
Patent Information
- Application Number
- JP2024547219
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-02-09
- Filing Date
- 2023-02-09
- Publication Date
- 2025-03-07
Smart Images
Figure 2025506141000001_ABST
Abstract
Description
[Technical field]
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 308,469, filed February 9, 2022, and entitled "Access Control System and Method for Crypto Wallets," the entire contents of which are incorporated herein by reference.
[0002] 1. Field
[0003] The present disclosure is directed to crypto wallets, and more particularly, the present disclosure is directed to access control for crypto wallets. [Background technology]
[0004] 2. Description of Related Technology
[0005] Access control in hardware crypto wallets typically relies on a PIN that the wallet owner enters using a button or electronic key on the device. If the PIN is entered incorrectly a certain number of times in a row, the device resets itself and deletes all wallet information, including the seed value. This can be a problem if the owner forgets the PIN, or if a bad actor enters too many potentially inaccurate PINs. Summary of the Invention
[0006] Systems, devices, and / or methods are provided for access control for crypto wallets. A method is provided for configuring a hardware wallet for control. The method may include generating, by a first wallet controller, a master signing key pair including a private master signing key and a public master signing key. The method may include generating, by the first wallet controller, a first unlocking key pair including a private first unlocking key and a public first unlocking key. The method may include signing, by the first wallet controller, the public first unlocking key with the private master signing key to create a signed public first unlocking key. The method may include transmitting the public master signing key from the first wallet controller to the hardware wallet. The method may include transmitting the signed public first unlocking key from the first wallet controller to the hardware wallet.
[0007] In various embodiments, the method includes one or more additional aspects. For example, the method may include storing, by the hardware wallet, the public master signing key. The hardware wallet may store the signed public first unlocking key. The hardware wallet may decrypt the public first unlocking key from the signed public first unlocking key by a master signing key of the public master signing key. The hardware wallet may store the public first unlocking key.
[0008] Other aspects may also be provided. The method may include setting a first user personal identification number (PIN) by a user input component of the hardware wallet and storing the first user PIN. The method may include transmitting a private master signing key from the first wallet controller to the second wallet controller. The second wallet controller may generate a second unlock key pair having a private second unlock key and a public second unlock key. The second wallet controller may sign the public second unlock key with the private master signing key to create a signed public second unlock key. The second wallet controller may transmit the signed public second unlock key to the hardware wallet. Transmitting the private master signing key from the first wallet controller to the second wallet controller may imply accessing the same Trusted Execution Environment (TEE) by the first wallet controller and the second wallet controller.
[0009] In various embodiments, the method further contemplates storing, by the hardware wallet, the signed public second unlock key; decrypting, by the public master signing key, the public second unlock key from the signed public second unlock key; and storing, by the hardware wallet, the public second unlock key.
[0010] The method may include approving unlocking of the hardware wallet to enable access to secure data comprising cryptocurrency. Approval may include generating, by the first wallet controller, a first wallet unlock command. Approval may include signing, by the first wallet controller, the first wallet unlock command with a private first unlock key to generate a first signed wallet unlock command. Approval may include sending, by the first wallet controller, the first signed wallet unlock command to the hardware wallet.
[0011] The method may include accessing secure data including cryptocurrency, where the access occurs following approval of unlocking of the hardware wallet. The access may include prompting a user to enter a personal identification number, by the hardware wallet. The access may include receiving, by the hardware wallet, the personal identification number. The access may include verifying, by the hardware wallet, that the received personal identification number is correct. Further aspects may occur in response to the verification. For example, the method may continue with decrypting the first wallet unlock command from the signed wallet unlock command with a public first unlock key to reveal the first wallet unlock command, and executing, by the hardware wallet, the first wallet unlock command.
[0012] In various embodiments including a second wallet controller, approving the unlocking of the hardware wallet to allow access to secure data including cryptocurrency may have aspects related to the second wallet controller. For example, approval may include generating, by the second wallet controller, a second wallet unlock command. Approval may include signing, by the second wallet controller, the second wallet unlock command with a private second unlock key to generate a second signed wallet unlock command. Approval may include sending, by the second wallet controller, the second signed wallet unlock command to the hardware wallet.
[0013] In various embodiments including a second wallet controller, accessing the secure data including cryptocurrency may have aspects related to the second wallet controller. For example, accessing may occur following approval of unlocking the hardware wallet and may include various actions. Accessing may include prompting the user to enter a personal identification number, by the hardware wallet. Accessing may include receiving, by the hardware wallet, the personal identification number. Accessing may include verifying, by the hardware wallet, that the received personal identification number is correct. Further aspects may occur in response to the verification. For example, the method may continue with decrypting the second wallet unlock command from the signed wallet unlock command with a public second unlock key to reveal the second wallet unlock command. The method may continue with executing, by the hardware wallet, the second wallet unlock command.
[0014] Various methods may also have aspects related to key revocation. For example, the method may include revoking the first unlocking key pair. Revoking the first unlocking key pair may include generating, by the first wallet controller, a first unlocking key pair revocation command. The method may include signing, by the first wallet controller, the first unlocking key pair revocation command with at least one of (i) a private master signing key and / or (ii) a private first unlocking key to generate a first signed unlocking key pair revocation command. The method may include sending, by the first wallet controller, the first signed unlocking key pair revocation command to the hardware wallet. The revocation may further include receiving, by the hardware wallet, the first signed unlocking key pair revocation command. The revocation may include decrypting the first unlocking key pair revocation command from the first signed unlocking key pair revocation command with at least one of (i) the public master signing key and / or (ii) the public first unlocking key to reveal the first unlocking key pair revocation command. The method may include removing, by the hardware wallet, the public first unlock key from the hardware wallet.
[0015] Further methods of configuring a hardware wallet for control by a first wallet controller are provided. The method may include receiving, by the hardware wallet from the first wallet controller, a public master signing key from a master signing key pair comprising a private master signing key and a public master signing key. The method may include receiving, by the hardware wallet from the first wallet controller, a signed public first unlocking key comprising a public first unlocking key from a first unlocking key pair comprising a private first unlocking key and a public first unlocking key, the public first unlocking key being signed by the private master signing key. The method may include storing, by the hardware wallet, the public master signing key. The method may include storing, by the hardware wallet, the signed public first unlocking key. The method may include decrypting, by the master signing key of the public master signing key, the public first unlocking key from the signed public first unlocking key. The method may include storing, by the hardware wallet, the public first unlocking key.
[0016] Additional aspects may also be provided. For example, the method may include setting, by a user input component of the hardware wallet, a first user personal identification number (PIN) and storing the first user PIN. The method may include authorizing unlocking of the hardware wallet to enable access to the secure data comprising the cryptocurrency. The authorizing may include receiving, by the hardware wallet from a first wallet controller, a first signed wallet unlock command, the first signed wallet unlock command comprising a first wallet command signed by the first wallet controller with a private first unlock key.
[0017] The method may include accessing, by the hardware wallet, secure data including cryptocurrency, where the access occurs following approval of unlocking of the hardware wallet. The access may include prompting, by the hardware wallet, a user to enter a personal identification number. The access may include receiving, by the hardware wallet, the personal identification number. The access may include verifying, by the hardware wallet, that the received personal identification number is correct. Various factors may occur in response to the verification. For example, the method may continue with decrypting the first wallet unlock command from the signed wallet unlock command with a public first unlock key to reveal the first wallet unlock command, and executing, by the hardware wallet, the first wallet unlock command.
[0018] A cryptocurrency wallet controller is disclosed. The wallet controller may configure a hardware wallet for control by the cryptocurrency wallet controller. The cryptocurrency wallet controller may include a transceiver configured to electronically communicate with the hardware wallet to communicate a cryptographic key to the hardware wallet. The cryptocurrency wallet controller may include a digital storage unit configured to securely store at least a portion of the cryptographic key. The cryptocurrency wallet controller may include a processor in electronic communication with the digital storage unit and the transceiver. The processor may be configured to perform various methods. For example, the processor may be configured to generate a master signing key pair including a private master signing key and a public master signing key. The processor may generate a first unlocking key pair including a private first unlocking key and a public first unlocking key. The processor may sign the public first unlocking key with the private master signing key to create a signed public first unlocking key. The processor may transmit, via the transceiver, the public master signing key to the hardware wallet. The processor may transmit, via the transceiver, the signed public first unlocking key to the hardware wallet. The processor stores the private master signing key and the private first unlocking key in the digital storage unit. The private master signing key and the private first unlocking key are not transmitted from the cryptocurrency wallet controller to the hardware wallet.
[0019] In various embodiments, further features are provided. The processor may be further configured to transmit the private master signing key from the first wallet controller to the second wallet controller. The second wallet controller may generate a second unlocked key pair having a private second unlocked key and a public second unlocked key. The second wallet controller may sign the public second unlocked key with the private master signing key to create a signed public second unlocked key. The second wallet controller may transmit the signed public second unlocked key from the second wallet controller to the hardware wallet. In various embodiments, the first wallet controller and the second wallet controller are software applications executing on the same device, and transmitting the private master signing key from the first wallet controller to the second wallet controller includes accessing, by both the first wallet controller and the second wallet controller, a shared trusted execution environment including the private master signing key. [Brief description of the drawings]
[0020] Other systems, methods, features, and advantages of the present invention will become apparent to one with skill in the art upon examination of the following figures and detailed description. The components shown in the drawings are not necessarily to scale and may be exaggerated to more fully illustrate the important features of the present invention.
[0021] [Figure 1] FIG. 1 depicts a block diagram of a wallet control system, according to various embodiments. [Diagram 2] FIG. 2 depicts various keys of a wallet control system, according to various embodiments. [Diagram 3] FIG. 3 depicts various communication channels of a wallet control system, according to various embodiments. [Figure 4] FIG. 4 depicts a method of configuring a hardware wallet for secure control by a first wallet controller, according to various embodiments. [Diagram 5] FIG. 5 depicts a method of configuring a hardware wallet for secure control by first and second wallet controllers, according to various embodiments. [Figure 6] FIG. 6 depicts a method of configuring a hardware wallet for control, including approving unlocking or other access control enforcement, according to various embodiments. [Figure 7] FIG. 7 depicts a method of configuring a hardware wallet for control, including authorizing unlocking or other access control enforcement, by first and second wallet controllers, according to various embodiments. [Figure 8] FIG. 8 depicts a method of revoking a key associated with access to a hardware wallet according to various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0022] As disclosed herein, systems, devices, and methods are provided for cryptocurrency wallet (crypto wallet) access and control.
[0023] Crypto wallets are used to generate and store cryptographic keys required to make cryptocurrency transactions. Crypto wallets include at least two common types: A software wallet is a crypto wallet that is a smartphone or desktop application that stores cryptographic keys and also manages input and output transactions. A hardware wallet is a crypto wallet that has an embedded device that stores private keys used to sign output transactions. A hardware wallet communicates with a smartphone, desktop, or web application "watch-only wallet" that stores only the corresponding public key of the hardware wallet's private key. A watch-only wallet monitors input transactions and prepares unsigned output transactions for the embedded device, but cannot sign output transactions. The embedded device validates the transaction details, obtains the applicable signing key, signs the transaction, and sends the signed transaction back to the smartphone, desktop, or web application for broadcast to mining nodes.
[0024] Hardware crypto wallets are known to be more secure than software crypto wallets because software crypto wallets coexist with other applications on a smartphone or desktop and therefore the private key is vulnerable to software attacks on a shared platform, whereas in a hardware crypto wallet the key never leaves the embedded device. Access to hardware crypto wallet operations is often protected by a personal identification number (PIN).
[0025] As stated, conventional crypto wallets rely on a personal identification number (PIN) being entered correctly, and often delete wallet information in response to an excessive number of incorrect PIN entries. This creates a variety of problems. For example, the owner may forget the PIN and lose access to the device. If a bad actor gains physical access to the device, for example while the device is left temporarily unattended, the bad actor may attempt to guess the PIN. In some cases, for example, if the PIN is part of the owner's birthday date or phone number, or is used elsewhere by the owner, the PIN may be stolen or easily guessed. If the bad actor can correctly guess the wallet's PIN within a few attempts, the bad actor may steal all of the wallet's cryptocurrency. If the bad actor cannot correctly guess the PIN, the bad actor may still force a device reset after several consecutive incorrect PIN attempts in a trivial denial of service attack. In such cases, the owner may need to restore the wallet seed value from a backup, or may otherwise lose their cryptocurrency.
[0026] The restoration process introduces the following additional risks: For example, the restoration process, if done, for example, via a recovery seed phrase, can be a time-consuming and undesirable task; It can result in opportunity costs if the owner does not have immediate access to a backup source; If the owner loses their backup, the wallet's cryptocurrency can be lost forever.
[0027] To address these and other challenges, various access control systems and methods for crypto wallets are provided. For example, a wallet owner may choose to use a smartphone application that communicates with the hardware wallet over Bluetooth Low Energy (BLE) to unlock the embedded device, in addition to or as an alternative to the device's PIN. As an initial step, the application may create a device unlock signing key and share the corresponding public key with the embedded device. Later, whenever the device needs to be unlocked, the application may send a digitally signed unlock command to the device. The signing key may be tied to the owner's verification via biometrics, PIN, or pattern set on the smartphone.
[0028] If application authentication is used in addition to a PIN, the embedded device should first authenticate the application before presenting the owner with a PIN entry to mitigate PIN attacks. If application authentication is used as an alternative to a PIN, the embedded device will not require a PIN if application authentication is successful, but will still require the owner to physically confirm the unlock process, for example by pressing two buttons simultaneously.
[0029] An exemplary system for crypto wallet backup and recovery may have different devices that cooperate to perform these mechanisms. Turning now to FIG. 1, an access control system 2 for crypto wallets may include one or more hardware wallets 8. The hardware wallet 8 may be a hardware crypto wallet embedded device. For example, the hardware wallet 8 may have processing, communication, and memory capabilities. The access control system 2 may include one or more wallet controllers. For example, FIG. 1 depicts a first wallet controller 4 and a second wallet controller 6, but any number of wallet controllers may be provided. A wallet controller may be a device that can cooperate with a hardware wallet 8 to control cryptocurrency transactions. A wallet controller may be a device that can configure a hardware wallet 8 for access.
[0030] The description now considers the hardware wallet 8, the first wallet controller 4, and the second wallet controller 6 in more detail. In various embodiments, the hardware wallet 8 may include a processor 28. The processor 28 may be a computer processor, microprocessor, or any other electronic device configured to perform calculations. The hardware wallet 8 may include a digital storage unit 26. The digital storage unit 26 may comprise electronic memory. The memory may interact with the processor 28 to store data for future use and to retrieve data for current use. In various examples, the digital storage unit 26 may include a securely stored key or may include a PIN. The hardware wallet 8 may include a user input component 22. The user input component 22 may include one or more keyboards, push buttons, touch-sensitive elements such as a touch screen, audio devices, haptic devices, or other human-machine interfaces capable of receiving input from a human. The hardware wallet 8 may include one or more user output components 24. The user output component 24 may include one or more visual display screens, light indicators, audio devices, haptic devices, or other human-machine interfaces capable of providing output to a human. The hardware wallet 8 may have a transceiver 30. The transceiver 30 may be an RF transceiver, a wired transceiver, a modem, or any other device configured to communicate with other devices, such as the first wallet controller 4 and the second wallet controller 6, directly or over a network.
[0031] The first wallet controller 4 and the second wallet controller 6 are shown as block diagrams of hardware devices. The first wallet controller 4 is shown with a processor 10, a digital storage unit 12, and a transceiver 14. The second wallet controller 6 is shown with a processor 16, a digital storage unit 18, and a transceiver 20. However, it can be understood that each wallet controller can be a combination of hardware and software. For example, in various embodiments, the first wallet controller 4 and the second wallet controller 6 are both software applications running on a computing device. Thus, the processor 10 and the processor 16 can be the same processor of the computing device. Similarly, the digital storage unit 12 and the digital storage unit 18 can be a shared computer memory or different portions of the computer memory (e.g., different addressable spaces). And the transceiver 14 and the transceiver 20 can be the same transceiver of the computing device.
[0032] More specifically, with reference to the first wallet controller 4, the first wallet controller 4 may include a processor 10. The processor 10 may be a computer processor, microprocessor, or any other electronic device configured to perform calculations. The first wallet controller 4 may include a digital storage unit 12. The digital storage unit 12 may include electronic memory. The memory may interact with the processor 10 to store data for future use and retrieve data for current use. In various examples, the digital storage unit 12 may include securely stored encryption keys. The first wallet controller 4 may include a transceiver 14. The transceiver 14 may be an RF transceiver, a wired transceiver, a modem, or any other device configured to communicate with other devices, such as the hardware wallet 8 and the second wallet controller 6, directly or over a network.
[0033] More specifically, with reference to the second wallet controller 6, the second wallet controller 6 may include a processor 16. The processor 16 may be a computer processor, microprocessor, or any other electronic device configured to perform calculations. The second wallet controller 6 may include a digital storage unit 18. The digital storage unit 18 may include electronic memory. The memory may interact with the processor 16 to store data for future use and retrieve data for current use. In various examples, the digital storage unit 18 may include securely stored encryption keys. The second wallet controller 6 may include a transceiver 20. The transceiver 20 may be an RF transceiver, a wired transceiver, a modem, or any other device configured to communicate with other devices, such as the hardware wallet 8 and the first wallet controller 4, directly or over a network.
[0034] Referring now to Figure 2, with continuing reference to Figure 1, various illustrative data and associations of various data with different devices are shown. Arrows are shown to depict various transmissions of data from one device to another. For example, the processor 10 of the first wallet controller 4 may generate an encryption key. In other embodiments, the encryption key is received from another system, network, or device. The first wallet controller 4 may store the encryption key in the digital storage unit 12.
[0035] The key may be an asymmetric encryption key. Asymmetric cryptography (e.g., public key cryptography) uses a pair of related keys to encrypt and decrypt data. Typically, a public key can be used by any machine to encrypt a message such that the message can only be decrypted by the holder of the corresponding private key. Similarly, if the holder of a private key encrypts a message using the private key, the message can be decrypted using the corresponding public key. Decryptability with a private key also verifies the origin of the message, based on the assumption that the private key is only under the control of the true sender of the message.
[0036] The first wallet controller 4 may have a master signing key pair 50. The master signing key pair 50 may have a public master signing key 52 and a private master signing key 54. The master signing key pair 50 may be used to sign and / or encrypt messages. The first wallet controller 4 may have a first unlocking key pair 56. The first unlocking key pair 56 may have a public first unlocking key 58 and a private first unlocking key 60. The first unlocking key pair 56 may be used in connection with sending an unlocking message to the hardware wallet 8 instructing the hardware wallet 8 to “unlock” such that cryptocurrency transactions may be performed in connection with cryptocurrencies transacted or otherwise controlled by the hardware wallet 8.
[0037] The second wallet controller 6 may have a master signing key pair 62. The master signing key pair 62 may be identical to the master signing key pair 50 of the first wallet controller 4. The master signing key pair 62 may include a public master signing key 64 and a private master signing key 66. In various embodiments, the private master signing key 66 may be omitted. For example, the private master signing key 66 may be stored only in the first wallet controller 4, such that the second wallet controller 6 does not have and does not have access to the private master signing key 66. This is indicated by the dashed line forming an X in the private master signing key 66. In further embodiments, the private master signing key 66 is not omitted and is identical to the master signing key pair 50. The master signing key pair 62 may be used to sign and / or encrypt messages. The second wallet controller 6 may have a second unlocking key pair 68. The second unlocking key pair 68 may have a public second unlocking key 70 and a private second unlocking key 72. The second unlocking key pair 68 may be used in connection with sending an unlocking message to hardware wallet 8 instructing hardware wallet 8 to “unlock” such that cryptocurrency transactions may be performed in connection with cryptocurrencies handled or otherwise controlled by hardware wallet 8.
[0038] It may therefore be understood that both the first wallet controller 4 and the second wallet controller 6 may have access to the master signature key pair, and pairs 62 and 50 may be a single key pair. For example, each wallet controller may be a software application running on a device having a master signature key pair securely stored in a Trusted Execution Environment (TEE) or Secure Element (SE). In particular, the first wallet controller 4 and the second wallet controller 6 may limit access to the first unlock key pair 56 and the second unlock key pair 68. For example, the first wallet controller 4 has access to the first unlock key pair 56 but does not have access to the second unlock key pair 68. Similarly, the second wallet controller 6 has access to the second unlock key pair 68 but does not have access to the first unlock key pair 56. Various other mechanisms may also be envisioned to further improve the security of the keys.
[0039] The hardware wallet 8 may also store various keys in the digital storage unit 26 of the hardware wallet 8. The first wallet controller 4 may utilize its transceiver 14 to communicate with the transceiver 30 of the hardware wallet 8 and transmit various keys for storage in the digital storage unit 26 of the hardware wallet 8. Similarly, the second wallet controller 6 may utilize its transceiver 20 to communicate with the transceiver 30 of the hardware wallet 8 and transmit various keys for storage in the digital storage unit 26 of the hardware wallet 8. The first wallet controller 4 may provide the public master signing key 52 and the public first unlocking key 58 to the hardware wallet 8. The second wallet controller 6 may provide the public second unlocking key 70 to the hardware wallet 8. And, the hardware wallet 8 may have a user input component 22 to receive input of a personal identification number (PIN) and verify stewardship and / or control of the hardware wallet 8 before various operations, such as unlocking the hardware wallet 8. Hardware wallet 8 may receive user confirmation 80, such as PIN 78, via input at user input component 22, such as the input indicated by arrow 82 (third communication channel 82, described below).
[0040] The hardware wallet 8 may cooperate with one or both of the first wallet controller 4 and the second wallet controller 6 to perform various operations utilizing inter-device and / or intra-device communications. With reference to FIG. 3 (with continued reference to FIGS. 1-2), the first wallet controller 4 may instantiate a first communication channel 84 with the hardware wallet 8 to send and receive commands and / or keys. The second wallet controller 6 may instantiate a second communication channel 86 with the hardware wallet 8 to send and receive commands and / or keys. The user verification 80 may proceed over a third communication channel 82 to interact with the hardware wallet 8. In various examples, the first communication channel 84 is a wireless connection between the transceiver 14 of the first wallet controller 4 and the transceiver 30 of the hardware wallet 8. In various examples, the second communication channel 86 is a wireless connection between the transceiver 20 of the second wallet controller 6 and the transceiver 30 of the hardware wallet 8. In various examples, the third communication channel 82 may be a physical interaction of the user providing a user confirmation 80 at a user input component 22 of the hardware wallet 8, such as by pressing a button or entering a PIN.
[0041] Having introduced aspects relating to the first wallet controller 4, the second wallet controller 6, the hardware wallet 8, and the communications among the first wallet controller 4, the second wallet controller 6, and the hardware wallet 8, various methods may be performed by one or more of these devices to control access to cryptocurrency associated with the hardware wallet 8. For example, with reference to FIG. 4 and continuing reference to FIGS. 1-3, a method 400 may be provided for setting up the hardware wallet 8 for secure control by one or both of the first wallet controller 4 and the second wallet controller 6. The method 400 for configuring the hardware wallet 8 for control may include generating keys. In a further example, the keys are generated by another device and provided to the access control system 2. For example, the method may include generating, by the first wallet controller 4, a master signing key pair 50 comprising a public master signing key 52 and a private master signing key 54 (block 402). The method may also include generating, by the first wallet controller 4, a first unlock key pair 56 comprising a public first unlock key 58 and a private first unlock key 60 (block 404).
[0042] The first wallet controller 4 may sign the public first unlock key 58 with the private master signing key 54 to create a signed public first unlock key (block 406). "Signing" data may include applying a cryptographic calculation, such as encrypting the data. The first wallet controller 4 may send the public master signing key 52 to the hardware wallet 8 (block 408). The first wallet controller 4 may send the signed public first unlock key to the hardware wallet 8 (block 410). In particular, the first wallet controller 4 may refrain from sending the private master signing key 54 and may refrain from sending the private first unlock key 60 to any other device. Similarly, the first wallet controller 4 may refrain from sending the public first unlock key 58 to any other device. Because the key sent in block 410 is signed, it is encrypted during transmission and is sent securely.
[0043] The hardware wallet 8 may perform various steps after receiving the public master signing key 52 and the signed public first unlock key. For example, the hardware wallet 8 may store the public master signing key 52 (block 412). The hardware wallet 8 may also store the signed public first unlock key (block 414). The hardware wallet 8 may decrypt the public first unlock key 58 from the signed public first unlock key by the public master signing key 52 (block 416). Upon recovering the public first unlock key 58 in unencrypted form, the hardware wallet 8 may store the public first unlock key 58 (block 418). The hardware wallet 8 now has the ability to decrypt messages encrypted with the private first unlock key 60. The origin of the message originating from the first wallet controller 4 and the contents of the message may be securely revealed by the hardware wallet 8 since the hardware wallet 8 has a local copy of the private first unlock key 60. Hardware wallet 8 may also set a first user personal identification number (PIN) via user input component 22 of hardware wallet 8 and store the first user PIN (block 420). This PIN may also facilitate verifying positive control of hardware wallet 8 by an authorized individual, and may be required by hardware wallet 8 to be re-entered before various operations, such as unlocking.
[0044] In various embodiments, the first wallet controller 4 may also be operable to set up the hardware wallet 8 for secure control by both the first wallet controller 4 and the second wallet controller 6. With reference to Figure 5, and with continuing reference to Figures 1-3, a method 500 of setting up a hardware wallet 8 for secure control by both the first wallet controller 4 and the second wallet controller 6 is provided. In this method, some aspects of the method 400 (Figure 4) described with reference to Figure 4 are repeated at similar block numbers and some aspects differ.
[0045] In various embodiments, the method 500 of configuring a hardware wallet 8 for control by both the first wallet controller 4 and the second wallet controller 6 may include generating keys. In a further example, the keys are generated by another device and provided to the access control system 2. For example, the method may include generating, by the first wallet controller 4, a master signing key pair 50 comprising a public master signing key 52 and a private master signing key 54 (block 402). The method may also include generating, by the first wallet controller 4, a first unlocking key pair 56 comprising a public first unlocking key 58 and a private first unlocking key 60 (block 404).
[0046] The first wallet controller 4 may sign the public first unlock key 58 with the private master signing key 54 to create a signed public first unlock key (block 406). "Signing" data may include applying a cryptographic calculation, such as encrypting the data. The first wallet controller 4 may send the public master signing key 52 to the hardware wallet 8 (block 408). The first wallet controller 4 may send the private master signing key 54 from the first wallet controller 4 to the second wallet controller 6 (block 502). The second wallet controller 6 may generate a second unlock key pair 68 comprising a private second unlock key 72 and a public second unlock key 70 (block 504). The second wallet controller 6 may sign the public second unlock key 70 with the private master signing key 66 to create a signed public second unlock key (block 506).
[0047] The first wallet controller 4 may send the signed public first unlock key to the hardware wallet 8 (block 410). The second wallet controller 6 may send the signed public second unlock key to the hardware wallet 8 (block 508).
[0048] In particular, the first wallet controller 4 may refrain from transmitting the private master signing key 54 and may refrain from transmitting the private first unlocking key 60 to the hardware wallet 8. Similarly, the second wallet controller 6 may refrain from transmitting the private master signing key 66 and may refrain from transmitting the private second unlocking key 72 to the hardware wallet 8. Because the keys transmitted in block 410 are signed, they are encrypted in transit and transmitted securely. Because the keys transmitted in block 508 are signed, they are encrypted in transit and transmitted securely.
[0049] Hardware wallet 8 may perform various steps after receiving one or more of public master signing key 52, the signed public first unlock key, and the signed public second unlock key. For example, hardware wallet 8 may store public master signing key 52 (block 412). Hardware wallet 8 may also store the signed public first unlock key (block 414). Hardware wallet 8 may store the signed public second unlock key (block 510).
[0050] The hardware wallet 8 may decrypt the public first unlock key 58 from the signed public first unlock key with the public master signing key 52 (block 416). The hardware wallet 8 may decrypt the public second unlock key 70 from the signed public second unlock key with the public master signing key 52 (block 512).
[0051] Upon recovering the first public unlock key 58 in unencrypted form, the hardware wallet 8 may store the first public unlock key 58 (block 418). Upon recovering the second public unlock key 70 in unencrypted form, the hardware wallet 8 may store the second public unlock key 70 (block 514).
[0052] Here, the hardware wallet 8 has the ability to decrypt messages encrypted with the private first unlock key 60 and to decrypt messages encrypted with the private second unlock key 72. The origin of the messages originating from the first wallet controller 4 and the second wallet controller 6 and the contents of the messages can be securely revealed by the hardware wallet 8, so that the hardware wallet 8 has local copies of the private first unlock key 60 and the private second unlock key 72. The hardware wallet 8 can also set a first user personal identification number (PIN) via the user input component 22 of the hardware wallet 8 and can store the first user PIN. This PIN can also facilitate verifying positive control of the hardware wallet 8 by an authorized individual and can be required by the hardware wallet 8 to be re-entered before various operations, such as unlocking.
[0053] The above methods focus on establishing secure access among the hardware wallet 8, the first wallet controller 4, and / or the second wallet controller 6 through the exchange of various keys. In the following paragraphs, the description continues with a description of various mechanisms for controlling the hardware wallet 8 by the controller with established access. The mechanisms are described with reference to their own figures and blocks, but it will be understood that aspects may be combined with or used following already described methods.
[0054] For example, with reference to FIG. 6 and with continuing reference to FIGS. 1-3, the method of configuring the hardware wallet 8 for control may further include steps associated with authorizing the unlocking or other access control exercise. For example, method 600 may comprise a continuation of method 400 or method 500 (FIGS. 4 and 5). In various embodiments, method 600 may include authorizing the unlocking of the hardware wallet 8 by the first wallet controller 4 to allow access to the secure data comprising the cryptocurrency (block 601). Authorization may include various further aspects. Method 600 may include accessing the secure data comprising the cryptocurrency, where access occurs after authorizing the unlocking of the hardware wallet 8 (block 650). Access may also include various further aspects.
[0055] In various embodiments, authorizing (block 601) may include generating a first wallet unlock command by the first wallet controller 4 (block 602). The unlock command may be a command to allow access to cryptocurrency transfers or transactions associated with the wallet. The method may include signing the first wallet unlock command with the private first unlock key 60 by the first wallet controller 4 to generate a first signed wallet unlock command (block 604). The first wallet controller 4 may send the first signed wallet unlock command to the hardware wallet 8 (block 606).
[0056] In various embodiments, the accessing (block 650) may include the hardware wallet 8 prompting the user to enter a PIN (block 652). The hardware wallet 8 may receive the PIN (block 654) and may verify that the received PIN is correct (block 656). In response to verifying that the received PIN is correct, the hardware wallet 8 may decrypt the first wallet unlock command from the signed wallet unlock command with public first unlock key 58 to reveal the first wallet unlock command (block 658). The hardware wallet 8 may execute the first wallet unlock command (block 660).
[0057] 7 and with continuing reference to FIGS. 1-3, the method of configuring the hardware wallet 8 for control may further include steps associated with authorizing unlocking or other access control enforcement by the second wallet controller 6 to enable unlocking or other access control enforcement by the second wallet controller 6. Such access by the second wallet controller 6 may be in addition to the access by the first wallet controller 4. Thus, in various embodiments, the method 700 may comprise a continuation of the method 400, the method 500, or the method 600 (FIGS. 4-6). In various embodiments, the method 700 may include authorizing the unlocking of the hardware wallet 8 by the second wallet controller 6 to enable access to the secure data comprising the cryptocurrency (block 701). The authorization may include various further aspects. The method 700 may include accessing the secure data comprising the cryptocurrency, the access occurring after the authorization of the unlocking of the hardware wallet 8 by the second wallet controller 6 (block 750). The access may also include various further aspects.
[0058] In various embodiments, authorizing (block 701) may include generating, by the second wallet controller 6, a second wallet unlock command (block 702). The unlock command may be a command to allow access to cryptocurrency transfers or transactions associated with the wallet. The method may include signing, by the second wallet controller 6, the second wallet unlock command with a private second unlock key 72 to generate a second signed wallet unlock command (block 704). The second wallet controller 6 may send the second signed wallet unlock command to the hardware wallet 8 (block 706).
[0059] In various embodiments, the accessing (block 750) may include the hardware wallet 8 prompting the user to enter a PIN (block 752). The hardware wallet 8 may receive the PIN (block 754) and may verify that the received PIN is correct (block 756). In response to verifying that the received PIN is correct, the hardware wallet 8 may decrypt the second wallet unlock command from the signed wallet unlock command with the public second unlock key 70 to reveal the second wallet unlock command (block 758). The hardware wallet 8 may execute the second wallet unlock command (block 760).
[0060] In various embodiments, the key may be revoked such that access to the hardware wallet 8 by the first wallet controller 4 or the second wallet controller 6 may be terminated. For example, with reference to FIG. 8, and periodically with reference to FIGS. 1-3, a method 800 of key revocation may be provided. The method may comprise a continuation of method 400, method 500, method 600, or method 700 (FIGS. 4-7). Method 800 may include revoking the first unlocking key pair 56 (block 801).
[0061] Revoking the first unlock key pair 56 may include various steps. For example, revoking (block 801) may include generating, by the first wallet controller 4, a first unlock key pair revocation command (block 802). The method may include signing, by the first wallet controller 4, the first unlock key pair revocation command with at least one of (i) the private master signing key 54 and (ii) the private first unlock key 60 to generate a first signed unlock key pair revocation command (block 804). The method may include sending, by the first wallet controller 4, the first signed unlock key pair revocation command to the hardware wallet 8 (block 806).
[0062] After the deactivation of the first unlock key pair 56 and transmission of the associated deactivation command to the hardware wallet 8, the method may continue. The method may include receiving the first signed unlock key pair deactivation command by the hardware wallet 8 (block 808). The hardware wallet 8 may decrypt the first unlock key pair deactivation command from the first signed unlock key pair deactivation command with at least one of (i) the public master signing key 52 and / or (ii) the public first unlock key 58 to reveal the first unlock key pair deactivation command (block 810). The hardware wallet 8 may remove the public first unlock key 58 from the hardware wallet 8 (block 812), add the key to a list of prohibited keys, or perform another command associated with the first unlock key pair deactivation command.
[0063] In addition to the methods described above, the system may be implemented with a variety of different hardware configurations for performing the methods. The wallet controller may be a smartphone application, and the smartphone may have a processor with a trusted execution environment (TEE). In other examples, a secure element (SE) is provided. One or more of the key pairs may be generated within the TEE or SE for improved security, such that the keys are hardware protected and not retrievable outside the TEE. In various examples, one or more of the private keys are kept in the TEE. This also facilitates improved security when the first wallet controller and the second wallet controller are different applications on the same hardware device. By keeping the keys in the TEE or SE, both controllers may share access to the keys, while the keys are secured from retrieval outside the TEE or SE.
[0064] Further, in various examples, the wallet controller may be a smartphone application that may be configured to use an attestation service provided by the operating system to obtain one or more digital certificate chains that are signed by a server at the smartphone's operating system manufacturer. The attestation may attest to the following (or a subset thereof): (1) authenticity of the operating system and device on which the application is running, (2) identity of the application developer, (3) authenticity of the application that the application has not been modified, (4) generation of an unlock key pair inside the TEE, and / or (5) possession of the unlock key pair by the application. The application may send the certificate chain to the hardware wallet, which may store and perform one or more operations related to the certificate chain. For example, the hardware wallet may store an attestation root key provided by the smartphone's operating system manufacturer. The hardware wallet may receive certificates from the application, validate each certificate chain using the stored attestation root key, and verify the attestation content of each certificate. Furthermore, the application may monitor and log each signature by incrementing a monotonically increasing counter that is incremented with each signing operation. Applications may further utilize a one-time nonce obtained from the hardware device. Additionally, an unlocked hardware device may relock itself after a certain duration that may be configurable by the user. These features further improve the security of the system.
[0065] And hardware wallets may also allow manual manipulation of keys. For example, a hardware wallet may allow the owner to manually select and delete one or more of the master public key or the unlocking public keys. A hardware wallet may allow the owner to manually change the device's PIN, control the unlock duration, or change the unlocking procedure using the device's buttons and screen while the device is unlocked. Thus, security may be further improved.
[0066] The preferred embodiments of the method / system are disclosed in an exemplary manner. Therefore, the terms employed throughout should be read as non-limiting. Those skilled in the art will conceive minor modifications to the teachings herein, but it should be understood that what is intended to be limited within the scope of the patent granted herein are all such embodiments that reasonably fall within the scope of the advancement to the art to which this specification contributes, and the scope should not be limited except in light of the appended claims and their equivalents.
Claims
1. 1. A method of configuring a hardware wallet for control, the method comprising: generating, by a first wallet controller, a master signing key pair comprising a private master signing key and a public master signing key; generating, by the first wallet controller, a first unlock key pair comprising a private first unlock key and a public first unlock key; signing, by the first wallet controller, the public first unlock key with the private master signing key to create a signed public first unlock key; transmitting the public master signing key from the first wallet controller to the hardware wallet; transmitting the signed public first unlock key from the first wallet controller to the hardware wallet; A method comprising:
2. storing, by the hardware wallet, the public master signing key; storing, by said hardware wallet, said signed public first unlock key; decrypting said public first unlock key from said signed public first unlock key with a master signing key of said public master signing key; storing, by said hardware wallet, said public first unlock key; The method of claim 1 further comprising:
3. 3. The method of claim 2, further comprising: setting, via a user input component of the hardware wallet, a first user personal identification number (PIN); and storing the first user PIN.
4. transmitting, from the first wallet controller, the private master signing key to a second wallet controller; generating, by the second wallet controller, a second unlock key pair comprising a private second unlock key and a public second unlock key; signing, by the second wallet controller, the public second unlock key with the private master signing key to create a signed public second unlock key; transmitting the signed public second unlock key from the second wallet controller to the hardware wallet; The method of claim 1 further comprising:
5. 5. The method of claim 4, wherein transmitting the private master signing key from the first wallet controller to the second wallet controller includes accessing the same Trusted Execution Environment (TEE) by the first wallet controller and the second wallet controller.
6. storing, by said hardware wallet, said signed public second unlock key; decrypting said public second unlocking key from said signed public second unlocking key with said public master signing key; storing, by said hardware wallet, said public second unlock key; The method of claim 4 further comprising:
7. and authorizing the unlocking of the hardware wallet to allow access to secure data comprising cryptocurrency, the authorization including: generating, by said first wallet controller, a first wallet unlock command; signing, by the first wallet controller, the first wallet unlock command with the private first unlock key to generate a first signed wallet unlock command; sending, by the first wallet controller, the first signed wallet unlock command to the hardware wallet; The method of claim 3 , comprising:
8. accessing the secure data comprising cryptocurrency, the access occurring after the approval of the unlocking of the hardware wallet; prompting a user via the hardware wallet to enter a personal identification number; receiving, by the hardware wallet, the personal identification number; verifying, by the hardware wallet, that the received PIN is correct; In response to said verification, decrypting the first wallet unlock command from the signed wallet unlock command with the public first unlock key to reveal the first wallet unlock command; executing the first wallet unlock command by the hardware wallet; The method of claim 7, comprising:
9. and authorizing the unlocking of the hardware wallet to allow access to secure data comprising cryptocurrency, the authorization including: generating, by said second wallet controller, a second wallet unlock command; signing, by the second wallet controller, the second wallet unlock command with the private second unlock key to generate a second signed wallet unlock command; sending, by a second wallet, the second signed wallet unlock command to the hardware wallet; The method of claim 6, comprising:
10. accessing the secure data comprising cryptocurrency, the access occurring after the approval of the unlocking of the hardware wallet; prompting a user via the hardware wallet to enter a personal identification number; receiving, by the hardware wallet, the personal identification number; verifying, by the hardware wallet, that the received PIN is correct; In response to said verification, decrypting the second wallet unlock command from the signed wallet unlock command with the public second unlock key to reveal the second wallet unlock command; executing the second wallet unlock command by the hardware wallet; 10. The method of claim 9, comprising:
11. and further comprising revoking the first unlocking key pair, the revoking comprising: generating, by the first wallet controller, a first unlock key pair revocation command; signing, by the first wallet controller, the first unlocking key pair revocation command with at least one of (i) the private master signing key and (ii) the private first unlocking key to generate a first signed unlocking key pair revocation command; sending, by the first wallet controller, the first signed unlock key pair revocation command to the hardware wallet; The method of claim 7, comprising:
12. The invalidation may be receiving, by the hardware wallet, the first signed unlock key pair revocation command; decrypting the first unlocking key pair revocation command from the first signed unlocking key pair revocation command with at least one of (i) the public master signing key and (ii) the public first unlocking key to reveal the first unlocking key pair revocation command; removing, by the hardware wallet, the public first unlock key from the hardware wallet; The method of claim 11 further comprising:
13. 1. A method of configuring a hardware wallet for control by a first wallet controller, the method comprising: receiving, by the hardware wallet from a first wallet controller, a public master signing key from a master signing key pair comprising a private master signing key and a public master signing key; receiving from the first wallet controller by the hardware wallet a signed public first unlock key comprising a public first unlock key from a first unlock key pair comprising a private first unlock key and a public first unlock key, the public first unlock key being signed by the private master signing key; storing, by the hardware wallet, the public master signing key; storing, by said hardware wallet, said signed public first unlock key; decrypting said public first unlock key from said signed public first unlock key with a master signing key of said public master signing key; storing, by said hardware wallet, said public first unlock key; A method comprising:
14. 14. The method of claim 13, further comprising: setting, via a user input component of the hardware wallet, a first user personal identification number (PIN); and storing the first user PIN.
15. and authorizing the unlocking of the hardware wallet to allow access to secure data comprising cryptocurrency, the authorization including:
15. The method of claim 14, comprising receiving a first signed wallet unlock command from the first wallet controller by the hardware wallet, the first signed wallet unlock command comprising a first wallet command signed by the first wallet controller with the private first unlock key.
16. accessing, by the hardware wallet, secure data comprising cryptocurrency, the access occurring after the approval of the unlocking of the hardware wallet; prompting a user via the hardware wallet to enter a personal identification number; receiving, by the hardware wallet, the personal identification number; verifying, by the hardware wallet, that the received PIN is correct; In response to said verification, decrypting a first wallet unlock command from the signed wallet unlock command with the public first unlock key to reveal the first wallet unlock command; executing the first wallet unlock command by the hardware wallet; 16. The method of claim 15, comprising:
17. 1. A cryptocurrency wallet controller for configuring a hardware wallet for control by a cryptocurrency wallet controller, said cryptocurrency wallet controller comprising: a transceiver configured to electronically communicate with the hardware wallet to communicate an encryption key to the hardware wallet; a digital storage unit configured to securely store at least a portion of the encryption key; a processor in electronic communication with said digital storage unit and said transceiver; wherein the processor: generating a master signing key pair comprising a private master signing key and a public master signing key; generating a first unlocking key pair comprising a private first unlocking key and a public first unlocking key; signing the public first unlock key with the private master signing key to create a signed public first unlock key; transmitting, by the transceiver, the public master signing key to the hardware wallet; configured to transmit, by the transceiver, the signed public first unlock key to the hardware wallet; the processor stores the private master signing key and the private first unlocking key in the digital storage unit; The cryptocurrency wallet controller, wherein the private master signing key and the private first unlock key are not transmitted from the cryptocurrency wallet controller to the hardware wallet.
18. 20. The cryptocurrency wallet controller of claim 17, wherein the processor is further configured to transmit, from a first wallet controller, the private master signing key to a second wallet controller.
19. The second wallet controller is generating, by the second wallet controller, a second unlock key pair comprising a private second unlock key and a public second unlock key; signing, by the second wallet controller, the public second unlock key with the private master signing key to create a signed public second unlock key; 20. The cryptocurrency wallet controller of claim 18, further comprising: transmitting the signed public second unlock key from the second wallet controller to the hardware wallet.
20. 20. The cryptocurrency wallet controller of claim 19, wherein both the first wallet controller and the second wallet controller are software applications executing on the same device, and the transmitting of the private master signing key from the first wallet controller to the second wallet controller includes accessing by both the first wallet controller and the second wallet controller a shared trusted execution environment containing the private master signing key.