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 permanently 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.
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
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.
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.
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.