Security Aspects of Cryptocurrency Wallets—A Systematic Literature Review

Attacker Model 1—physical access: Attacks on the memory level usually focus on extracting data used in a subsequent attack performed on a different level. The data obtained by a RAM analysis can include the wallet’s private keys, seeds, PIN codes, and the transaction history [45, 90]. In case of web application, Zollner et al. [100] showed that it is possible to extract the URLs of all used wallets and artifacts such as the mnemonic passphrase and the wallet ID.

Koerhuis et al. [60] conducted an artifact analysis of two privacy-oriented cryptocurrencies, Monero and Verge. They examine the software running on a computer used to execute transactions. They performed a memory and disk analysis. It was possible to extract the wallet passphrase, the entire transaction history, and the public and stealthy addresses for Monero and Verge.

Attacker Model 2—theoretical attacks: Praitheeshan et al. [75] performed two attacks focusing on the keystore file of Ethereum wallets. This specific file stores the account credentials of the wallets. A key that is at least eight characters long protects this file. If attackers can crack this key (password), then they gain full control of the wallet and thus the Ethereum address. The keystore file was created in the experimental setup, and various eight character long passwords were generated. First, they performed a brute-force attack using Hashcat [3]. Hashcat could not crack one of the passwords in the predefined time limit of one hour. The estimated time was ten years. Using the mask option made it possible to crack passwords consisting of a sequence of numbers. The mask option can only be used when more detailed information about the password is available, e.g., only numbers were used. The second attack run against the generated test files was a dictionary attack using the rockyou [8] dictionary and Hashcat. Hashcat was able to crack “weak passwords with single characters, continues digits or letters, combination of simple digits and letters and common words” [75] in less than an hour.

Not only implementation and structure misconfigurations lead to incorrect key storage but also the unfamiliarity of the users. Often they do not know what function the private key has or that it exists at all. The information provided by the wallets in this regard is inadequate or non-existent, leading to incorrect use on the user side [36].

Attacker Model 3—unlimited login attempts: With the increase of users of Blockchain technology, more people have to handle their private keys. Brain wallets were introduced to simplify the storage of keys. Brain wallets are Blockchain wallets derived from a user-given or randomly generated passphrase, mainly containing 12 or 24 words. This method replaces the need to have a physical device for storing the key on it and makes it impossible for attackers to steal it, since it is not permanently saved (except in the user’s memory). Nevertheless, offering access to it via a passphrase exposes a weakness, because an attacker can guess the password without any restrictions, and if guessed right, then the attacker has complete control over the wallet. The study of Vasek et al. [94] revealed that most brain wallets were drained within 24 hours or less.

Attacker Model 1—USB debugging: The attacker can perform an artifact analysis, e.g., scan the mobile device’s memory and search for sensitive information [63]. He et al. [46] showed that extracting the PIN code from the Huobi Wallet [4] and the imToken [6] application is possible.

Moreover, Haigh et al. [45] analyzed eight different Android applications installed on a rooted device. They acquired sensitive data during an artifact analysis using Android Debugging Bridge (adb). Volety et al. [95] performed a brute-force attack based on data found during memory scans that were possible after gaining access due to the debugging mode. Angelica Montanez [69] performed an artifact analysis of wallet applications installed on Android and iOS devices. It was possible to extract information regarding the active presence of a wallet app for both operating systems; gaining data about a past application was only possible for Android apps. For the Android device, the adb pull command was particularly successful in extracting valuable data of installed and active applications as well as past ones.

Uddin et al. [90] performed an extensive analysis of 311 Android wallet applications, revealing that 111 apps store key-related information in plain. Moreover, only 20 apps implement their own keyboard, which can prevent the prediction of the mnemonic passphrase by using the user dictionary, which stores the words typed into the default keyboard. Only 70 apps check whether the device they are running on is root. A rooted device can lead to security risks as monitoring activities or sending sensitive information to an external server in the presence of an installed malicious application, which is also interesting for the second attacker model.

