Concept for restoring access to cryptocurrency wallets on remote servers

Abstract

To improve the cryptocurrency wallet concept and reduce risks for wallet owners. [Solution] Embodiments relate to concepts for restoring access to a cryptocurrency wallet on a remote server, and in particular to a wallet management device, method, computer program and system for registering a new cryptographic secret in a cryptocurrency wallet hosted in a trusted execution environment on a server. The wallet management device is configured to register a new first cryptographic secret in the cryptocurrency wallet hosted in a trusted execution environment on the first remote server by generating a first cryptographic secret, obtaining a second cryptographic secret from a second remote server when an owner of the cryptocurrency wallet is authenticated to the second remote server, signing control instructions for registering the first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret, and sending the signed control instructions for registering the first cryptographic secret in the cryptocurrency wallet to the first remote server. The wallet management device is configured to issue cryptographically protected instructions based on the first cryptographic secret to the first remote server for controlling the cryptocurrency wallet.

Description

[Technical field]

[0001] The present embodiments relate to concepts for restoring access to a cryptocurrency wallet on a remote server, and in particular to a wallet management apparatus, method, computer program and system for registering a new Cryptographic Secret to a cryptocurrency wallet hosted in a trusted execution environment on the server. [Background technology]

[0002] Cryptocurrencies, i.e. currencies that exist digitally and use cryptography to secure transactions, for example on a blockchain, are an area of ​​research and development. Cryptocurrency transactions usually require the use of so-called wallets - computer programs used to store and manage cryptographic secrets that can be used to sign cryptocurrency transactions.

[0003] There are various types of cryptocurrency wallets. The first type of wallet is called a "Self-Custodial Wallet". In a self-custodial wallet, the wallet owner does not rely on a third party to store and operate the private key that controls the assets in the wallet. Self-custodial wallets include hardware wallets, also known as cold storage, web or mobile wallets, and desktop wallets. Lost, stolen, or broken devices can usually be recovered by using a recovery phrase (often 24 words) that allows the key to be regenerated. This recovery phrase must be stored in a safe place. Self-custodial wallets are considered to be at high risk of permanent loss due to human error. According to one study, more than 20% of all Bitcoins (cryptocurrency) have been permanently lost due to device loss, human error, etc. This goes against the purpose of making it easy for humans to perform highly complex tasks without extreme mental effort or living with the constant fear of making a mistake.

[0004] The second type of wallet is called a "custodial wallet." When using a custodial wallet, the wallet owner entrusts a third party with the storage and operation of the private keys that control the assets in the wallet. Typically, such a third party, for example a major exchange market, does not store the assets of individual wallets, but holds them in a large pool. In this respect, the wallet is more similar to a bank account. However, custodial wallets may be vulnerable to large-scale attacks against the custodial wallet provider. In addition, the risk of the custodial wallet provider going bankrupt (due to a large-scale attack) cannot be ignored.

[0005] The third type of wallet is called a "Smart Contract Wallet". In a smart contract wallet, the assets are managed by a (Ethereum) smart contract. Such smart contract wallets offer various features such as multi-signature authentication, rate limiting, social recovery (friends can help you recover your wallet), temporary locking of the wallet, etc. However, smart contract wallets are still considered to be quite sensitive to human error (so wallet owners need to be well organized). The adoption of concepts like smart contracts is expanding.

[0006] In Ethereum, transactions (ETH transfers, ERC20 transfers, smart contract calls) are issued using signatures signed with a private key corresponding to a public key associated with an account. In social recovery, 3-5 witnesses can change the public key associated with an account. Additionally, the signing key can be used to sign messages that may change witnesses after a delay (often 1-3 days). Summary of the Invention [Problem to be solved by the invention]

[0007] There may be a demand to improve the cryptocurrency wallet concept and reduce the risks for wallet owners.

[0008] This need is addressed by the subject matter of the independent claims. [Means for solving the problem]

[0009] Various embodiments of the present disclosure are based on the discovery that a cryptocurrency wallet can be provided that mitigates risks to the wallet owner by using a new type of wallet called a "guard (crypto) wallet" together with a key recovery mechanism. In the proposed concept, the wallet owner's individual wallet is managed and executed within a trusted execution environment on a first remote server. A cryptographic secret stored in the wallet and a wallet management application (wallet manager) operated by the wallet owner creates a link between the wallet and the wallet management application, allowing the wallet owner to sign instructions to control the cryptocurrency wallet from his or her wallet management application. If the wallet management application is lost, e.g., if the computer or mobile device used to run the wallet management application fails or is lost, or if said application is accidentally deleted, access can be restored via a second remote server that hosts a second cryptographic secret that serves as a recovery key, and the second remote server can be used to install a new cryptographic secret between the wallet management application and the wallet hosted on the first remote server. The second cryptographic secret can be obtained once the wallet owner is authenticated to the second remote server (e.g., by using a government-backed identification scheme). This resulted in the concept of a crypto-wallet, which gives the owner sole control over their crypto-wallet and the ability to restore access even if access to the wallet is temporarily lost due to a lost or malfunctioning device or accidentally deleted application.

[0010] Various aspects of the present disclosure relate to a wallet management apparatus. The wallet management apparatus includes a processing circuit configured to register a new first cryptographic secret in a cryptocurrency wallet hosted in a trusted execution environment on a first remote server. Registering the new first cryptographic secret includes generating a first cryptographic secret. Registering the new first cryptographic secret includes obtaining a second cryptographic secret from a second remote server when an owner of the cryptocurrency wallet is authenticated to the second remote server. Registering the new first cryptographic secret includes signing control instructions for registering the first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret. Registering the new first cryptographic secret includes transmitting the signed control instructions to a first remote server for registering the first cryptographic secret in the cryptocurrency wallet. The processing circuit includes issuing cryptographically protected instructions based on the first cryptographic secret to the first remote server for controlling the cryptocurrency wallet. In the proposed concept, a second cryptographic secret, which can be used to register a new first cryptographic secret in the wallet, can be recovered from a second remote server once the owner has authenticated to said second remote server, thereby allowing to restore access to the wallet in case the previously used first cryptographic secret is lost.

[0011] For example, the processing circuit may be configured to register a new first cryptographic secret after a previously used first cryptographic secret is lost. In this way, a new first cryptographic secret can be registered after a previously used first cryptographic secret is lost.

[0012] There are various approaches to cryptography. In some embodiments, an approach called public key authentication is used, which is based on a key pair consisting of a private key and a public key. Typically, the private key is kept by the key owner, while the public key is distributable and can be used to verify messages signed with the private key. For example, the first cryptographic secret may be a private key of a device authorization key pair. The processing circuit may be configured to derive a public key of the device authorization key pair from the private key of the device authorization key pair. The processing circuit may be configured to include the public key of the device authorization key pair in the control command for registering the first cryptographic secret. That is, after generating a private key, the corresponding public key (for verifying commands signed with the private key) may be sent to and stored in the wallet for verifying commands issued by a wallet management device.

[0013] Similarly, the second cryptographic secret may be a private key of a device registration key pair, and a public key of the device registration key pair may be known to the cryptocurrency wallet, where the public key of the device registration key pair may be used to verify instructions, such as control instructions, for registering a new first cryptographic secret, that are signed using the private key of the device registration key pair.

[0014] For example, the processing circuit may be configured to obtain a response from the first remote server in response to the signed control instructions for registering the first cryptographic secret in the cryptocurrency wallet, and the response may include a confirmation of the cryptocurrency wallet if the private key of the device registration key pair matches the public key of the device registration key pair stored in the cryptocurrency wallet. That is, if the registration of the new first cryptographic secret is successful, a confirmation response may be issued by the wallet, which is also a confirmation response that the private key of the device registration key pair is valid for registering the new first cryptographic secret.

[0015] The control instructions for registering the first cryptographic secret to the cryptocurrency wallet may include a first instruction for deleting a previously used first cryptographic secret from the cryptocurrency wallet and a second instruction for registering a new first cryptographic secret to the cryptocurrency wallet, such that deleting a previously used first cryptographic secret can increase security in the event that a device having a previously used first cryptographic secret is lost.

[0016] In some embodiments, the processing circuitry may be configured to authenticate the owner of the cryptocurrency wallet to the second remote server by providing a signed identity proof to the second remote server. The signed identity proof may be signed by an independent entity. The processing circuitry may be configured to obtain a second cryptographic secret in response to the authentication. That is, the wallet management device may authenticate the owner to the remote server.

[0017] For example, the processing circuitry may be configured to obtain the signed identity from the independent entity, such that in the event of loss of the signed identity (e.g., if a previously used device fails or is lost), the signed identity may be restored from the independent entity.

[0018] In some embodiments, the processing circuitry may be configured to include the signed identity certificate along with a subset of instructions for controlling the cryptocurrency wallet, some instructions, such as instructions for setting and resetting rate limits and registering a new first cryptographic secret, may be protected by this additional layer of security.

