With the BitBox Bellinzona update, we have introduced a new security mechanism for your BitBox02. It might not sound intuitive to implement additional security measures without there being a vulnerability in the first place. But this is where our ethos of “defense in depth” becomes relevant.
Defense in depth
The term “defense in depth” may have a military background, but nowadays it’s mostly used in cybersecurity references. It describes a strategy in which a defense line is not set up as a singular line of contact but rather multiple staggered defense lines. The goal is to maximize the attrition of an attacker by not giving them a single target to attack, and by making it necessary to defeat an entire area of fortifications with varying strengths. A breakthrough in one spot does not immediately lead to a collapse of the entire defense line.
This philosophy also applies to the security architecture of the BitBox02. Similar to a defense line, the security of the BitBox aims to have no single point of failure that can result in a full breach. Rather than giving a possible attacker a singular target to exploit, the BitBox02 spreads its security mechanism redundantly and as wide as possible.
Compromising a single aspect of the BitBox02 is generally not enough to gain access to the wallet. One example of this is our dual-chip architecture, which spreads the secrets needed to decrypt the seed stored on the BitBox02 over both the general purpose MCU and the secure chip. In other hardware wallets, compromising either the secure chip or the MCU is enough. With the BitBox02, both chips would need to be breached, and the seed would still be protected by the device password that is not stored on the device at all. Other examples of this “security in depth” approach include reproducible builds, the anti-klepto protocol, and our USB communication encryption.
In previous firmware versions, once the device was unlocked, the seed was decrypted and held in the BitBox02’s working memory (also called “random access memory, or RAM) without additional encryption. This was necessary because the BitBox02 needs access to the seed to function, e.g. so that the user can create addresses or sign transactions.
If however, at some point a vulnerability would be found that could give an attacker access to the contents of the RAM, this could leave the keys vulnerable to extraction. This is a very unlikely scenario, because the attacker would likely need to have physical access to an unlocked device in their electronics laboratory while the device must stay powered on at all times. But even for an attack like this, we can still prepare and mitigate the possible damage.
By keeping the seed encrypted when it is not actively used, and only decrypting it temporarily when absolutely necessary, we can avoid a security breach even in case of a possible RAM read-out.
But how does this work? If the encryption key for the seed is also held in the device’s RAM, an attacker could just read out both and decrypt the seed afterwards. How can the BitBox02 keep the seed encrypted and still sign transactions without the need to enter the device password every time?
How the seed encryption works
Encrypting data in the device's working memory, where it also needs to keep the encryption key in some form, is no easy feat. Here’s how we implemented it for the BitBox02:
- Unlocking the BitBox02: When you plug in your BitBox02, you are asked for your device password. The device password, in combination with the secrets on the general-purpose MCU and the secure chip, decrypts the encrypted seed that’s stored in the flash memory of the BitBox02. This is explained in detail in our article Best of both worlds: using a secure chip with open source firmware
- Creating the encryption key: After this initial unlock, the MCU creates a random key. This random key is then sent to the secure chip, which stretches the key via its key derivation function. For this, it uses the same secret that’s stored in the secure element for the initial unlock. This allows us to safely hold a precursor of the actual encryption key in RAM, to learn the real encryption key you need to run it through the secure chip.
- Encrypting the seed: The stretched key is sent back to the MCU, which then uses it to re-encrypt the seed that it holds in the RAM. The stretched encryption key and the unencrypted seed are then immediately discarded.
- Decrypting the seed: To decrypt the seed, for example to send a transaction, the MCU again requests the stretched key from the secure element. With this temporary stretched key, it can decrypt the encrypted seed and sign the transaction. After signing each input, the stretched key is immediately discarded and only the encrypted key remains on the MCU.
With this process, the seed is still protected if an attacker manages to read out the working memory of the BitBox02.
Because the random key is only held in RAM, unplugging the BitBox02 will erase it. This makes sure that the device password is once again required to decrypt the seed.
Having the seed only decrypted when absolutely necessary makes the BitBox02 more secure. As the manufacturer of a device that is used to custody large amounts of money, we must account for the possibility that our current security assumptions may not always remain valid in the future. This is why it is important not to rely on what could be a singular point of failure, but to build multiple layers of security into your architecture and constantly improve the overall security of the BitBox02.
Like a castle adding another wall inside its perimeter, the BitBox02 now has an additional layer of defense.
Don’t own a BitBox yet?
Keeping your crypto secure doesn't have to be hard. The BitBox02 hardware wallet stores the private keys for your cryptocurrencies offline. So you can manage your coins safely.
The BitBox02 also comes in Bitcoin-only version, featuring a radically focused firmware: less code means less attack surface, which further improves your security when only storing Bitcoin.
Frequently Asked Questions (FAQ)
What is the "defense in depth" approach in the BitBox02?
It refers to a strategy where there isn't just one line of defense. Instead, multiple staggered defense lines are set up to maximize the attrition of an attacker. A breakthrough in one spot doesn't lead to a collapse of the entire defense line.
How does the BitBox02 ensure there's no single point of failure?
The BitBox02 spreads its security mechanisms redundantly and as wide as possible. For instance, it uses a dual-chip architecture, spreading the secrets needed to decrypt the seed across both the MCU and the secure chip. Breaching one isn't enough; both chips and the device password are required.
Why was seed encryption in RAM introduced in the BitBox02?
Previously, once unlocked, the seed was decrypted in the BitBox02’s RAM without extra encryption. If a vulnerability gave an attacker access to the RAM, the keys could be vulnerable. By keeping the seed encrypted when not in use and decrypting it only when necessary, security is enhanced.
How does the BitBox02 manage seed encryption without constant password input?
After the initial unlock with the device password, the MCU creates a random key. This key, combined with secrets from the MCU and secure chip, is used to re-encrypt the seed in RAM. To decrypt the seed for transactions, the MCU requests the stretched key from the secure element.
Shift Crypto is a privately-held company based in Zurich, Switzerland. Our team of Bitcoin contributors, crypto experts, and security engineers builds products that enable customers to enjoy a stress-free journey from novice to mastery level of cryptocurrency management. The BitBox02, our second generation hardware wallet, lets users store, protect, and transact Bitcoin and other cryptocurrencies with ease - along with its software companion, the BitBoxApp.