Attacker Model 2—malicious application installed: A vulnerability that is generally Android specific, but can be used as an attack against crypto wallets, exploits the so-called Accessibility Mode in Android. The permission BIND_ACCESSIBILITY_SERVICE can be requested by any application and enables, if set to true (=1), the Android accessibility features [62, 63]. Those features allow applications to access all GUI events, including all displayed information on the screen [62] except the password textbox, since this one is protected by default [63]. Leguesse et al. [62] even announced that it would be possible to “potentially backdooring Android’s security model” [62]. An attacker can use this vulnerability by first uploading a benign application to the PlayStore with permission to use the accessibility mode. The BIND_ACCESSIBILITY_SERVICE permission is not classified as suspicious or dangerous by Google [62]. Second, when opened, the installed application needs to trick the user into enabling the setting to allow installation from third-party sources. This can be achieved by creating an overlay so that users do not realize which button they click. After that, the malicious application needs to create another overlay tricking the user into downloading an additional malicious app via a hidden link from some third-party holding permissions marked as malicious by the PlayStore [63]. Moreover, Li et al. [63] explain how an application with enabled accessibility features could capture sensitive information when combined with a third-party keyboard. The password text field cannot be observed easily, but the attacker could listen to the click events triggered by the third-party keyboard.

Once the malicious application is installed on the victim’s device, the attacker has even more options than those mentioned above. Android divides its storage into external and internal storage, mainly differentiated by their security levels [63]. Each app has its internal storage in which it stores all its app-specific data. Only the app itself or root can access it. The permission to access the external storage containing photos, documents, videos, downloads, and so on, can be requested by any application during runtime. To force the user to grant this permission, the app could show a pop-up window that needs to be accepted to use the application. Another option would be to mimic an older Android version, since no runtime request is required for those. Backup files are usually stored in a local file or external cloud. Assuming the first in combination with access permission to the external storage, an attacker’s app could read the backup file, if not encrypted, and thus gain access to sensitive information such as transaction ids. Regularly, the field android:allowBackup is set to false in the Manifest.xml by default [63, 90].

When an application is holding the SYSTEM_ALERT_WINDOW permission, it can automatically draw any floating window and thus tamper the user interface by, e.g., capturing the password or manipulating the entered transaction credentials [63]. Another way to change the transaction data is to modify the clipboard, especially the receiver’s address, since it is often too long and complicated to memorize. Hence, users copy it to the clipboard and then paste it into the wallet app. And precisely between these two actions, the attacker can intervene and replace the copied address with their own or any other arbitrary address without the victim’s notice. This weakness is independent of the application and even the used operating system [58, 63]. Moreover, Ulqinaku et al. [91] presented an attack exploiting the scan-and-pay mechanism by creating an overlay containing a fake QR code.

Attacker Model 1—physical access or access to specific file: Cryptocurrency wallets leave artifacts on the device, even after removing the wallet [100]. It is possible to find artifacts in the browser history, temporary storage, and cookies. Some cryptocurrency wallets save their credentials in an inappropriate file format, meaning in a non-encrypted form. Keeping the private keys in an unencrypted format can lead to theft of the wallet’s complete content. Saving the transactions in plaintext can be a privacy issue, since it can connect an address to a person [45]. The same applies to contact lists that are saved in plaintext [92]. Some users are sharing debugging logs of the wallets on publicly available platforms (e.g., Pastebin). Some of those logs contain sensitive information like the private keys or information that enables to infer the private key [26]. Other wallets showed deficiencies by using a hardcoded encryption key or other sensitive information [45, 83].

The key generation process is one of the most critical steps in using cryptocurrency and needs to be done securely to protect the user from loss or theft. The nonce plays an essential role in the creation process and needs to be kept secret, and in practice, it is unlikely that the same nonce is picked more than once, since the possible set of nonces is roughly about \(2^{256}\) possibilities [26]. Nevertheless, the reuse of nonce already occurred within the Bitcoin Blockchain, and it is most likely that it happened due to a weak random number generator, a bad implementation of a wallet, or a reset of a virtual machine and thus to reset to the same seed [26, 59].

