Announcing the BitBox01 (aka Digital Bitbox) end-of-sale and end-of-life dates and process
Today, we stop selling the BitBox01 with official support ending a year later in November 2020. As a thank you, we’re offering all BitBox01 customers a 30% loyalty discount to move over to the BitBox02, our new flagship product with better usability and security. All BitBox01 users will be able to access their discount code for our online shop via the next BitBoxApp update with an in-app notification.
The first BitBox01 hardware wallet came to market on 25 March 2016 to protect your funds from a potentially compromised computer. With the BitBox01, we pioneered wallet backups to a microSD card and a portable form that allows you to put the device on your key ring. Instead of featuring a screen, you could pair the BitBox01 with your mobile phone to verify receive addresses and transactions on a remote screen. This set-up allowed us to offer a less complicated and expensive to produce hardware wallet. However, by using an on-board screen, like in the new BitBox02, the attack surface is reduced and the product is easier to maintain. In the longer run, security will be better served by upgrading to the BitBox02.
We want to give everyone enough time to move their funds to a new set-up. We will therefore continue to support the BitBox01 in our app and through firstname.lastname@example.org until November 2020. We will continue to provide security patches for any issues that arise. However, we will stop paying bug bounties for new reports by security researchers for the BitBox01 with immediate effect.
What we learned
During the lifetime of the BitBox01 we learned a lot. Here are some of our key lessons and how we’ve addressed them in the BitBox02.
Complexity really is the enemy of security
Without an integrated screen, you had to pair a mobile phone in order to know what you were confirming by touching the BitBox01. Since the only way for the device to communicate to the mobile phone is through the potentially attacker-controlled computer, the channel had to be set up securely and resistant to manipulation.
Saleem Rashid broke the pairing a few times (see his blog post for the first exploit). First, the initial key exchange to set up the channel had to be protected against a man in the middle. The only way to ensure this is to pass information out-of-band from one endpoint to the other. With only touch and LED blinks available, we ended up with a sub-optimal user experience. For security, it was a challenge to protect against brute-forcing the exchanged key with such limited entropy out-of-band (fixed in release 4.0.0). But it also turned out that you could use the U2F interface to fake the blinks of the pairing on the BitBox01.
Once you have established the channel, you need to protect it against attacks like replay (fixed in release 6.0.0). This is the reason why we had to require a confirmation button press on the mobile phone even when “full 2FA” was not enabled. In addition, the mobile verification app was one more code base to maintain and check for vulnerabilities, and thus two injection attacks triggerable by the computer went unnoticed until Saleem Rashid reported them to us (fixed in the most recent release). We’re thankful for his work and efforts in improving the security of the BitBox01.
BitBox02 solution: By having an integrated screen with no attacker-controlled channel between the firmware and the screen and no additional code base, the BitBox02 avoids all these problems.
Security architecture before implementation
Security products should be designed carefully rather than growing organically. While this sounds obvious, it’s often not what happens in practice. Different engineers add different features over time. Another conceptual flaw, besides the pairing issue, is how the BitBox01 uses the ATAES132A secure chip. Originally added to have a good source of entropy for generating the seed, it was later also used to store the seed encrypted with a key stored in the MCU. However, no security protections for the secure chip were enabled, which means anyone could request the encrypted seed from the secure chip. We originally marketed this aspect as “all secrets (keys and passwords) are stored isolated on a separate high-security chip designed specifically to keep your secrets secret”. While technically true — as long as we only talk about the seed when it comes to keys — the claim is misleading so we removed it. Saleem Rashid offers detailed explanations in his blog post. Another lesson is to be very careful when translating technical properties into marketing messages. Technical marketing claims should always be vetted by engineers.
BitBox02 solution: Everything we learned from the BitBox01 went into the design of the hardware and firmware of the BitBox02. All the attack vectors we considered and the countermeasures we implemented are explained in our recently published threat model.
You have to maintain what you build
There are two key aspects to this. One, many early features like the hidden wallet for plausible deniability or full second-factor authorization were difficult to fix or maintain in a backwards-compatible manner, i.e., so that negative effects on existing users were as small as possible. Two, we shifted focus internally to develop the BitBox02, which meant less engineers and eyes looking at the BitBox01. As a consequence, security issues, such as the lack of keypath sanitization, can go unnoticed for too long.
BitBox02 solution: Focus our engineering resources on improving and maintaining a core hardware wallet that we see has the higher long term security potential.
Bug bounty programs work
Open-source software with financial incentives for security researchers has worked to the benefit of our users. Over the last two years, we received numerous reports through our bug bounty program. Many were minor but some were mission-critical. We greatly appreciate all who have contributed to our bug bounty program.
BitBox02 solution: Our bug bounty program and your help is important for making the BitBox02 as secure as possible. That is why we continue to develop in the open in our GitHub repositories for the firmware and the app.