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.