Attacker Model 2—user and server impersonation: Many desktop cryptocurrency wallet applications use open remote procedure calls to extend the wallet’s functionality with other Blockchain-based applications, e.g., web-browser extensions [27]. By offering this Remote Procedure Call (RPC) interface, it is possible to impersonate the wallet owner in some cases without the need for a password. By impersonating the wallet owner, it is possible to start a transaction to an address owned by a malicious actor. Some other wallets enable the function to use basic access authentication, but Bui et al. [27] found a way to get access to the wallet by impersonating the server first. They started a server on the same port as the regular server and prevented it from starting. After the user sends its credentials to the malicious server, it shuts down and waits until the regular server restarts. After the restart, an impersonation as the wallet owner can be achieved. There are cryptocurrency wallet applications that use digest access authentication. Bui et al. [27] managed to impersonate the server in the same way as in the previous example. The attacker can capture all the commands sent to the server, especially the wallet generation process, and thus can own a copy of the new keys. The difference from the previous example is that they consider the client impersonation as not practical, because they do not receive the credentials in plaintext but as an MD5 hash that has to be cracked before.

Attacker Model 3—vulnerable libraries: Another potential source of danger is the faulty use of libraries. Tschannen et al. [89] analyzed the usability of the library libbitcoin “well-known C++ implementation of the bitcoin system.” The inappropriate use of it can lead to bugs and security vulnerabilities, including zero-day attacks. Their evaluation of libbitcoin showed that, e.g., misleading documentation and function names lead to the wrong usage in source code of applications and thus to security issues. Hu et al. [50] presented a vulnerability of the BitcoinJ client library, which is used for communicating with the Simple Payment Verification (SPV) client. Wallets as Bitcoin Wallet and Mycelium utilize this library. The SPV client establishes a connection to a Full Node Client (FNC) via TCP. However, if this connection is torn down, then the SPV client will automatically establish a new connection to an available FNC, which can be interfered with by a malicious third party. Thus, the attacker can extract the wallet’s Bitcoin address. Moreover, the transactions are downloaded in the background without the user’s knowledge. Therefore, if a man-in-the-middle attack occurs, then the attacker can add or change transactions. Furthermore, Hu et al. found that some Bitcoin wallets, e.g., Bitcoin Wallet and Coinbase, violate the decentralization property of the network as they do not allow the wallet to join the network directly but through the wallet’s provider’s server.

Attacker Model 4—sending fake transactions: Other implementation mistakes can lead to Bait and Switch vulnerabilities allowing users to steal coins after the faulty new source code was pushed. An attack called Fabricated Transaction means that fake transactions are sent to users. Kaushal et al. [55] analyzed multiple wallet applications and found that only one is secure against the attacks mentioned earlier, the Bitcoin Core wallet.

Attacker Model 1—passive access to network: It is possible to deanonymize users using different techniques. One of those techniques is called clustering. Biryukov and Tikhomirov [22, 23] deployed this technique, and by analyzing wallet applications and their underlying protocols, they deanonymized users. In addition to their clustering, they also tried to estimate the issuing user’s IP, giving insightful information for an attacker. Their approach analyzed the propagation time between each of the nodes. They successfully clustered smaller networks such as the Bitcoin test network and Zcash but had problems with more extensive networks (e.g., Bitcoin mainnet), because clustering these networks requires significantly more computing power, and their computing resources were insufficient for this.

Additionally, Teomete et al. [88] and Bergman et al. [20] provided overviews of deanonymization methods for Bitcoin that can be utilized by law enforcement. Teomete et al. listed three techniques based on clustering. The first approach, developed by Reid et al. [80], takes advantage of the Blockchain’s property that when Bitcoins are transferred, the link between the sender and the receiver is publicly accessible through blocks in the Blockchain. A transaction graph can be created between the various identities based on these links, even if different addresses are generated for each transaction. The identities in the created network can be grouped into the same entities. It is possible to identify the most commonly used transactions using these groups, and if an identity is revealed in between, then any Bitcoin address associated with that identity can be tracked using financial and customer transaction histories. The second method, summarized by Teomete et al. and developed by Meiklejohn et al. [68], assumes that when Bitcoins from two different addresses are combined, those bitcoins, and therefore the addresses, belong to the same user. The last technique utilizes website analytic cookies to locate Bitcoins transactions by cross-matching information and data on the Blockchain [42]. Some clustering methods with published heuristics were tested by Neudecker et al. [72]. They showed that only a small share of clusters could be assigned to a single IP address. However, adjusted heuristics and a preciser network observation could improve the results. Biryukov et al. [21] introduced a new method to deanonymize clients in the Bitcoin network based on the entry nodes and the established outgoing connections. Androulaki et al. [13] conducted a study mimicking Bitcoin as the primary payment method used at a university. Their evaluation showed that using the security features recommended by Bitcoin, the identity of 40% of the users can be revealed.