[0019] Alternatively, authentication of the cryptocurrency wallet owner to the second remote server may occur external to the wallet management device, for example in person, to further secure key recovery.

[0020] Some aspects of the present disclosure relate to a mobile device comprising the wallet management apparatus presented above. Digital transactions, such as digital cryptocurrency transactions, are often performed from mobile devices, such as smartphones.

[0021] Various aspects of the present disclosure relate to a system including a wallet management apparatus as introduced above and a second remote server. The second remote server has memory circuitry configured to store a second cryptographic secret. The second remote server has processing circuitry configured to provide the second cryptographic secret in response to an owner of a cryptocurrency wallet being authenticated to the second remote server. Thus, the second remote server can recover the second cryptographic secret once the owner is authenticated to the second remote server.

[0022] In some embodiments, as outlined above with respect to a wallet management device, the processing circuitry of the second remote server may be configured to authenticate the owner to the second remote server based on a signed identification certificate of the owner and information about the identity of the owner of the cryptocurrency wallet stored at the second remote server, where the signed identification certificate may be signed by an independent entity. For example, the information about the identity of the owner may be used to verify the signed identification certificate.

[0023] For example, the signed identity certificate may be provided by a wallet management device, and the processing circuitry of the second remote server may be configured to obtain the signed identity certificate from the wallet management device, thereby facilitating faster recovery of the second cryptographic secret.

[0024] Alternatively, the processing circuitry of the second remote server may be configured to obtain the signed identity proof from an entity other than the wallet manager, for example by a principal using, for example, a smart card and a secret code to further secure key recovery.

[0025] The signed identity certificate may be derived from a trust anchor, such as a trust anchor provided by a government agency, so that the signed identity certificate can be restored or a new certificate can be issued in the event of loss. For example, the signature of the signed identity certificate may be derived from a trust anchor. The processing circuitry of the second remote server may be configured to verify the signed identity certificate based on the public key of the trust anchor.

[0026] In some embodiments, the system includes a plurality of second remote servers. For example, the system may include two or more second remote servers. The processing circuitry of the wallet management device may be configured to obtain the second cryptographic secret from the two or more second remote servers. This may provide additional redundancy or security depending on whether the multiple second remote servers store the entire second cryptographic secret or portions of the second cryptographic secret.

[0027] For example, the processing circuitry of the wallet management device may be configured to select one of the two or more second remote servers and obtain the second cryptographic secret from the selected second remote server, thereby adding redundancy to the two or more second remote servers.

[0028] Alternatively or additionally, the processing circuitry of the wallet management device may be configured to obtain two or more parts of the second cryptographic secret from the two or more second remote servers and combine the two or more parts to obtain the second cryptographic secret, which may improve security since a wallet owner needs to authenticate, e.g. directly, to multiple second remote servers.

[0029] In some embodiments, the system further comprises a first remote server, the first remote server may have processing circuitry configured to provide a trusted execution environment and to perform operations related to the cryptocurrency wallet within the trusted execution environment, the first remote server being used to securely host the cryptocurrency wallet.

[0030] As outlined above with respect to the wallet management device, the first cryptographic secret may be a private key of a device authorization key pair. The control instructions for registering the first cryptographic secret may include a public key of the device authorization key pair. The processing circuitry of the first remote server may be configured to store the public key of the device authorization key pair in a cryptocurrency wallet of a trusted execution environment. The public key of the device authorization key pair may then be used to verify instructions received from the wallet management device.

[0031] For example, the second cryptographic secret may be a private key of a device registration key pair. The processing circuitry of the first remote server may be configured to store a public key of a device registration key pair in the cryptocurrency wallet in the trusted execution environment and verify the signed control instructions for registering the first cryptographic secret based on the public key of the device registration key pair. This allows a counterpart of the second cryptographic secret to be (persistently) stored in the cryptocurrency wallet.

[0032] As outlined above, transactions on a cryptocurrency blockchain are signed using a cryptocurrency key (pair). Typically, the cryptocurrency key (pair) is stored in a cryptocurrency wallet. The processing circuitry of the first remote server may be configured to store, in the cryptocurrency wallet in the trusted execution environment, a third cryptographic secret for signing transactions on the cryptocurrency blockchain, and to sign transactions on the cryptocurrency blockchain using the third cryptographic secret.

[0033] In various embodiments, the processing circuitry of the first remote server may be configured to store a public key of a trust anchor and store information regarding the identity of the cryptocurrency wallet owner in a wallet in the trusted execution environment, and these two pieces of information may be used to verify a signed identity certificate of the cryptocurrency wallet owner.

[0034] For example, the subset of instructions for controlling the cryptocurrency wallet may require inclusion of a signed identity of the cryptocurrency wallet owner, and the signature of the signed identity may be derived from a trust anchor. The processing circuitry of the first remote server may be configured to verify the subset of instructions based on information in the signed identity, information about the identity of the cryptocurrency wallet owner, and the public key of the trust anchor. That is, some critical instructions, such as setting rate limits or registering a new first cryptographic secret, may be additionally protected by a signed identity provided by the cryptocurrency wallet owner.

[0035] In some embodiments, the second remote server may be configured to provide confirmation information to the first remote server regarding a second cryptographic secret stored by the second remote server, the confirmation information may include information regarding the identity of the owner of the cryptocurrency wallet. Once confirmation is obtained, the cryptocurrency wallet set-up may be considered complete.

[0036] Generally, software code running in the trusted execution environment may be audited by a third party, to ensure that no data is leaked from the first remote server.

[0037] Various aspects of the present disclosure relate to a wallet management method, the method including registering a new first cryptographic secret in a cryptocurrency wallet hosted in a trusted execution environment on a first remote server. Registering the new first cryptographic secret includes generating a first cryptographic secret. Registering the new first cryptographic secret includes obtaining a second cryptographic secret from a second remote server when an owner of the cryptocurrency wallet is authenticated to the second remote server. Registering the new first cryptographic secret includes signing control instructions for registering the first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret. Registering the new first cryptographic secret includes transmitting the signed control instructions to a first remote server for registering the first cryptographic secret in the cryptocurrency wallet. The method includes issuing cryptographically protected instructions based on the first cryptographic secret to the first remote server for controlling the cryptocurrency wallet.

[0038] Various aspects of the present disclosure relate to a computer program having a program code for performing the above methods, when the computer program is run on a computer, a processor or a programmable hardware component.

[0039] Some embodiments of the apparatus and / or methods will now be described, by way of example only, with reference to the accompanying figures, in which: FIG. [Brief description of the drawings]

[0040] [Figure 1a] FIG. 2 is a block diagram showing an example of a wallet management device. [Figure 1b] 1 is a flow chart illustrating an example of a wallet management method. [Figure 1c] 1 is a schematic diagram illustrating an example of a system including a wallet management device, a first remote server, and a second remote server. [Diagram 2] 1 is a schematic diagram of a system including a wallet management device and a first remote server that hosts a cryptocurrency wallet. [Diagram 3] FIG. 2 is a schematic diagram of a first remote server hosting a trusted execution environment cryptocurrency wallet. [Figure 4] FIG. 2 is a schematic diagram showing the contents of a cryptocurrency wallet hosted on a first remote server. [Diagram 5] 1 is a schematic diagram of a system including a wallet management device, a first remote server that hosts cryptocurrency wallets, and a second remote server that provides a vault service. [Figure 6] FIG. 1 illustrates the creation of a cryptocurrency wallet hosted in a trusted execution environment of a first remote server. [Figure 7] FIG. 1 illustrates how an operation is performed on a cryptocurrency wallet hosted in a trusted execution environment of a first remote server. [Figure 8] FIG. 1 illustrates how access to a cryptocurrency wallet hosted in a trusted execution environment of a first remote server is restored. [Figure 9] FIG. 13 illustrates the use of multiple second remote servers. [Figure 10] FIG. 1 illustrates how access to a cryptocurrency wallet hosted in a trusted execution environment of a first remote server is forwarded to other devices of the wallet owner. [Figure 11] FIG. 1 illustrates how rate limits and other usage controls can be configured on a cryptocurrency wallet hosted in a trusted execution environment on a first remote server. [Figure 12] FIG. 1 illustrates how a cryptocurrency wallet hosted in a trusted execution environment on a first remote server is protected by persistent storage and redundancy. [Figure 13] FIG. 1 illustrates emergency measures that may be taken to restore a cryptocurrency wallet hosted in a trusted execution environment of a first remote server. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0041] Some embodiments are described in more detail below with reference to the accompanying drawings. However, other possible embodiments are not limited to the features of these embodiments described in detail. Other embodiments may include equivalents and alternatives of features as well as modifications of features. Furthermore, the terms used in this specification to describe certain embodiments do not limit further possible embodiments.

[0042] Throughout the description of the figures, the same or similar reference numbers indicate the same or similar elements and / or features, which may be the same or may be implemented in modified forms while providing the same or similar functionality. The thickness of lines, layers and / or regions in the figures may be exaggerated for clarity.

