BitBox logo

BitBox02 threat model

Introduction

This page uses technical language and is primarily written for advanced users and security researchers. For ordinary users, we recommend to first have a look at the security features.

Overview

Summary

We designed both the hardware and the firmware of the BitBox02 from scratch based on all the learnings we gained from the BitBox01. The BitBox02 features a secure chip, the ATECC608B, to harden the user-chosen device password, which encrypts the wallet seed stored on the MCU. We do this by combining the device password on the secure chip with a key generated and stored on the secure chip and limit the number of key derivations with a monotonic counter enforced by the secure chip. Once the seed on the MCU is decrypted, we do all cryptographic operations like BIP32 key derivation and ECDSA signing on the MCU with open source code that is fully auditable and can be built deterministically (more on this below).

Threat model

The BitBox02 is designed to protect you from attackers that try to steal your funds (without using coercion), make you lose funds (without getting it themselves) or compromise your privacy without unlocking the device first, for example, by learning your transaction history. In order to be secure, you should always trust the screen of your hardware wallet over the information displayed on your computer and verify carefully what is displayed on your hardware wallet. The reason why you should buy and use a hardware wallet is to reduce your attack surface from a highly complex general purpose operating system with millions of lines of code and weak security domains to a security device built for a single purpose – namely to keep your private keys private – that only runs trusted code. The only time you should side with your computer is when the BitBoxApp tells you that the device is not authentic or that the device did not follow the anti-klepto protocol (more information below).

Out of scope

There are no protections in place if an attacker gets access to both your device and your device password or to your backup. In the latter case, however, you can enable an optional passphrase, which you have to enter every time you use your BitBox02. This is an advanced feature that you use at your own risk (see below). (If you forget or misremember your optional passphrase, your coins are lost and no one can help you.) By gluing the casing to the PCB with epoxy, we try to make it difficult to tamper with the device. However, if you unlock a tampered device with your device password, the attacker is likely to succeed. Such targeted attacks are out of scope for the threat model of the BitBox02. Please note that a lost or stolen device does not fall into this category. The BitBox02 is designed to protect your assets in such cases.

Attack vectors and countermeasures

Device attacks

Firmware bugs

The BitBox02 firmware can contain vulnerabilities such as buffer overflows, memory leaks and other unintended functionality, which could make the device exploitable from a compromised computer. As countermeasures, we use stack smashing protection to prevent buffer overflows, make as many memory areas as possible non-executable with the memory protection unit (MPU) of the MCU and use two specific integer values to encode booleans. Additionally, we lock the device down during factory setup by disabling debug interfaces to the MCU, making the bootloader read-only and irreversibly configuring the secure chip. Moreover, the firmware exposes its full API to the computer only after unlocking it with the device password. (Only the device authenticity check takes place before that.) In order to encourage reviews by independent security researchers and responsible disclosures of found vulnerabilities, our firmware code is fully open-source and we run a bug bounty program.

Invasive attacks

We assume that an attacker can decapsulate the MCU and read its memory or replace components such as the secure chip or MCU on the PCB after the user stopped using the device. (As mentioned above, unlocking a tampered device is out of scope.) The secure chip that we use (the ATECC608B) is designed in such a way that it should not be possible to read out its memory. (Prior to the release of the ATECC608B chip, BitBox02 used the earlier ATECC608A chip.) Since we combine information from the user (namely the device password), the MCU and the secure chip to decrypt the wallet seed, you are protected against invasive attacks on the MCU. A monotonic counter on the secure chip prevents an attacker from brute-forcing the device password (see below). In addition, the MCU and the secure chip authenticate and encrypt some of their communication with IO protection, encryption and auth keys generated during the factory setup.

Non-invasive attacks

By analyzing the execution time, electromagnetic radiation or power consumption of the device, an attacker could learn sensitive information from the device, which is known as a side-channel attack. We try to prevent this by using well known open-source cryptographic libraries, which run in constant time and were thoroughly reviewed, wherever possible. Unfortunately, we didn’t have time yet to address the OLED power consumption side-channel vulnerability discovered by Christian Reitter (also see the article by Trezor).

Evil maid attacks

An attacker can steal the device from you and modify or replace it before giving it back to you. Unlike in case of the invasive attacks above, you interact with the tampered device. As countermeasures, we sign a key generated on the device for each device during the factory setup and verify the authenticity of the device with the BitBoxApp before every use. Moreover, since we encrypt the USB communication (more on this below) and both the device and the app remember the counterparty with which they were paired, having to re-pair should raise your suspicion that either your BitBox02 has been replaced or that your computer runs a malicious app. The device itself is sealed with epoxy and each time before using it you should check it for signs of tampering. However, with enough effort, evil maid attacks are feasible as explained above.

Brute-forcing

If an attacker gets access to your device, they can try to brute-force the device password you use to unlock your device. By limiting the number of attempts both in the firmware and on the secure chip using its monotonic counter, which is increased for every unlocking and bricks the chip when brute-forcing, we try to make brute-forcing your device password as unlikely to succeed as possible. In addition, each attempt requires a certain computational effort, which also makes brute-forcing harder by slowing down its execution.