Khalilov et al. [56] performed an extensive survey regarding privacy issues in Bitcoin and similar systems. They concluded that for Bitcoin, improvement is needed. As mentioned above, many attack methods exist, most of which result from the transparency that all transactions are broadcasted in the network. They also stated that combining data extracted from the blockchain with data obtained from external sources can reveal one’s identity. In his case study, Amin Aghaee [12] showed that it is possible to identify a specific user account within a network by utilizing information gathered from social media platforms. Law enforcement can use this approach to identify the cryptocurrency accounts of suspects.

Attacker Model 2—active access to network: The third clustering approach presented by Teomete et al. (mentioned above) uses Internet Protocol addresses. Mining software needs to be injected into a network to listen to its traffic [88]. If two validators receive data from the same IP address, then it is assumed that this address belongs to the same user. Since it is possible to link IP addresses to real-life identities or locations, the user can be deanonymized [61].

Blockchain technology depends on the Internet infrastructure; otherwise, the connections between the different peers cannot be established. It is possible to interfere with the BGP to perform two types of Routing Attacks: (i) the Partitioning Attack and (ii) the Delay Attack [14, 31, 71, 96]. The Partitioning attack tries to split the Blockchain network into disjoint groups. This possibly enables applying double-spending attacks. The Delay attack creates false information to enforce the peers to resend their packages, leading to a delay in broadcasting blocks. Having a delay gives the attacker more time to find a block and thus receive the mining rewards.

Attacker Model 1—accepting unconfirmed TX: One of the malicious schemes in the Blockchain is the so-called double-spending. Double spending refers to using the same coin multiple times [30, 31, 34, 41, 53, 54, 71, 73, 74, 85, 93, 96]. Double spending can appear when a chain is forked, and each of the forks spends the same coins but sends them to different addresses. Both transactions can be valid, but one of the forks will be abandoned as soon as one of the forks achieves a longer chain than the other. Usually, it is assumed that a double-spending attack can be carried out successfully if the attacker has a higher proportion of computing power than the honest party. Jang et al. [51] showed that even an attack with less than the assumed 50% can be profitable, which means that the profit made during the attack is greater than the costs to perform the attack. The study performed by Zhang et al. [97] showed that the success probability depends on the clustering coefficient and not on the path length or the number of nodes in the network. The lower the clustering-coefficient, the higher the success probability. Different attacks fall under the category of double-spending as the Race Attack, the Finney Attack, and the Vector76 Attack. The Race attack works when a user accepts payments as soon as the TXs are sent but are not validated yet. An attacker can abuse it and create another TX, which transfers the coin to an address the attacker owns. The attacker publishes both TX in the network at the same time. This creates a race between the TXs, because both are valid, but the other becomes invalid if one gets mined in a block. If the attacker is lucky, then the TX to their address gets mined first, thus getting service without paying the merchant. The Finney attack is quite similar to the Race attack. The Finney attack has the same requirement as the Race attack; the merchant must accept the unconfirmed TX. The Finney attack requires the attacker to create two TXs and mine the malicious TX independently. The attacker releases the TX containing the transfer to the merchant to the network. The merchant checks the transaction and fulfills their part of the trade. The attacker releases the pre-mined block to the network as soon as the merchant accepts the payment, invalidating the merchant’s transfer. The Vector76 attack extends the previously mentioned attacks by the possibility to apply this attack even when a merchant waits until a transaction is validated (by one block) and included in the Blockchain. The attacker mines a merchant-paying TX independently and withholds the TX to the network until they find a valid block. When the attacker finds a block, they publish the TX as soon as a new block is found by the network, thus creating a fork in the chain. The attacker publishes a malicious transaction in the fork, not including the merchant-paying TX, and double-spends the coin. The attack is successful when the fraudulent chain becomes longer than the chain with the merchant-paying TX [31, 41, 57, 71, 96].

Liu et al. [66] describe another attack based on the Blockchain protocol, the so-called Malleability Attack. This attack targets the way TX are created in the network. Since all network participants can receive broadcasted TX, they can also alter the TX and rebroadcast them. The transactions have to be valid, so the inputs and outputs cannot be changed, but it is possible to replace operators, e.g., OP_0 with OP_PUSHDATA2, and add some operators to change its hash value. The altered and the original TX are competing now in the network, and in case the edited TX wins, the user can think that the TX failed. However, the TX was successful just with another hash value [66, 77].