[0043] When two elements A and B are combined using "or", this is to be understood as disclosing all possible combinations, e.g. only A, only B, A and B, etc. As alternative expressions of a similar combination, "at least one of A and B" or "A and / or B" may also be used. This applies equally to combinations of two or more elements.

[0044] Where singular forms such as "a, an, the" are used and the use of only a single element is not explicitly or implicitly defined as required, further embodiments may also implement the same functionality using multiple elements. Where functionality is described below as being implemented using multiple elements, further embodiments may implement the same functionality using a single element or a single processing entity. It is further understood that when the terms "include", "including", "comprise" and / or "comprising" are used, they represent the presence of specified features, integers, steps, operations, processes, elements, components and / or groups thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or groups thereof.

[0045] FIG. 1a is a block diagram illustrating an example of a wallet management device 110. The wallet management device 110 includes a processing circuit 114. The processing circuit 114 is configured to provide the functionality of the wallet management device 110. Optionally, the wallet management device 110 further includes an interface 112 (e.g., an interface circuit) for communicating with other entities, such as a first remote server 120 and / or a second remote server 130 (shown in FIG. 1c), and / or a memory circuit 116 for storing information. The processing circuit 114 shown in FIGS. 1a and 1c is connected to the optional interface 112 and the optional memory circuit 116. For example, the processing circuit 114 may be configured to cooperate with the interface 112 (for communication) and / or the memory circuit 116 (for storing and retrieving information) to provide the functionality of the wallet management device 110. For example, the wallet management device 110 may be part of a computer system, such as a personal computer, a tablet computer, or a smartphone. The functionality of the wallet management unit may be provided as software, for example as a wallet management application executed by the respective computer system.

[0046] The processing circuit 114 is configured to register a new first cryptographic secret in a cryptocurrency wallet hosted in a trusted execution environment on a first remote server 120 (shown in FIG. 1c). Registering the new first cryptographic secret includes generating a first cryptographic secret. Registering the new first cryptographic secret includes obtaining (e.g., receiving via interface 112) a second cryptographic secret from a second remote server 130 (shown in FIG. 1c) when an owner of the cryptocurrency wallet is authenticated to the second remote server. Registering the new first cryptographic secret includes signing control instructions for registering the first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret. Registering the new first cryptographic secret includes transmitting (e.g., via interface 112) the signed control instructions for registering the first cryptographic secret in the cryptocurrency wallet to the first remote server. The processing circuit 114 is configured to provide (e.g., transmit via the interface 112) to a first remote server cryptographically protected instructions based on a first cryptographic secret for controlling the cryptocurrency wallet.

[0047] FIG. 1b shows a flow chart of an example of a corresponding wallet management method. The method includes registering (10) a new first cryptographic secret in a cryptocurrency wallet hosted in a trusted execution environment on a first remote server. Registering the new first cryptographic secret includes generating (12) a first cryptographic secret. Registering the new first cryptographic secret includes obtaining (14) a second cryptographic secret from a second remote server 130 (shown in FIG. 1c) when the owner of the cryptocurrency wallet is authenticated to the second remote server. Registering the new first cryptographic secret includes signing (16) control instructions for registering the first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret. Registering the new first cryptographic secret includes transmitting (18) the signed control instructions for registering the first cryptographic secret in the cryptocurrency wallet to the first remote server. The method includes providing (20) cryptographically protected instructions based on the first cryptographic secret to the first remote server for controlling the cryptocurrency wallet.

[0048] It is clear that the wallet management device, wallet management method and corresponding wallet management computer program (e.g., wallet management application) interact with two other entities, namely, a first remote server 120 and a second remote server 130. FIG. 1c is a schematic diagram illustrating an example of a system comprising a wallet management device 110, a first remote server 120 and a second remote server 130. Similar to the computer system hosting the wallet management device 110 [Takahashi 1], the first remote server 120 and the second remote server 130 may be computer systems comprising processing circuits 124, 134 and optionally interfaces 122, 132 and / or storage circuits 126, 136. For example, the first remote server 120 comprises a processing circuit 124 and optionally an interface 122 and / or a storage circuit 126. The processing circuit 124 shown in FIG. 1c is connected to the optional interface 122 and the optional storage circuit 126. For example, the processing circuitry 124 may be configured to cooperate with the interface 122 (for communicating with the wallet management device 110 and / or the second remote server 130) and / or the memory circuitry 126 (for storing and retrieving information) to provide the functionality of the first remote server 120. Similarly, the second remote server 130 includes a processing circuitry 134 and, optionally, an interface 132 and / or a memory circuitry 136. The processing circuitry 134 shown in FIG. 1c is connected to the optional interface 132 and the optional memory circuitry 136. For example, the processing circuitry 134 may be configured to cooperate with the interface 132 (for communicating with the wallet management device 110 and / or the first remote server 120) and / or the memory circuitry 136 (for storing and retrieving information) to provide the functionality of the second remote server 130.

[0049] The first remote server 120 and the second remote server 130 interact with the wallet management device 110. For example, the storage circuitry 136 of the second remote server is configured to store a second cryptographic secret. The processing circuitry 134 of the second remote server may be configured to provide the second cryptographic secret (to the wallet management device 110) in response to authentication of the owner of the cryptocurrency wallet to the second remote server. Meanwhile, the processing circuitry 124 of the first remote server 120 is configured to provide a trusted execution environment and to perform operations related to the cryptocurrency wallet within the trusted execution environment. That is, the processing circuitry 124 of the first remote server 120 may be configured to host the cryptocurrency wallet within the trusted execution environment.

[0050] In the following, the functionality of the wallet management device, wallet management method, wallet management computer program, and system are briefly introduced with respect to the wallet management device and system. Features introduced in relation to the wallet management device and system may also be included in the corresponding wallet management method and wallet management computer program, including features executed by the first remote server and the second remote server. That is, the wallet management method and wallet management computer program may also include features introduced in relation to the first remote server and / or the second remote server.

[0051] The proposed concept is directed to registering a new first cryptographic secret in a cryptocurrency wallet hosted in a trusted execution environment on a first remote server 120. Such a scenario may occur after initialization of the cryptocurrency wallet. For example, during initialization of the cryptocurrency wallet, the respective cryptographic secret may be generated by the wallet management device and transmitted to the first remote server and stored in the cryptocurrency wallet. If after the cryptocurrency wallet is initialized, the respective cryptographic secret is lost, for example due to loss or malfunction of the device, or due to incorrect operation of the wallet management device or the device, the proposed concept may be used to store a new first cryptographic secret in the wallet, for example by modifying a previously used first cryptographic secret. For example, the processing circuitry of the wallet management device may be configured to register a new first cryptographic secret after the previously used first cryptographic secret is lost.

[0052] In the proposed concept, cryptocurrency wallets are stored in a trusted execution environment on a server. The wallet service device [Takahashi 2] is then configured to, for example, make available, manage, or make accessible such a trusted execution environment. There are various implementations of trusted execution environments. A trusted execution environment may, for example, be called a secure enclave. In general, a trusted execution environment is an execution environment that is encapsulated (i.e., shielded) from other processes that run on the processing circuitry that provides the trusted execution environment. In particular, processes that run outside of a particular trusted execution environment may not be able to read or write data or code contained in the trusted execution environment. In the proposed concept, in particular, the wallet contents and the wallet service application may not be accessible from outside the trusted execution environment, except for an interface used, for example, to update the wallet service application.

[0053] For example, the software code of a wallet service application running in the trusted execution environment may be audited by a third party, may be updated using the interfaces described above, may be cryptographically protected, and the contents of the wallet may remain shielded within the trusted execution environment at any time.

[0054] Various embodiments of the present disclosure use public-private key cryptography, i.e., the private key of a cryptographic key pair is used to sign something, such as an instruction or an identity certificate, and the corresponding public key can be used to verify the signature, whereas the public key of the cryptographic key pair is used to encrypt information, and the private key can be used to decrypt that information.

[0055] For example, both the first cryptographic secret and the second cryptographic secret may be keys of a cryptographic key pair. For example, the first cryptographic secret may be a private key of a device authorization key pair. In general, the device authorization key pair may be used to sign and verify control instructions issued for the wallet by the wallet management device. The private key may reside in the wallet management device and be used to sign the control instructions, and the public key may be stored in the cryptocurrency wallet. Thus, the processing circuitry of the wallet management device may be configured to generate a device authorization key pair having a private key and a public key. For example, the processing circuitry of the wallet management device may be configured to derive a public key of the device authorization key pair from the private key of the device authorization key pair. The processing circuitry of the wallet management device may be configured to transmit the public key to a first remote server for storage in the cryptocurrency wallet. For example, the processing circuitry of the wallet management device may be configured to include the public key of the device authorization key pair in the control instructions for registering the first cryptographic secret. That is, the control instructions for registering the first cryptographic secret may include the public key of the device authorization key pair.

