On the security model of software wallets

We can distinguish two prevalent types of wallets: software and hardware wallets. They fulfill the same function, but in a different way. Software wallets are considered simpler to use: a single program is enough to create, validate and sign transactions. With a software wallet, it is not necessary to create the transaction on the software and confirm it on a hardware device.

Two weeks ago, Forbidden Stories unveiled a targeted attack against thousands of people around the world. This attack exploited vulnerabilities on Android and iOS, to install spyware developed by the NSO Group: Pegasus. This malware is able to monitor the whole activity of the device, and to exfiltrate personal information: SMS, WhatsApp and Signal conversations, phone calls, etc. This article explains how, under these conditions, such a malware would be able to extract all the secrets of a software wallets, and the differences from a security point of view between software wallets on mobile phones and desktop computers.

This article is intended to be not very technical. To keep it relatively simple, only basic features will be discussed.

Protecting secrets

What is stored in a crypto wallet?

Wallets do not actually store the users’ cryptocurrencies: they only store the secrets, notably the private keys, that allow to access the cryptocurrencies and the ability to spend them. These private keys are mostly ECC (elliptic curve cryptography) private keys on different curves depending on the blockchain. The most common curves are secp256k1 (Bitcoin, Ethereum…), Ed25519 (Monero), or BLS12-381 (Ethereum 2).

These keys are used to sign transactions, and more generally to interact with blockchain assets.

The storage of these keys depends on the type of wallet: deterministic or not. A Hierarchical Deterministic (HD) wallet allows the creation of a tree of keys from a single master secret called the seed (cf BIP44). This seed is often derived from a mnemonic sequence of 12, 18 or 24 words randomly generated or chosen by the user (cf.BIP39). These mnemonics allow to limit the number of keys to be stored: they can be recomputed anytime from the seed. HD wallets only store this mnemonic or the seed.

Non deterministic wallets generate a new key for each use and must store all of them. Non-deterministic wallets can’t be easily migrated to another wallet since backups are not compatible.

The main security features of a wallet consist in generating, storing and using these secrets properly. There are different levels of security against different types of threats:

• Protection against “evil maid” attacks : An attacker with temporary access to the wallet mustn’t be able to add a backdoor inside the wallet allowing to steal the PIN or the password protecting secrets.
• Secure cryptographic material : Keys and nonce generated by the wallet must never be predictable. Furthermore the knowledge of secrets (except the seed) generated at some point in time shall not allow to predict the secret to be generated in the future.
• Protection at rest : If an attacker obtains persistent data of a software wallet, they must not be able to extract the keys.
• Protection during secret use: When the wallet is unlocked, the keys must not be accessible by an attacker or a malware.

Hardware wallets

The security model of a hardware wallet aims at obviating these security threats. Hardware wallets protect against malware by design. They are independent devices which sign transactions on their own. The cryptographic materials always stay inside the device and are never sent to the software application to which they communicate. The communication interface is always simple which drastically reduces the attack surface. It can be USB, Micro SD or camera + screen (through QR code), or Bluetooth Low Energy.

Furthermore, hardware wallets embed a screen directly into the device allowing the user to verify the actions he’s about to do when he interacts with his secret keys. These manual checks on devices are a very efficient countermeasure against malware on the computer/mobile. Where malware on a computer/mobile device could access the secrets (seed or private keys) or even swap/modify addresses or amounts when the user is performing a transaction, this is not possible with a hardware wallet.

Hardware wallets are also designed to protect against “evil maid” attacks and against an attacker with physical access. Depending on the hardware wallet, they have different levels of security, but in all cases they are designed to secure against these threats. A detailed description of Ledger Nano threat models can be found here.

Software Wallets

Regular software wallets protect secrets with regular means: security mechanisms of the operating system on which they run and sometimes an access control based on a PIN or a password.

In the following, desktop (Windows, macOS, Linux) wallets and mobile wallets are considered. The main differences between them mostly rely on the security mechanisms offered by the operating system.

Software wallets on a computer

Several popular wallets, such as Electrum, Exodus, Atomic or Bitcoin core, run on computers.

On a computer, security mechanisms offered by the operating system to isolate a wallet process from other processes are limited. Most apps are run by the same user, and apps are allowed to read other application’s data.