Atzei et al. [16] published a survey on the attacks targeting the Ethereum network. The unpredictable state of the blockchain can lead to attacks as GovernMental and the exploitation of dynamic libraries. The problem is that it cannot be guaranteed that the contract will be in the same state when the transaction is performed as it was when the transaction was initiated.

Attacker Model 2—more than 50% of the network’s computing power: One of the most significant attacks is the 51% Attack also called Majority Attack [71, 85, 93, 96]. This attack can be applied when the attackers have more than 50% of the computing power in the Blockchain network. By owning more computing power than the rest of the network, it is possible to change the existing Blockchain (to a certain degree, depending on the implementation of the Blockchain) by creating a fork where the attackers want to change the chain. This change can then lead to a double-spending attack or a reverse of validated transactions, or both.

Attacker Model 3—DoS attack: It is possible to send vast amounts of data within the network to create DoS attacks [31, 96]. Those attacks can lead to a change in the rate of block creation, giving an advantage or a disadvantage to a group of miners. A DoS attack could also lead to double-spending.

Attacker Model 4—votes per IP address: The Sybil Attack [31, 35, 71, 85, 96] is abusing the fact that some peer-to-peer networks allow a vote per IP address and not one vote per node. This allows an attacker to create multiple identities (IP addresses) to achieve a higher number of votes within the network. When the attacker has more votes in the network, it gives the attacker the possibility to change the propagation in the network.

Attacker Model 5—blackout or downtime of ISP: The Eclipse Attack [31, 47, 71, 85, 96] tries to populate all the ingoing and outgoing connections of a node by malicious nodes. This malicious table of IP addresses enables the attacker to influence the target perspective, since all information comes from malicious nodes. This attack needs a full restart of all its connections, which appears mostly after blackouts or when an ISP goes down.

Attacker Model 1—exchange platform: Not only the security of the wallets but also the security of the exchange platforms is essential. Exchange platforms offer the exchange between money and cryptocurrencies. Since those platforms unite a massive amount of cryptocurrencies, they are targeted quite often. The exchange platform Coinbase Exchange has a volume of about $5.1 billion and is the biggest exchange provider in the U.S., offering fiat support for USD, EUR, and GBP [10].

Online wallets need a way to authenticate the user to the platform, which is often done via regular login credentials. If registration is needed to use a wallet, then the wallet provider can deanonymize the user [22], which means the platform could connect a wallet address to an explicit user.

Attacker Model 2—implementation flaws: Arapinis et al. [15] state that each transaction includes three parties, the hardware (wallet), the client (software), and the user. Each component has its weaknesses. The wallet’s security depends on the underlying cryptographic primitives, mainly the hash function and signature scheme. If one of them is broken, then it can result in a loss of coins. A broken hash function potentially results in a loss of receiving funds and a defective signature scheme in losing the spending funds. Moreover, the security heavily depends on the honesty of the client and user. Any input or output could be malicious if it compromised a client, and the security cannot be guaranteed anymore. In addition, all parties must adhere to their protocols and execute them correctly, but this could be thwarted by the user if, for example, they deviate from the intended security assumptions by using a too weak password. Furthermore, the security could be compromised by the missing usability of hash function comparison techniques.

Hierarchical deterministic wallets use a secret master-private key, or parent-private key, from which each child-private key can be generated pseudo-randomly. Accordingly, each child-public key can be generated from the master-public key or parent-public key. However, an attacker knowing the master-public key and any child-private key can recover the master-private key. Thus, the attacker could generate as many child-private keys as desired and spend the user’s coins [44]. This attack is also known as privilege escalation attack [37].