[0056] Similarly, the second cryptographic secret may be part of a cryptographic key pair. For example, the second cryptographic secret may be a private key of a device registration key pair. For example, the device registration key pair is used to register a new device that is authorized to manage the cryptocurrency wallet. The device registration key pair may be generated during initialization of the wallet, and the private key (i.e., the second cryptographic secret) may be stored by the second remote server in the wallet management device, so that the device comprising the wallet management device can be restored if lost or broken. The public key of the device registration key pair may be known to (e.g., stored in) the cryptocurrency wallet, so that it may be used by the first remote server (e.g., the cryptocurrency wallet) to verify the signed control instructions for registering the first cryptographic secret. For example, the second cryptographic secret may be received from the second remote server, e.g., after the owner of the cryptocurrency wallet has successfully authenticated to the second remote server. This authentication may be performed by the wallet management device or may be performed without involving the wallet management device. In particular, the owner may identify himself / herself directly with the company hosting the second remote server.

[0057] A control instruction is generated, signed, and transmitted to register a new first cryptographic secret in the cryptocurrency wallet. In contrast to the other instructions for controlling the wallet, the control instruction is not signed using the first cryptographic secret (e.g., the private key of the device authorization key pair) but is signed using a second cryptographic secret (e.g., the private key of the device registration key pair) because the previously used first cryptographic secret (known to the cryptocurrency wallet) has been lost. For example, the control instruction may instruct the cryptocurrency wallet to register the new first cryptographic secret (and in particular the public key of the new device authorization key pair) in the wallet. The control instruction may also instruct the cryptocurrency wallet to delete the previously used first cryptographic secret (i.e. the public key of the previously used device authorization key pair) from the cryptocurrency wallet. Once the control instruction is generated and signed (using the private key of the second cryptographic secret / device registration key pair), the control instruction is transmitted to a first remote server. In this context, the term signing means that the second cryptographic secret is used to generate a digital signature based on the control instruction (e.g., based on a hash value of the control instruction including the public key of a device authorization key pair) that can be used to verify that a) the control instruction has not been tampered with and b) the control instruction was signed by an entity that holds the second cryptographic secret (and is therefore authorized to issue the control instruction).

[0058] In the first remote server, in particular in a cryptocurrency wallet in the trusted execution environment, the signed control instruction may be verified and a public key of the device authorization key pair may be extracted from the control instruction and stored in the cryptocurrency wallet. For example, the processing circuitry of the first remote server may be configured to store the public key of the device registration key pair in a cryptocurrency wallet in the trusted execution environment and to verify the signed control instruction for registering the first cryptographic secret based on the public key of the device registration key pair. The processing circuitry of the first remote server may be configured to extract the public key of the device authorization key pair from the signed control instruction. For example, the processing circuitry of the first remote server may be configured to store the public key of the device authorization key pair in a cryptocurrency wallet in the trusted execution environment and to store the public key of the device authorization key pair in the cryptocurrency wallet.

[0059] If the registration of the new first cryptographic secret is successful, the first remote server may confirm that the registration of the wallet management device is successful. For example, the processing circuitry of the wallet management device may be configured to obtain a response from the first remote server in response to the signed control instruction for registering the first cryptographic secret in the cryptocurrency wallet. For example, the response may include confirmation of the cryptocurrency wallet if the private key of the device registration key pair matches the public key of the device registration key pair stored in the cryptocurrency wallet, i.e., if the control instruction signed with the private key of the device registration key pair can be verified using the public key of the device registration key pair stored in the cryptocurrency wallet. Thus, the processing circuitry of the first remote server may be configured to provide a response to the wallet management device upon verification of the signed control instruction.

[0060] Once the new first cryptographic secret is installed in the wallet, the new first cryptographic secret can be used to sign subsequent instructions for controlling the cryptocurrency wallet. The processing circuitry of the wallet management device is configured to provide the (subsequent) instructions for controlling the cryptocurrency wallet to the first remote server, where the instructions are cryptographically protected based on the first cryptographic secret. For example, the instructions may be cryptographically signed using the new first cryptographic secret (e.g., a private key of a device authentication key pair).

[0061] A more detailed introduction of the (optional) features and functions of the wallet management device, wallet management method, wallet management computer program and system will be described below in conjunction with Figures 2-12. In Figures 2-12, the wallet management device is referred to as "Wallet App" 252 (Figures 2, 9-10) or "Crypto Wallet" (Figures 6-8). The wallet management device may also be included in a mobile device 250 (shown in Figures 2 and 10) or a personal computer 1010 (shown in Figure 10). The first remote server is referred to as "Wallet Support Service" and the second remote server is referred to as "Vault Service".

[0062] The interfaces 112, 122, 132 of the wallet management device 110 and the first remote server 120 and / or the second remote server 130 may correspond to one or more inputs and / or outputs for receiving and / or transmitting information, which is a digital (bit) value according to a specified code, within a module, between modules, or between modules of different entities. For example, the interfaces 112, 122, 132 of the wallet management device 110 and the first remote server 120 and / or the second remote server 130 may comprise interface circuitry configured to receive and / or transmit information.

[0063] For example, the processing circuits 114, 124, 134 of the wallet management apparatus 110 and the first remote server 120 and / or the second remote server 130 may be implemented using one or more processing units, one or more processing devices, any processing means, such as a processor, computer or programmable hardware component operable with appropriately configured software. That is, the above-mentioned functions of the processing circuits 114, 124, 134 of the wallet management apparatus 110 and the first remote server 120 and / or the second remote server 130 may also be implemented in software and then executed on one or more programmable hardware components. Such hardware components may include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc. For example, at least the processing circuit 124 of the first remote server may be suitable for or configured to provide a trusted execution environment, such as Intel Software Guard Extensions, AMD Platform Security Processor or Secure Encrypted Virtualization, ARM TrustZone or RISC-V MultiZone, etc.

[0064] For example, the memory circuits 116, 126, 136 of the wallet management device 110 and the first remote server 120 and / or the second remote server 130 may be comprised of at least one element from the group of computer readable storage media, such as, for example, a hard disk drive, a flash memory, a floppy disk, a RAM (Random Access Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) or a magnetic or optical storage medium such as a network storage.

[0065] Details and aspects of the wallet management device, the first remote server, the second remote server, the system, the method, and the computer program are described in relation to the proposed concept or one or more embodiments described above or below (e.g., FIGS. 2-13). The wallet management device, the first remote server, the second remote server, the system, the method, and the computer program may have one or more optional additional features corresponding to one or more aspects of the proposed concept or one or more embodiments described above or below.

[0066] In Figure 1a-1c, the core functionality of a concept called "Guard (crypto) wallet" is introduced. This wallet is a new type of wallet and may be suitable for the average, non-tech-savvy user who is not good at organizing. It may be configured as a (paid) service to free users from the worry of losing their keys. It may provide an easy and simple user experience, with minimal user setup for recovery, for example. It may be implemented as a self-custodial wallet, if possible, reducing the security risks against (large-scale) attacks.

[0067] The proposed concept consists of three components. The first remote server may be a cloud service that stores wallet assets (private keys) using secure enclave technology (like Intel SGX) so that the cloud provider cannot access the wallet assets. This makes the proposed concept self-custodial. The wallet may be operated by the user from a wallet manager (second component) hosted on a mobile phone, from which signed wallet instructions are sent to the wallet in the cloud, where the wallet instructions are executed.

[0068] An external authentication infrastructure outside the control of the cloud service may optionally be used for wallet access and / or recovery (e.g., for the cryptocurrency wallet owner to be authenticated to a third component, a second remote server). For example, a Self-Sovereign Identity (SSI) infrastructure may be used. For example, an SSI key may be used, where the user registers the SSI key with a government agency and receives verifiable credentials for the SSI key. Alternatively, other forms of authentication infrastructure may be used for access to government websites, banking services, etc. To validate the verifiable credentials used for authentication, the cloud service may have trust anchors, ideally in an enclave. These may be updated via software updates.

[0069] FIG. 2 is a schematic diagram of a system including a wallet manager (wallet app 252) and a first remote server hosting a cryptocurrency wallet 230. FIG. 2 illustrates a wallet support service using secure enclave(s) 210 (trusted execution environment). The secure enclave protects the cloud owner from operations within the enclave (thus implementing self-custodial cryptocurrency wallets). The enclave (or enclaves) may isolate a small kernel of security-sensitive code from the operating system and main software stack. They may be strongly protected against attacks. Inside the secure enclave, individual user wallets 230 store asset keys.

[0070] To regain access to the wallet 230, the proposed concept may use a renewable form of authentication. For example, SSI certificates 220 distributed by the government may be used for authentication. These certificates 220 can be held by the owner and stored in the wallet 230 within the secure enclave 210. In this context, "renewable" means that if the wallet owner loses their authentication secret (e.g., a private key linked to an authentication certificate issued by an SSI operated by a government agency), they generate a new authentication secret, register it with the government agency, and are provided with a new SSI certificate (signed identity document) signed by the government agency.