The security of these software wallets mainly relies on the security of the password that protects them, and also on the fact that no malware runs on the OS (which is quite difficult to guarantee, see recent news regarding Pegasus).

Most of the time, the seed is stored in an encrypted container protected by a password.A straightforward attack consists, for a malware or a remote administration tool, to retrieve this encrypted container and send it to the attacker. Then the password can either be brute-forced or obtained through using a keylogger.

In a scenario where an attacker only manages to access the encrypted container (the attacker finds a USB key containing a wallet, or installs malware on a computer, but the victim never opens his wallet application), the attacker has to brute force the password.

Most passwords are bad. There are billions of passwords that leaked on the web, and many people tend to reuse their passwords for several services. Ready-made tools allow you to retrieve passwords for cryptocurrencies wallets, such as btcrecover or hashcat. Passwords can be complex, but behind each wallet there is real money, hence attackers won’t hesitate to invest resources to break such passwords.

Two basic security principles to keep your passwords secure are to use a password manager, and to never reuse your password for different purposes.

The most concerning threat for software wallets are dedicated malware and stealers, developed specifically to drain your funds. Such malware, such as KPOT or ElectroRAT, do not even have to bruteforce your password: they can directly capture it when you enter it, decrypt the wallet configuration data, and exfiltrate the seed.

Here is a toy application, developed for this article, that targets the Electrum wallet (though it could have been another software wallet). It simulates a malware that steals the user password when it is entered by the victim. Password is then used to decrypt the wallet data, and to display the seed:

As you see, even if the password is complex, the app is able to retrieve it as it directly sniffes it in memory.

This example is very similar to the recent .SCR malware campaigns used to steal cryptocurrencies. Criminals used social engineering techniques to trick users into downloading a malicious screensaver. This screensaver was actually stealing information from the computer’s victim, including wallet and cryptocurrency exchange information.

To conclude on software wallets running on computers:

• In most cases software wallets running on computers protect the user’s seed using a password.
• The access control for these wallet files mainly rely on the security of the computer. In practice, it is hard to protect computers from malware, and as cryptocurrencies become mainstream, attacks against wallets will become more and more sophisticated.
• Using such software wallets to secure digital assets is not a good idea. Any specialized malware will be able to get the wallet files and find the passwords offline, or get the password through a keylogger.

Software wallets on a smartphone

Android and iOS smartphones offer by default security features that are not widely used on desktop operating systems.

Mobile operating systems offer app and user data protection. In particular, app sandboxes are mandatory for all apps. This is not the case on, for instance, Windows: by default, any application can access user data.

Hence, a malicious app cannot read data from another app, except if:

• It finds a vulnerability on that app.
• Or it manages to escalate privileges, for example by exploiting a kernel vulnerability allowing it to gain root access to the system.

Unfortunately, such attacks exist. They are much easier on outdated versions of Android and iOS, and on older or cheap devices where third-party code is often less secure.

On an up-to-date OS, these attacks are harder but not remotely unfeasible. For example, Ian Beer showed an extremely impressive zero-click attack on iOS 13.5 in December 2020. Guang Gong presented an exploit chain to remotely root a wide range of Qualcomm-based Android devices in June 2020. And, two weeks ago, Forbidden Stories unveiled that NSO Group used an exploit chain to target recent iOS and Android devices using 0-day vulnerabilities.

Less sophisticated attackers can use local vulnerabilities allowing them to extract wallet data from a malicious application. Vulnerability brokers such as Zerodium pay up to $200,000 for a privilege escalation to root on Android and iOS, but up to $1,500,000 for remote attacks.

We studied a couple of Android/iOS wallets. Their security depends on the app itself, but also on the security features of the underlying OS. Of course, when the security of the operating system is defeated, the application is not secure anymore

Two methods to protect the seed are commonly used:

• Password protection – wallet data is protected by a password entered by the user. The design is the same as for desktop wallets. In practice, data is harder to extract than from a computer, as retrieving app data from a malicious app is technically more difficult, for the reasons explained above. However, retrieving the password once the data has been stolen is in practice easier: entering complex passwords on mobile phones is tedious, hence users tend to choose simpler ones. Moreover, key derivation mechanisms (used to create a key from a password) on mobile devices are usually simpler to break, as they are often more lightweight for performance reasons.

• Coinomi and Metamask are examples of such wallets.