Attacker Model 3—air-gapped wallets: Davenport et al. [33] analyzed air-gapped wallet applications, which are known to be very secure due to their offline structure. Thus, it is difficult to compromise them. Davenport et al. identified two main challenges for attackers. The first one is the infiltration process that can be achieved in three different ways: (i) pre-downloaded infiltration, (ii) physical access, and (iii) remote infiltration. The infiltration consists of three steps. First, the online machine needs to be compromised, then some external media used for data transfer between the online machine and the air-gapped device, and last the air-gapped device itself. The second challenge is the exfiltration of data such as keys. This can be done by, e.g., using external media transfer or side-channel exfiltration. Since infiltration depends on an inside actor, it is harder to perform than exfiltration. Moreover, there exist more ways to exfiltrate than to infiltrate. However, both steps need to be successful for a successful attack. Guri [43] performed a similar analysis of key leakage in air-gapped wallet devices. He divided the infiltration into two categories, the post-installation infection, and the pre-installation infection. The former refers to a removable device such as a USB drive or an SD card to exchange information between offline (air-gapped) wallets and online wallets needed for a transaction. The attacker installed malicious software on the machine running the online wallet. When inserting the removable media, malware is installed on it. When the removable media is then inserted into the air-gapped device, it is also infected. The latter means installing a malicious or already infected wallet application. If the infiltration is successful, then the attacker establishes a covert channel to exfiltrate the keys. This can be accomplished using physical devices such as removable media, electromagnetic, electric, magnetic, optical, acoustic, or thermal data and signals.

Unauthorized access, e.g., cracking passwords (a-1, a-3, b-1, b-2, c-1, d-1, f-1): Brute-forcing passwords need a lot of computational power and time to be successful. This process can be even more challenging by implementing some of the following steps proposed by Khan et al. [57]. The most simple step is to use more complex passwords to increase the possibilities and thus the time needed to crack. Another attempt can be made to reduce the number of tries allowed by the user in a given time, and if exceeded, then the account can be locked, and the owner messages about the failed logins. A two-layer approach can be used to avoid this type of attack. The use of Captchas could avoid automatic login tries. In addition to that, they suggest using two or more login URLs and the modification of the ruleset of Hypertext access files. Increased awareness among users and developers could lead to the use of one or more techniques mentioned before.

Bulut et al. [28] provided a list of security objectives that developers and users should follow to secure the wallet applications. The wallet application must provide a sufficient level of authentication to prevent unauthorized access by offering two-factor authentication and ensuring that passwords are complex enough to be robust against brute-force and dictionary attacks. The communication channels and the storage of the wallets must be encrypted to avoid eavesdropping attacks and data leakage. Moreover, the receivers’ addresses need to be displayed so that the user can visually verify them. Additionally, they should provide an integrity check mechanism and the option of a secure failure mode in case of a failure.

Since no legal foundation is responsible for cryptocurrencies, users are responsible for securing their virtual money. The users can do this by using sufficient authentication mechanisms. Therefore, Lim et al. [64] analyzed Bitcoin’s security breaches to give an overview of countermeasures. Based on their findings they recommended applying at least two-factor authentication using Hardware Security Module or One-Time Password (OTP).

The research conducted by Barber et al. [18] focused on vulnerabilities in the Bitcoin system and proposed solutions to the findings. The loss of Bitcoins can have several causes. It can result from malware attacks, which can be prevented by using standard threshold cryptography techniques. These techniques randomly split the private key and store the pieces in different locations. As another countermeasure, they introduced the principle of super wallets. These also use threshold cryptography techniques to divide the assets among multiple devices. The second reason for losing Bitcoins could be an accident or theft. They listed different solutions to this problem. The first is the simplest: using backups. If no backup is desired, then one can use pseudo-random keys. This means having a random secret master key from which private keys can be generated. To counteract wallet theft, encryption is a suitable solution. However, this countermeasure runs the risk of forgetting the decryption password, as it must be sufficiently complex.

Jasem et al. [52] introduced a new wallet consisting of a hot and cold wallet to countermeasure dictionary attacks and deanonymization. They modified the key generation algorithm by increasing the key space. Moreover, new keys are generated for each transaction, which decreases the risk of deanonymization.

The master seed is used to generate the private keys of a wallet. Jasim et al. [38] enhanced the security of the master seed of Brain wallets by adding entropy to it. They achieved this by including non-fixed ASCII encoded characters, which drastically decreases the success rate of dictionary attacks as the increased entropy leads to the need of “building huge rainbow tables which are both space and time consuming process” [38].