[0071] A challenge with secure enclaves is that the code may need to be periodically upgraded for new features, security and other (latest) fixes. For this reason, a mechanism may be used to have the cloud provider involve an independent auditor 240 for all changes applied to the code. The independent auditor 240 may verify the correctness of the code running within the enclave and control the code upgrade process. That is, the software code running in the trusted execution environment may be audited by a third party. Although this somewhat reduces the self-management nature of the proposed concept, it should provide some assurance that the wallet keys cannot be accessed by anyone involved in the day-to-day operation of the cloud service.

[0072] FIG. 2 shows an owner's mobile device 250 with a wallet app 252 (wallet manager). The wallet app 252 contains two private keys: the private key 260 and the public key 265 of a device authorization key pair, and the private key 270 of a device registration key pair. The wallet app 252 uses the private key 260 of the device authorization key pair to add a signature 256 to instructions 254 for performing wallet operations. The wallet 230 contains the public keys 265, 275 of the device authorization key pair and the device registration key pair. The wallet 230 further contains the private key 280 and the public key 285 of a wallet (blockchain) key pair for performing operations on the blockchain 290. That is, the processing circuitry of the first remote server may be configured to store in the cryptocurrency wallet in the trusted execution environment a third cryptographic secret for signing transactions on the cryptocurrency blockchain 290 (e.g., a wallet key pair, a private key of the wallet key pair, or a seed key of a Hierarchical Deterministic (HD) scheme used to generate a private key for signing transactions on the blockchain). For example, the processing circuitry of the first remote server may be configured to sign transactions on the cryptocurrency blockchain using the third cryptographic secret.

[0073] In general, the private key of each public / private key pair can be used to sign messages, data structures, etc. The public key of each public / private key pair can be used to verify whether a signature was created with the corresponding private key. When sending crypto assets, the private key of the wallet key pair may be used to sign a transaction on the cryptocurrency blockchain. In that case, the private key of the wallet key pair is a cryptographic code that acts as a secret password that allows a user to sign cryptocurrency transactions to send funds to another cryptocurrency address.

[0074] In Figure 3, the characteristics of the trusted execution environment (secure enclave) and the contents of the cryptocurrency wallet are shown in more detail according to an embodiment. Figure 3 is a schematic diagram of a first remote server hosting a cryptocurrency wallet in a trusted execution environment (secure enclave) 310. In the following, the terms secure enclave and trusted execution environment are used interchangeably.

[0075] FIG. 3 illustrates a secure enclave 210 having a cryptocurrency wallet. In various examples, the wallet service operator does not have access to the wallet key (stored within the secure enclave) and cannot initiate any operations with the wallet key. The code that runs in the secure enclave is highly protected code, e.g., a small kernel of code that has only critical portions of functionality. This can reduce security risks resulting from large software stacks with zero-day vulnerabilities.

[0076] The wallet support service 310 (provided by a first remote server) can be linked to a natural person with "bank level security" and renewable authentication (eID (Electronic Identification), bank card token, etc.).

[0077] An independent auditor 240 may audit the code running within the enclave to ensure proper operation and security. When a software update is due, the running code may hand over the internal key to the new version of the code if the new version of the code is signed by the audit service. Additionally, the independent auditor 240 may approve changes to the trust anchors for identity validation (in software updates).

[0078] FIG. 4 is a schematic diagram showing the contents of an example of a cryptocurrency wallet hosted by a first remote server. The proposed concept may be aimed at creating self-custodial wallets hosted by a wallet support service. Each wallet may therefore be associated with a single user (per wallet use). A cryptocurrency wallet may have a device authentication public key 265. The party holding the corresponding private key 260 can issue operations on the assets in this wallet. A cryptocurrency wallet may have a device registration public key 275. The party holding the corresponding private key 270 can register / unregister devices that can manage this wallet. A cryptocurrency wallet may have a wallet key pair 280, 285 generated by the wallet service at the time of user wallet creation. The private key of the wallet key pair manages the assets associated with the wallet (by signing blockchain operations).

[0079] The following illustrates the use of a vault service (i.e., a second remote server) to recover a second cryptographic secret. Figure 5 is a schematic diagram of a system including a wallet management device, a first remote server hosting a cryptocurrency wallet, and a second remote server providing a vault service.

[0080] The proposed concept is based on recovering the second cryptographic secret (i.e. the private key of the device registration key pair) using an independent vault service. To obtain the second cryptographic secret from the vault service, the owner of the cryptocurrency wallet needs to authenticate to the vault service and, optionally, to the first remote server (as an additional security measure to send a signed control instruction for registering the new first cryptographic secret). The main purpose of the authentication is to avoid that the vault service can access the wallet without the intervention of the user.

[0081] Part of the onboarding process can be for the user to select the independent vault service(s) they wish to use. The wallet support service can also verify that the vault service(s) have received the recovery key, relieving the user of wallet recovery worries.

[0082] In FIG. 5, a trust anchor 510 is introduced, which may be an anchor of trust for authentication of the wallet owner to two remote servers. In particular, it may be used for wallet restoration. For example, both the first and second remote servers may use the trust anchor to verify the identity (e.g., a signed identity certificate) of the cryptocurrency wallet owner. For example, the processing circuitry of the first remote server may be configured to store the public key of the trust anchor and store information 555 about the identity of the cryptocurrency wallet owner in a wallet of a trusted execution environment. Similarly, the processing circuitry of the second remote server may be configured to store the public key of the trust anchor and store information 555 about the identity of the cryptocurrency wallet owner. An independent vault service 520 (selected by the user) stores authentication information 555 that allows the user to regain access to his or her wallet.

[0083] With a wallet support service, the trust anchor(s) (and authentication) can be stored and performed outside of the Secure Enclave, which allows the solution to not be stored because a recovery key (for the device registration key pair) is required to recover a wallet that the wallet support service cannot access.

[0084] In Figure 5, trust anchor 510 is used by a government identification issuing authority 530 (which may support SSI). The government identification issuing authority 530 provides an identity certificate 540 (containing the user public key) signed by the authority, and a private key 550 to sign authentication requests. The wallet owner's national identity number 555 is stored in the independent vault service 520 and in the wallet (upon wallet creation). An authentication request signed by the wallet owner and accompanied by the identity certificate (or its SSI certificate) can be verified against the trust anchor(s).

[0085] Currently, there are many variations in authentication schemes (used for wallet restoration). For example, the processing circuitry of the wallet management device may be configured to authenticate the owner of the cryptocurrency wallet to the second remote server by providing a signed identity certificate (ID certificate 540 signed by a government agency) to the second remote server. For example, the signed identity certificate may be signed by an independent entity (e.g., an entity that manages trust anchors), such as a government agency. The processing circuitry of the wallet management device may be configured to obtain a second cryptographic secret in response to the authentication. For example, the signed identity certificate may be provided to verify an instruction signed with a private key 550 linked to the identity certificate 540 (provided to verify a signature). That is, the processing circuitry of the wallet management device may be configured to authenticate the owner of the cryptocurrency wallet to the second remote server by signing an instruction with a private key linked to the identity certificate, such that the signed instruction can be verified using the signed identity certificate. The wallet management device may receive the signed identity certificate from the independent entity. For example, the processing circuitry of the wallet management device (and each of the processing circuitry of the first and second remote servers) may be configured to obtain a signed identification certificate from an independent entity.

[0086] For example, authentication based on a signed identity may be similar to authentication performed according to Transport Layer Security (TLS). TLS is a cryptographic protocol used to provide communication security for communications occurring over computer networks, for example between a web server and a web browser. In TLS, the server provides the client with an identity that includes the server's name, a reference to a trusted Certificate Authority (CA) that vouches for the authenticity of the certificate, and the server's public key. The client uses the server's public key to encrypt a first encrypted message consisting of a random number. The server can decrypt the first encrypted message using its private key. This random number can be used to encrypt a Diffie-Hellman key exchange, which results in a session key that is used for subsequent communications. As mentioned above, the identity provided by the server includes a reference to a trusted CA that vouches for the authenticity of the certificate. In this way, a certificate chain is formed from the identity to the trusted CA. In many cases, the CA referenced is not a root Certificate Authority (CA) but an intermediate Certificate Authority (CA). Thus, to verify the authenticity of the certificate, the client follows the certificate chain up to an intermediate CA, which also provides a similar identification certificate containing a reference to a further intermediate CA or root CA. In this way, the certificate chain is extended to a further intermediate CA or root CA. When the certificate chain reaches the root CA, the certificate chain is complete. Typically, multiple CAs are organized in a hierarchical tree structure, all linking back to the root CA at the top of the tree. The public key associated with the signing key of the root CA is called a trust anchor. Trust anchors are typically hard-coded in entities that need to authenticate others, which is why they are called trust anchors. For example, the public key of the root CA may be stored in the client's "trusted root CA" store and serve as a trust anchor for the verification procedure. The client may follow the certificate chain to the root CA and verify the authenticity of the identification certificate.