In the following video, we show another toy app developed for this article. It is a malware disguised as a fake Bitcoin ticker widget. Malware exploits a known vulnerability on an unpatched device to get a root acess on the device, and to exfiltrate the encrypted seed to a remote server. The server then bruteforces the password to decrypt the seed.

This method is not specific to a wallet. It can be (more or less) easily adapted to any password protected wallet. Here is he same example with Coinbase Wallet:

• Security based on the Android Keystore (or iOS Keychain) – In this case, wallet data is encrypted with an encryption key stored in the Android Keystore (iOS Keychain). These services were initially designed to securely store encryption keys, and many apps use them to generate a key that will encrypt all the sensitive user data.Applications using the Keystore implement the following mechanism:
  • The app asks the Keystore to generate an encryption key for a given identifier. Keystore generates the key and stores it securely.
  • When the app wants to encrypt or decrypt a blob, it sends the blob along with the key identifier to the Keystore.
  • Finally, the keystore checks if the app has actually the rights to use this key and sends back then output data to the app.

With this model, the app can’t know the value of the key but can use it. It is also possible to associate additional access controls to the key: for example, key access can be conditioned to a user authentication (request for a PIN or unlock pattern).

This mechanism can provide additional security, compared to password based protection. Indeed, on recent phones, the Keystore is backed by a Trusted Execution Environment (TEE), or sometimes a Secure Element.

That means an attacker with root privileges won’t be able to extract encryption keys from the keystore. Nevertheless, they will be able to use the Keystore as a decryption oracle, and to encrypt or decrypt any data they want.

Keystore offers encryption, but also signing services. So, could a wallet protect its encryption keys, making them difficult to extract? The answer is unfortunately no: software wallets do not use Keystore to sign transactions, and private keys are always manipulated in plaintext by the app.

This is for a simple reason: KeyStore and KeyChain offer generic signature and encryption services, but don’t support the cryptography used in cryptocurrencies. For instance, the KeyStore implements ECDSA Signature but only on NIST curves defined in FIPS 186-4 (P-224, P-256, P-384 and P-521). Bitcoin uses another curve, secp256k1, which is not supported yet.

To summarize, Keystore and Keychain are good services to protect secret and private keys. They can offer some security by encrypting sensitive data: some classes of vulnerabilities (arbitrary file read, for example) will be tacked by Keystore encryption. However, if a root privilege escalation is not enough to extract the key values from a hardware-backed Keystore, it is sufficient to decrypt sensitive data. An attacker able to instrument the app is able to retrieve its secrets.

To conclude on mobile wallets:

• The isolation mechanism between apps provided by iOS/Android raises the bar for security compared to a software wallet running on a computer. The attacker needs first a privilege escalation to access app data. This is feasible on outdated devices. Skilled attackers (Ian Beer did it in 6 months alone but… It is Ian Beer) can also do it on recent, patched devices.
• Key protection services (KeyStore, KeyChain) could add an additional layer of security for protecting secrets at rest. Nevertheless, as they don’t support cryptographic algorithms for cryptocurrency applications, key can still be extracted.
• In all cases, an attacker with a root access can either retrieve the seed at rest, when used, or leverage the user’s rights to empty the wallet using the software wallet as an oracle.

Here is a last example of a toy spyware targetting the Blockchain.com wallet (though this could be performed on many other wallets just as easily). It is installed remotely, and monitors the wallet. Once user has authenticated using his fingerprint, encryption key is unlocked and wallet data is decrypted. The spyware instruments the app to retrieve this encryption key. It then exfiltrate the key and the wallet data to a remote server:

Conclusion

As a conclusion, software wallets have different levels of security. However, their threat model does not cover the case of a malware running on the OS with a privilege escalation. This is by design: the wallet app cannot be more secure than the operating system it runs on.

• The isolation mechanism between apps provided by iOS/Android raises the bar for security compared to a software wallet running on a computer. The attacker needs first a privilege escalation to access app data.
• Key protection services (KeyStore, KeyChain) could add an additional layer of security for protecting secrets at rest. Nevertheless, as they don’t support cryptographic algorithms for cryptocurrency applications, keys have to be manipulated directly from the app, so they offer a limited protection.
• In all cases, an attacker with a root access, can either retrieve the seed at rest, when used, or leverage the user’s rights to empty the wallet using the software wallet as an oracle.