Hu et al. [49] introduced a new approach to verifying the user’s identity continuously in real-time using the user’s mouse behavior biometrics in combination with a CNN network. Upon the first use of the wallet, the user’s mouse behavior is monitored and passed on to the CNN model to generate a profile. In all subsequent logins the movements are measured and compared to the initial ones to verify the user’s identity. The BioWallet [19] is another approach using biometric verification to increase the security of Bitcoin wallets. The wallet applies a two-step authentication process. In the initialization phase, the users have to scan their fingerprints and set a username and password. After that, the process starts with requesting the users for their fingerprint, which is then compared with the saved one for each transaction. If the fingerprints match, then the users are forwarded to the next step, entering their username and password. If those are correct, then the transaction will be performed. The users have three attempts to enter their fingerprint and password correctly. Otherwise, the process is aborted.

Zhu et al. [99] designed a new online wallet, called HA-eWallet. Usually, the private key of an online wallet is stored on the providers’ server. If the server gets compromised, then all assets can be lost. The HA-eWallet prevents this by using three private keys out of five available keys to sign a transaction. Two encrypted keys are stored on the server in two different internal locations, and the other three keys are stored in the user node. So even if the server is compromised and an attacker obtains the keys stored on the server, it is not possible to perform a transaction.

No direct (physical) access to wallet (b-2, c-1, c-3): The security of wallet applications can be improved by performing a more sophisticated security analysis before making it available to users. Takahashi et al. [87] developed a multi-layered approach consisting of a combination of three different methods. First, a static analysis is performed to find vulnerabilities in the app’s source code. Second, the app is run in a sandbox environment to assess the runtime behavior, called dynamic analysis. The last method is a semantic analysis to evaluate the app’s general behavior and decide whether it is a benign or malicious application.

It is possible to impersonate an RPC Server and, in some cases, even the client. Bui et al. [27] provided different ways to avoid these impersonations. One suggested solution is to avoid other users using the device containing the cryptocurrency wallet. Another improvement can be made by using RPC via TLS and by actively notifying the user when there is an issue starting the RPC server. Another approach is to change the architecture of the wallet from RPC to inter-process communication.

It is possible to prevent clickjacking by enabling Android’s touch filter mechanism. However, this countermeasure is not applicable for scan-and-pay attacks presented by Ulqinaku et al. [91], since no click event is triggered. One possible way to prevent it would be to modify Android’s OS system level by restricting views generated by a background service to a specific style to be easily recognizable for users. This measurement would require training the users to identify those styles and thus the malicious overlays. Another method would be to use sensitive views. The developers must implement these, who must mark the area where the QR code is displayed as sensitive. The operating system then automatically prevents any other application from creating an overlay at this point.

Dai et al. [32], Rezaeighaleh et al. [82], and Gentilal et al. [40] propose to divide the wallet applications into several individual sections, although their implementation of this idea differs. Dai et al. utilize the Trusted Execution Environment or, in their case, the Secure Execution Environment (SEE) based on the TrustZone scheme. The wallet is split into two layers, an outer and an inner one, as shown in Figure 4. The inner one stores all sensitive information, such as the private and public keys, and performs the key generation process. This layer is the SEE and prevents the data from being stolen or tampered with. Only the block headers are stored in a local database located in the outer layer (Not secure Execution Environment). The operating system switches to safe mode for every transaction [32]. Gentilal et al.’s implementation is quite similar to the one mentioned above. It is also based on the TrustZone scheme. They are modifying an existing hardware wallet by moving its whole storage into the trusted zone. However, this causes a massive overhead for each writing or reading operation, since the whole storage needs to be decrypted before. Therefore, they deployed the write-cache, which uses intermediate storage. Gentilal et al. moved the most critical wallet functions into the secure world to fully protect the private key from being stolen. These include all operations dealing with sensitive data, the key generation, and the signing process. Moreover, the random number generator is also used in the secure world. Due to these modifications, attackers can no longer manipulate sensitive data and the wallet’s code [40].

Rezaeighaleh et al. developed a three-layered model, illustrated in Figure 5, to enhance the security of wallet applications. The first layer, the offline layer, functions as a backup wallet for the second layer, containing the protected or superior wallet. This is the central component, since it is responsible for generating and storing the master seed and the keys. If the user wants to spend some coins, then the wallet automatically switches to the third layer, the online layer. It receives a subordinated seed from the superior wallet and only holds a limited fund so that in the event of an attack, only this limited amount of coins gets lost. Two additional security layers are implemented by splitting the wallet into those three levels, since the backups are offline and cannot be accessed. The online component is not holding the master seed and the keys and only a limited amount of coins.