[0087] The proposed concept may use a similar scheme, where the wallet manager plays the role of the server (in the TLS scheme) and the first (or second) remote server plays the role of the client (in the TLS scheme). For example, the wallet manager may generate or obtain a public / private key pair for the wallet owner, of which the public key is registered with the government agency associated with the trust anchor used. The government agency may sign the public key registered with the government agency and generate an identity certificate for it (using the owner's public key, an identifier identifying the owner, e.g. a passport number, and a reference to the trust anchor). The first and second remote servers may then use the signed identity certificate, guaranteed by the trust anchor, to verify that commands issued by the wallet manager were issued by the identity certificate owner. SSI is a more modern adaptation of this scheme, leveraging blockchain technology.

[0088] If the authentication is performed by a wallet management device, the second remote server may automatically verify the signed identity certificate. For example, the processing circuitry of the second remote server is configured to obtain the signed identity certificate from the wallet management device. As outlined above, the signature of the signed identity certificate may be derived from a trust anchor. In this case, the processing circuitry of the second remote server may be configured to verify the signed identity certificate based on the public key of the trust anchor (and based on the wallet owner's stored authentication information 555). The processing circuitry of the second remote server may be configured to authenticate the owner to the second remote server based on the owner's signed identity certificate and based on information about the identity of the owner of the cryptocurrency wallet (e.g., the wallet owner's authentication information / ID number 555) stored on the second remote server.

[0089] There are several variations on the human procedure. For example, the wallet owner may visit an office of the wallet support service and verify his / her identity. Thus, authentication of the cryptocurrency wallet owner to the second remote server may be performed external to the wallet management device. For example, the processing circuitry of the second remote server may be configured to obtain a signed identity certificate from an entity separate from the wallet management device. Alternatively, authentication verification may be performed manually by an operator of the second remote server.

[0090] The following describes the creation of a cryptocurrency wallet on the cloud. FIG. 6 illustrates the creation of a cryptocurrency wallet hosted in a trusted execution environment of a first remote server. As shown in FIG. 2, the user's cryptocurrency wallet on the mobile device (wallet management device) has a device registration private key 270 and a device authentication private key 260, which may be generated in the user's cryptocurrency wallet / app. A device registration public key 275 and a device authentication public key 265 are derived from the respective private keys and transferred and stored in the wallet on the wallet support server. The device registration public key 275 stored in the wallet allows the user to access the wallet by registering his / her device. The device authentication public key 265 allows the user to initiate operations on the assets in the wallet. The wallet key pair 280, 285 used to perform blockchain operations is also stored in the wallet. This key pair can be generated in the wallet on the user's device or in the cloud wallet. The device registration private key 270 (i.e., the second cryptographic secret) is further stored in an independent vault service. This allows the user to restore the device registration key.

[0091] User credentials 555 are stored in the cloud wallet and the independent vault service, allowing the user to always verify their identity (even after updating their identity credentials). Existing bank-standard security renewable authentication (e.g., using SSI credentials) may be used to authenticate the user to the independent vault service and cloud wallet support services. Authentication on the cloud wallet service may occur outside the secure enclave (authentication based on verifiable credentials inside the enclave requires a trusted, up-to-date trust anchor, which is difficult and can be a single point of failure).

[0092] Evidence 610 that the user has stored a copy of the registration key (= recovery key) at the independent vault service may be transferred from the independent vault service to the cloud wallet (and stored in the wallet). That is, the second remote server may be configured to provide the first remote server with verification information regarding the second cryptographic secret stored by the second remote server. For example, the verification information may include information regarding the identity of the owner of the cryptocurrency wallet.

[0093] After the respective cryptographic keys and information are stored with the respective entities, the wallet may be marked initialized and ready for use, at which point the wallet service may ensure that the user can always re-access the wallet.

[0094] 7 illustrates how operations are performed on a cryptocurrency wallet hosted in a trusted execution environment of a first remote server (i.e., a cloud wallet support service). Instructions 254 to perform wallet operations are signed 256 with a device authentication key 260 (i.e., a first cryptographic secret) and sent to the cloud wallet. At the cloud wallet, the signature is verified using a device authentication public key 265. A blockchain private key 280 is used to perform the blockchain operations.

[0095] It allows the Owner to restore access to their Cryptocurrency Wallet in the event that the Crypto Wallet / Wallet App on their Device or the Crypto Wallet App is lost (e.g. device is stolen or lost, app is deleted, etc.).

[0096] FIG. 8 illustrates how access to a cryptocurrency wallet hosted in a trusted execution environment of a first remote server is restored. During restoration, the wallet owner authenticates to the independent vault service and the cloud wallet service using his or her own identity certificate 540. A backup of the device registration private key 270 (i.e., the second cryptographic private key) is retrieved from the independent vault service and stored in the cryptographic wallet of the owner's own mobile device (i.e., the wallet management device). A new device authorization key pair (i.e., the first cryptographic secret) is created, and instructions 810 for deleting the old device and registering the new device are signed 820 with the device registration secret [Takahashi 4] key 270 and sent to the cloud wallet service. The signature is verified using the device registration public key 275. Thus, the control instructions for registering the first cryptographic secret to the cryptocurrency wallet may include a first instruction for deleting the previously used first cryptographic secret from the cryptocurrency wallet and a second instruction for registering the new first cryptographic secret to the cryptocurrency wallet.

[0097] In some embodiments, multiple vault services may be used. For example, the system may include two or more second remote servers. FIG. 9 illustrates the use of multiple second remote servers 520. For example, the processing circuitry of the wallet management device may be configured to obtain the second cryptographic secret from two or more second remote servers. In general, multiple second remote servers may be used for two purposes: for redundancy or to distribute the private key of the device registration key pair (i.e., the second cryptographic secret) across multiple second remote servers.

[0098] For example, when multiple second remote servers are used for redundancy purposes, the processing circuitry of the wallet management device is configured to select one of the two or more second remote servers and obtain the second cryptographic secret from the selected second remote server.

[0099] If the key is split across two or more (independent) vault services (as shown in FIG. 9), the wallet owner may reconstruct the wallet recovery key by taking portions of the key from m of the n vaults and combining them (e.g., using Shamir's secret sharing scheme). For example, the processing circuitry of the wallet management device may be configured to obtain two or more portions of the second cryptographic secret from two or more remote servers and combine the two or more portions to obtain the second cryptographic secret. For example, if the second cryptographic secret is split into multiple portions, a scheme may be used (e.g., Shamir's secret sharing scheme discussed above) that allows the second cryptographic secret to be reconstructed from a subset of the portions.

[0100] Although this disclosure is directed to a method for restoring access to a wallet via the vault service, access can also be transferred to a new (or secondary) device without going through the vault service. Figure 10 illustrates how access to a cryptocurrency wallet hosted in a trusted execution environment of a first remote server can be transferred to another device of the wallet owner.

[0101] In some cases, an owner may have multiple devices, such as a mobile device 250 and a computer 1010 that may host a cryptographic wallet app 1020. A wallet owner may request from one of the owner's devices that the wallet service allow them to access the wallet on another one of their devices. The original wallet app may send a signed request to the wallet support service that includes the public key (of the device authorization key pair) of the new wallet app. In this case, the previously used public key of the device authorization key pair is not deleted but is kept along with the new public key.

[0102] The proposed Guard Wallet may provide more advanced features such as rate limiting and other usage controls. Figure 11 shows how rate limits and other usage controls can be configured for a cryptocurrency wallet hosted in a trusted execution environment on a first remote server. Rate limits (e.g., daily transaction limits) and other usage controls may be imposed (by the wallet) and configurable by the user. If the configured limits are exceeded, they may be allowed after authentication (e.g., via a private key 550 signing the authentication request). For example, this authentication may be performed outside the secure enclave.

[0103] For example, the subset of instructions for controlling the cryptocurrency wallet may be required to include a signed identity of the owner of the cryptocurrency wallet (e.g., the instructions may be signed using the private key 550 that signs the authentication request). For example, the subset of instructions may include instructions for setting rate limits, instructions for removing or modifying rate limits, instructions for setting usage controls, instructions for removing or modifying usage controls, and control instructions for registering a new first cryptographic secret. The processing circuitry of the wallet manager may be configured to include the signed identity with the subset of instructions for controlling the cryptocurrency wallet (e.g., sign each instruction with the private key 550 that signs the authentication request). The processing circuitry of the first remote server may be configured to verify the subset of instructions based on information in the signed identity and information about the identity of the owner of the cryptocurrency wallet (and based on the public key of the trust anchor).

[0104] Alternatively, a multi-signature scheme can be used to secure large-scale operations, where a wallet in the enclave will proceed with a transaction if the request to perform the transaction is signed by multiple parties, which may be other people or other devices of the wallet owner.

[0105] Deleting a wallet may be a choice (or user option) in that the wallet cannot be deleted without first emptying it (transferring assets to another wallet).

[0106] Below we detail techniques to protect the wallet(s) stored in the secure enclave(s) of the first remote server. Figure 12 shows how cryptocurrency wallets hosted in the trusted execution environment of the first remote server can be protected with persistent storage and redundancy. When deploying cloud wallet services, security and backups are important. This may be subject to "bank-grade security levels."

[0107] For example, wallet assets may be encrypted and backed up to persistent storage. Figure 12 shows how an encrypted copy 1220 of wallet assets is left in persistent storage (e.g., storage circuitry 126 of the first remote server). Only the enclave(s) can decrypt (using the global wallet encryption key 1210). Wallet support services may be provided by secure hardware 1230 (e.g., processing circuitry 124 of the first remote server) with embedded encryption key 120 [Takahashi 5] that supports secure enclave technology (e.g., Intel SGX). Redundancy may be created by duplicating both the hardware (with keys) and persistent storage with wallet assets.

[0108] The proposed concept may support emergency procedures for the (highly unlikely) case that all Central Processing Unit (CPU) hardware holding the global wallet encryption keys 1210 [Takahashi 6] becomes unavailable or destroyed, in which case all data on the backups will become inaccessible.

[0109] Figure 13 illustrates emergency measures that can be taken to restore cryptocurrency wallets hosted in the trusted execution environment of the first remote server. For example, the global wallet [Takahashi 7] encryption key 1210 (which provides access to all wallets) can be split into different parts 1310 (e.g., Shamir secret sharing) and they are handed over to different key persons within the cloud service organization. A very strict procedure may govern the circumstances 1320 in which these key parts can be combined to instantiate a new enclave 1330 with the reconstructed key. This reconstructed enclave can make the data on the backup accessible again and instantiate other enclaves and populate them with the global encryption key.

[0110] The proposed Guard Wallet concept offers ease of setup, resistance to human error (and therefore loss of assets), the possibility to set usage controls (daily limits, confirmation of large transactions), decentralized setup, reduced security risks (in terms of sensitivity to vulnerabilities and large scale attacks) and support for different types of assets, at the expense of anonymity.

[0111] In general, the proposed concept may be complex to utilize effectively, especially with regard to software updates for secure enclaves. This may be ensured by configuring the secure enclave (i.e., the software running within the secure enclave) to accept software when the enclave is signed by an auditor. This enhances the security of the proposed concept, while also slowing down the procedure in cases where a quick patch (e.g., for a vulnerability) is required.

[0112] To avoid identity failures (e.g. if an (government) agency accidentally gives their identity to someone else), a combination of authentication methods MAY be used (depending on the amount of money stored in the wallet). To prevent the enclave from being damaged or the keys from being lost, banking level security procedures MAY be used. To avoid vulnerabilities in the code running within the enclave, the enclave may be operated at a minimal size and the enclave code may be subject to very intensive security checks.

[0113] Further details and aspects of the Guard Wallet concept are set forth in relation to the proposed concept or one or more of the embodiments described above or below (e.g., Figures 1a-1c). The Guard Wallet concept may include one or more optional additional features corresponding to one or more aspects of the proposed concept or one or more of the embodiments described above or below.

[0114] Examples of the proposed concept relate to the following configurations: (1) A wallet management device (110) comprising a processing circuit (114), The processing circuit includes: generating a first cryptographic secret; obtaining a second cryptographic secret from a second remote server (130) when the owner of the cryptocurrency wallet is authenticated to said second remote server; signing a control instruction to register the first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret; Sending the signed control instructions to a first remote server (120) for registering the first cryptographic secret in the cryptocurrency wallet. By doing so, registering a new first cryptographic secret with the cryptocurrency wallet hosted in a trusted execution environment on the first remote server; issuing cryptographically protected instructions based on the first cryptographic secret to the first remote server for controlling the cryptocurrency wallet; It is configured as follows: Wallet management device. (2) A wallet management device according to (1), The processing circuitry is configured to register a new first cryptographic secret after a previously used first cryptographic secret is lost. Wallet management device. (3) A wallet management device according to (1) or (2), the first cryptographic secret being a private key of a device authorization key pair; The processing circuitry is configured to derive a public key of the device authorization key pair from a private key of the device authorization key pair and include the public key of the device authorization key pair in the control instructions for registering the first cryptographic secret. Wallet management device. (4) A wallet management device according to any one of (1) to (3), The second cryptographic secret is a private key of a device registration key pair, and a public key of the device registration key pair is known to the cryptocurrency wallet. Wallet management device. (5) A wallet management device according to (4), the processing circuitry is configured to obtain a response from the first remote server in response to the signed control instructions for registering the first cryptographic secret in the cryptocurrency wallet; The response includes a confirmation of the cryptocurrency wallet if the private key of the device registration key pair matches the public key of the device registration key pair stored in the cryptocurrency wallet. Wallet management device. (6) A wallet management device according to any one of (1) to (5), The control instructions for registering the first cryptographic secret to the cryptocurrency wallet include first instructions for deleting a previously used first cryptographic secret from the cryptocurrency wallet and second instructions for registering a new first cryptographic secret to the cryptocurrency wallet. Wallet management device. (7) A wallet management device according to any one of (1) to (6), The processing circuit is configured to authenticate an owner of the cryptocurrency wallet to the second remote server by providing a signed identity certificate to the second remote server and obtain a second cryptographic secret in response to the authentication, the signed identity certificate being signed by an independent entity. Wallet management device. (8) A wallet management device according to (7), The processing circuitry of the wallet management device is configured to authenticate the owner of the cryptocurrency wallet to the second remote server by signing an instruction with a private key linked to the identity certificate, thereby enabling verification of the signed instruction using the signed identity certificate. Wallet management device. (9) A wallet management device according to (7) or (8), The processing circuitry is configured to obtain the signed identification from the independent entity. Wallet management device. (10) A wallet management device according to any one of (7) to (9), The processing circuitry is configured to include the signed identity certificate along with a subset of instructions for controlling the cryptocurrency wallet. Wallet management device. (11) A wallet management device according to any one of (1) to (6), Authentication of the cryptocurrency wallet owner to the second remote server occurs external to the wallet management device. Wallet management device. (12) The wallet management device according to any one of (1) to (11) is provided. Mobile devices. (13) A system comprising a wallet management device (110) according to any one of (1) to (11) and the second remote server (130), The second remote server is a storage circuit (136) configured to store a second cryptographic secret; and a processing circuit (134) configured to provide the second cryptographic secret in response to authenticating an owner of a cryptocurrency wallet to the second remote server. system. (14) The system according to (13), The processing circuitry of the second remote server is configured to authenticate the owner to the second remote server based on the owner's signed identity and information about the identity of the owner of the cryptocurrency wallet stored at the second remote server, the signed identity being signed by an independent entity. system. (15) The system according to (14), The processing circuitry of the second remote server is configured to obtain the signed identity certificate from the wallet management device. system. (16) The system according to (14), The processing circuitry of the second remote server is configured to obtain the signed identity certificate from an entity other than the wallet management device. system. (17) A system according to any one of (14) to (16), the signature of the signed identity document is derived from a trust anchor; The processing circuitry of the second remote server is configured to verify the signed identity based on the public key of the trust anchor. system. (18) A system according to any one of (13) to (17), two or more second remote servers; The processing circuitry of the wallet management device is configured to obtain the second cryptographic secret from the two or more second remote servers. system. (19) The system according to (18), The processing circuitry of the wallet management device is configured to select one of the two or more second remote servers and obtain the second cryptographic secret from the selected second remote server. system. (20) The system according to (18), The processing circuitry of the wallet management device is configured to obtain two or more portions of the second cryptographic secret from the two or more second remote servers and combine the two or more portions to obtain the second cryptographic secret. system. (twenty one) A system according to any one of (13) to (20), The first remote server (120) is further included. The first remote server is a processing circuit (124) configured to provide a trusted execution environment and to perform operations related to the cryptocurrency wallet within the trusted execution environment; system. (twenty two) The system according to (21), the first cryptographic secret being a private key of a device authorization key pair; the control instructions for registering the first cryptographic secret include a public key of the device authorization key pair; The processing circuitry of the first remote server is configured to store the public key of the device authorization key pair in a cryptocurrency wallet of a trusted execution environment. system. (twenty three) The system according to (21) or (22), the second cryptographic secret being a private key of a device registration key pair; Processing circuitry of the first remote server is configured to store a public key of a device registration key pair in the cryptocurrency wallet in the trusted execution environment and verify the signed control instructions for registering the first cryptographic secret based on the public key of the device registration key pair. system. (twenty four) A system according to any one of (21) to (23), The processing circuitry of the first remote server is configured to store a third cryptographic secret for signing transactions on a cryptocurrency blockchain in a cryptocurrency wallet in the trusted execution environment and to sign transactions on the cryptocurrency blockchain using the third cryptographic secret. system. (twenty five) A system according to any one of (21) to (24), The processing circuitry of the first remote server is configured to store a public key of a trust anchor and to store information regarding an identity of an owner of the cryptocurrency wallet in a wallet in the trusted execution environment. system. (26) The system according to (25), the subset of instructions for controlling the cryptocurrency wallet is required to include a signed identification of an owner of the cryptocurrency wallet; The signature of the signed identity document is derived from a trust anchor; Processing circuitry of the first remote server is configured to verify the subset of instructions based on information in the signed identification document, information regarding an identity of an owner of the cryptocurrency wallet, and a public key of the trust anchor. system. (27) The system according to (25) or (26), the second remote server is configured to provide to the first remote server confirmation information relating to a second cryptographic secret stored by the second remote server; The verification information includes information regarding the identity of the owner of the cryptocurrency wallet. system. (28) A system according to any one of (21) to (27), The software code that runs in the trusted execution environment is audited by a third party. system. (29) generating a first cryptographic secret (12); obtaining (14) a second cryptographic secret from the second remote server when the cryptocurrency wallet owner is authenticated to the second remote server; Signing (16) a control instruction for registering a first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret; Sending the signed control instructions to a first remote server for registering the first cryptographic secret in the cryptocurrency wallet (18). By doing so, Registering (10) a new first cryptographic secret in a cryptocurrency wallet hosted in a trusted execution environment on the first remote server; issuing cryptographically protected instructions based on the first cryptographic secret to the first remote server for controlling the cryptocurrency wallet (20); How to manage your wallet. (30) A program code for performing the method according to (29) when executed on a computer, processor or programmable hardware component. Computer program.

[0115] Aspects and features described in connection with a particular one of the preceding embodiments may be combined with one or more further embodiments, either to replace the same or similar features in the further embodiments or to introduce additional features to the further embodiments.

[0116] The embodiments may further be or relate to a (computer) program having a program code for performing one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, different method steps, operations or processes of the above methods may also be performed by a programmed computer, processor or other programmable hardware component. The embodiments are also directed to a program storage device, such as a digital data storage medium, that is machine, processor or computer readable and that encodes and / or stores machine-executable, processor-executable or computer-executable programs and instructions. The program storage device may include or be, for example, a digital storage device, a magnetic storage medium such as a magnetic disk or magnetic tape, a hard disk drive, or an optically readable digital data storage medium. Other examples include computers, processors, control units, (F)PLAs ((field) programmable logic arrays), (F)PGAs ((field) programmable gate arrays), GPUs (graphics processor units), ASICs (application-specific integrated circuits), ICs (integrated circuits) or SoCs (system-on-a-chip) systems programmed to perform the steps of the methods described above.

[0117] Furthermore, it should be understood that the disclosure of multiple steps, processes, operations or functions disclosed in the present embodiments or claims should not be construed as necessarily relying on the order in which these operations are described, unless expressly stated in individual instances or required for technical reasons. Thus, the above description does not limit the execution of some steps or functions to a specific order. Also, in further embodiments, a single step, function, process or operation may include and / or be divided into several sub-steps, sub-functions, sub-processes or sub-operations.

[0118] Where some aspects are described in relation to an apparatus or system, these aspects should also be understood as a description of a corresponding method. For example, a block, device or functional aspect of an apparatus or system may correspond to a feature, such as a method step, of a corresponding method. Thus, aspects described in relation to a method should also be understood as a description of a property or functional feature of a corresponding block, corresponding element, corresponding device or corresponding system.

[0119] The following claims are incorporated into the detailed description of this specification, with each claim standing on its own as a separate embodiment. It should be noted that in the claims, a dependent claim is a specific combination with one or more other claims, but other embodiments may also include combinations of the dependent claim with the subject matter of other dependent or independent claims. Such combinations are expressly suggested herein, unless it is stated in individual cases that a specific combination is not intended. Moreover, the features of a claim should also be included in any other independent claim, even if that claim is not directly defined as being dependent on that other independent claim.

Claims

1. A wallet management device (110) comprising a processing circuit (114), The processing circuitry includes: generating a first cryptographic secret; obtaining a second cryptographic secret from a second remote server (130) when the owner of the cryptocurrency wallet is authenticated to said second remote server; signing control instructions for registering the first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret; Sending the signed control instructions to a first remote server (120) for registering the first cryptographic secret in the cryptocurrency wallet. By doing so, registering a new first cryptographic secret with the cryptocurrency wallet hosted in a trusted execution environment on the first remote server; issuing cryptographically protected instructions based on the first cryptographic secret to the first remote server for controlling the cryptocurrency wallet. It is configured as follows: Wallet management device.

2. 2. The wallet management device according to claim 1, The processing circuitry is configured to register a new first cryptographic secret after a previously used first cryptographic secret is lost. Wallet management device.

3. 2. The wallet management device according to claim 1, the first cryptographic secret being a private key of a device authorization key pair; The processing circuitry is configured to derive a public key of the device authorization key pair from a private key of the device authorization key pair and include the public key of the device authorization key pair in the control instructions for registering the first cryptographic secret. Wallet management device.

4. 2. The wallet management device according to claim 1, The second cryptographic secret is a private key of a device registration key pair, the public key of which is known to the cryptocurrency wallet. Wallet management device.

5. 2. The wallet management device according to claim 1, The control instructions for registering the first cryptographic secret with the cryptocurrency wallet include first instructions for deleting a previously used first cryptographic secret from the cryptocurrency wallet and second instructions for registering a new first cryptographic secret with the cryptocurrency wallet. Wallet management device.

6. 2. The wallet management device according to claim 1, The processing circuitry is configured to authenticate an owner of the cryptocurrency wallet to the second remote server by providing a signed identity certificate to the second remote server and obtain a second cryptographic secret in response to the authentication, the signed identity certificate being signed by an independent entity. Wallet management device.

7. 7. The wallet management device according to claim 6, The processing circuitry is configured to authenticate the owner of the cryptocurrency wallet to the second remote server by signing an instruction with a private key linked to the identity certificate, thereby enabling verification of the signed instruction using the signed identity certificate. Wallet management device.

8. 7. The wallet management device according to claim 6, The processing circuitry is configured to obtain the signed identification from the independent entity. Wallet management device.

9. 7. The wallet management device according to claim 6, The processing circuitry is configured to include the signed identity certificate along with a subset of instructions for controlling the cryptocurrency wallet. Wallet management device.

10. A system comprising the wallet management device (110) of claim 1 and the second remote server (130), The second remote server comprises: a memory circuit (136) configured to store a second cryptographic secret; and a processing circuit (134) configured to provide the second cryptographic secret in response to authenticating an owner of a cryptocurrency wallet to the second remote server. system.

11. 11. The system of claim 10, The processing circuitry of the second remote server is configured to authenticate the owner to the second remote server based on the owner's signed identity and information about the identity of the owner of the cryptocurrency wallet stored at the second remote server, the owner's signed identity being signed by an independent entity. system.

12. 12. The system of claim 11, a signature of the signed identity certificate is derived from a trust anchor; Processing circuitry of the second remote server is configured to verify the signed identity certificate based on a public key of the trust anchor. system.

13. 11. The system of claim 10, two or more second remote servers; The processing circuitry of the wallet management device is configured to obtain the second cryptographic secret from the two or more second remote servers. system.

14. 11. The system of claim 10, The first remote server (120), The first remote server comprises: a processing circuit (124) configured to provide a trusted execution environment and to perform operations related to the cryptocurrency wallet within the trusted execution environment; system.

15. 15. The system of claim 14, the second cryptographic secret being a private key of a device registration key pair; Processing circuitry of the first remote server is configured to store a public key of a device registration key pair in the cryptocurrency wallet in the trusted execution environment and to verify the signed control instructions for registering the first cryptographic secret based on the public key of the device registration key pair. system.

16. 15. The system of claim 14, The processing circuitry of the first remote server is configured to store a public key of a trust anchor and to store information regarding an identity of an owner of the cryptocurrency wallet in a wallet in the trusted execution environment. system.

17. 17. The system of claim 16, the subset of instructions for controlling the cryptocurrency wallet is required to include a signed identification of an owner of the cryptocurrency wallet; a signature of the signed identity certificate is derived from a trust anchor; Processing circuitry of the first remote server is configured to verify the subset of instructions based on information in the signed identification certificate, information regarding an identity of an owner of the cryptocurrency wallet, and a public key of the trust anchor. system.

18. 15. The system of claim 14, the second remote server is configured to provide to the first remote server confirmation information regarding a second cryptographic secret stored by the second remote server; The verification information includes information regarding the identity of the owner of the cryptocurrency wallet. system.

19. generating (12) a first cryptographic secret; obtaining (14) a second cryptographic secret from a second remote server when the owner of the cryptocurrency wallet is authenticated to said second remote server; signing (16) control instructions for registering a first cryptographic secret in the cryptocurrency wallet using the second cryptographic secret; Sending the signed control instructions to a first remote server for registering the first cryptographic secret in the cryptocurrency wallet (18). By doing so, Registering (10) a new first cryptographic secret with a cryptocurrency wallet hosted in a trusted execution environment on the first remote server; issuing cryptographically protected instructions based on the first cryptographic secret to the first remote server for controlling the cryptocurrency wallet (20); How to manage your wallet.

20. 20. A method for carrying out the method of claim 19, comprising: Computer program.

Images