Computer attacks

Malicious app/computer

A compromised computer is the main attack vector that hardware wallets protect you against. By replacing the stored app or by tricking the user to download a malicious app, an attacker can control whatever the app does and displays on the computer. For this reason, you have to confirm all security-relevant actions on the device itself. Since an attacker could record the keystrokes on your machine, you can only enter your device password on the BitBox02. In order that you can verify that you downloaded the right app, we publish the hash of the BitBoxApp and sign it.

Malicious USB stack/connection

Certain operating systems like Qubes OS isolate the app from the USB stack. If only the USB stack, some USB cable or hub is compromised but not the app itself, we protect your privacy by encrypting and authenticating the USB communication between the app and the firmware with the Noise_XX_25519_ChaChaPoly_SHA256 protocol from the Noise Protocol Framework. Additionally, remembering the long-term keys on the device and the computer allows the firmware and the app to detect when the other endpoint changed. The device currently can remember up to five pairings, after which the oldest is rotated out. The out-of-band confirmation of the pairing code ensures that there is no man-in-the-middle.

Clipboard hijacking

A malicious program can read the content of your clipboard and replace its content to a different receive address. Such an attack is detrimental both when sending and receiving funds. This is why you should always double-check with the original information after pasting an address.

Services attacks

Compromised server

A compromised server is a problem both for the security (e.g. wrong balance or exchange rates) and privacy (e.g. tracking IP addresses and transactions) of our users. To reduce the risks, the BitBoxApp downloads all blockchain headers of Bitcoin and Litecoin, verifies the proof-of-work and then checks that all your coins exist with a method known as simplified payment verification (SPV). The app also allows you to configure your own backend in order to be fully independent of Shift’s servers, also in case of a denial-of-service attack on our infrastructure.

Supply chain attacks

Backdoored entropy

The firmware uses the true random number generators (TRNG) of the MCU and secure chip to generate the entropy of your wallet seed. However, it’s impossible for us and for you to verify whether the generated randomness is truly random or whether it has been backdoored by the manufacturer. This is why we combine the randomness of the two chips with randomness that we generate and store for each device during the factory setup, with randomness provided by your computer and with the entropy of your device password. If you want to use a seed that has not been generated by our open-source firmware, you can import a seed that you generated yourself with either the BIP39 mnemonic import functionality or the microSD card backup recovery.

Device shipping

The BitBox02 can get replaced or tampered with after it leaves the factory and before it reaches you. It is absolutely crucial that you always set up your wallets yourself. Otherwise, one of our employees or a reseller could ship to you a device initialized with a seed known to them. In order to make fake devices and evil-maid attacks more difficult, we sign a key generated on the secure chip of each device during the factory setup. The BitBox App then checks that it is connected to an authentic device produced and programmed by Shift Crypto with a challenge-response mechanism.

Malicious firmware

In order to prevent that a reseller or a malicious app installs a malicious firmware on your device, each firmware version has to be signed by several engineers at Shift Crypto with no single point of failure. Before accepting a new firmware, the bootloader on your device checks the signatures of the firmware before installing and running it. However, some of our employees could try to inject a malicious bootloader. By returning the hash of the bootloader from the firmware during the device authenticity check, we increase the complexity to pull this off.

Binary intransparency

Shift Crypto might be forced by a state or a criminal organization to sign a malicious firmware and deliver it just to you. We allow you to detect this by configuring the bootloader to always show the hash of the installed firmware before running it during booting, thereby further reducing the required trust in us. The firmware itself can be built deterministically, which allows you to verify what you install before the installation. If you do so, please consider contributing your verification to our repository so that other members of the community can take your word instead of ours (see the releases for more information).

Exfiltration of secrets via a nonce covert channel

The BitBox02 supports the anti-klepto protocol to prevent exfiltration of secrets through the signatures it creates. Read more details about it here.

The BitBox02 supports the anti-klepto protocol for ECDSA signatures created for the secp256k1 elliptic curve. There is no support for this protocol for Schnorr signatures on secp256k1 (used by e.g. Taproot) and elliptic curves other than secp256k1.

User attacks

Misinformation

There is only so much we as Shift Crypto can do to protect your financial assets. It is also up to you to properly inform and educate yourself and to not act naively. Besides always trusting the screen of your BitBox02 over the one of your computer with the exception of the device authenticity check, you should always set up the device yourself and never give your device password or wallet backup to anyone else. We will never ask you for your password, microSD card or mnemonic phrase and neither should anyone else. Only rely on others for handling your BitBox if they are completely trustworthy (and you asked them to help you rather than the other way around). Never accept unsolicited help for your cryptoassets.

Stolen backup

Anyone who has access to your wallet backup has access to all your funds unless an optional passphrase is set. You can enable this advanced feature in the BitBoxApp, on the "Manage Device" page.
If you enabled the optional passphrase feature: please note that any passphrase derives a valid wallet. If you forget the passphrase you used, no one can help you. The passphrase is not part of the backup and in order to recover a wallet from a backup, both the backup itself and the passphrase is necessary.

Read more