Furthermore, Rezaeighaleh et al. [81] recommended creating more than one backup wallet. They designed a new wallet application consisting of two wallets, the main wallet and the backup wallet. The backup wallet generates a key pair (pk, sk), computes the public key’s verification code, and exports the pk. After that, the main wallet receives pk and calculates the verification code to compare both verification codes. If matching, then the main wallet generates the key pair and computes the transport key to encrypt the master seed. The backup wallet imports the encrypted master seed and pk. It computes the transport key itself and thus can decrypt the master seed.

Homoliak et al. [48] proposed a similar approach for Ethereum-based wallets. They combined three components to create a safer and more user-friendly system to prevent ether loss due to attacks. The first component is an air-gapped authenticator that is used to verify the transaction using OTPs for each one. The second component is the client, which is used for user interaction and to trigger a transaction. The last one is the smart contract, which, when verified, executes the transactions.

Hu et al. [50] developed an additional mobile application (Bitcoin Security Rectifier) addressing the vulnerabilities introduced by the Bitcoin client library BitcoinJ. The app fixes the weaknesses without changing Bitcoin’s protocol or the wallet applications themselves. The Bitcoin Security Rectifier examines all ingoing and outgoing Bitcoin messages and applies additional filtering rules to prevent arbitrary transactions.

Gutoski et al. [44] introduced a new HD wallet countering the recovery problem of the master-private key for known master-public key and child-private key. They propose to use m master-private keys for the generation of child-private keys. Therefore, to recover the master-private keys, the attacker requires m child-private keys, which makes breaking the wallet “at least as hard as the so-called ‘one more’ discrete logarithm problem.” Fan et al. [37] focused on solving the same vulnerability. They proposed to use the trapdoor hash of a child-private key for singing instead of the child-private key itself. Even if the parent-public key and any trapdoor hashed child-private key is known to an attacker, it is not possible to recover the parent-private key.

Accepting unconfirmed TX (e-1): Another way of securing the use of wallet applications was introduced by Bamert et al. [17]. The so-called BlueWallet is a hardware token for authorization of Bitcoin transactions. It can be used to combine the user’s smartphone or computer running a wallet application to sign the transactions securely. The BlueWallet is connected to the device running the wallet via Bluetooth Low Energy. The unsigned TX is transmitted to the BlueWallet and verified there. If the TX was accepted, then the user must enter a preset password to trigger the signing action. The signed TX is then transmitted back to the device.

Malleability Attack (e-1): Rajput et al. [78] invented a modification to the Bitcoin system to prevent Malleability attacks. They appended the hash of the intermediate raw transaction to the transaction id, resulting in \(hash_{prev}\mid hash_{new}\) . If an attacker now changes \(hash_{prev}\) to perform a Malleability attack, as the one known from Mt.Gox, then the transaction will be performed normally but the sender can know verify that the transaction arrived at the receiver searching for the appended \(hash_{new}\) of the transaction id. If the attacker modifies the \(hash_{new}\) part, then the transaction will be discarded by the miners.

Passive and active access to network (d-1, d-2): Venkatakrishnan et al. [24] created a new networking policy, called Dandelion, to prevent deanonymization in the Bitcoin network by redesigning it. The network is protected against adversaries using botnets “by mixing messages from different users on a graph that is unknown to the adversary.” Thus, it is nearly impossible for an adversary to reveal an user’s identity.

Bergman et al. [20] presented three wallet applications that focus on anonymization. The first one is the Darkwallet [2], which uses a stealthy address instead of the usually used hashed address. This means that a new public key is generated for each transaction based on a fixed, known public key. The second wallet is the Wasabi Wallet [11], which utilizes the Chaumian CJ transactions, which uses blind signatures. This means a third-party tumbler validates the transactions so that never the receiver and the sender are known at the same time. The last wallet presented is the Samourai Wallet [9]. It generates a new address for each outside transaction and sends the payments through multiple dummy addresses to conceal the user’s address.

Rai et al. [76] introduced a new wallet application primarily designed for Linux systems, which uses different receiving addresses for each transaction to improve the users’ privacy. The seed is represented as a 12 words long mnemonic passphrase. The wallet is open source.