Best of both worlds: using a secure chip with open source firmware
Tags: Cryptocurrency, Security, Wallet, Bitcoin

Best of both worlds: using a secure chip with open source firmware Stadicus Follow Jun 18 · 7 min read

Within the hardware wallet industry, there are two contrasting approaches to security design: relying on a secure chip (SC) as a black box, or using open-source firmware on a general purpose microcontroller unit (MCU). With the BitBox02, we found a security architecture that allows us to combine the advantages of both approaches.

Why using a secure chip is important

Hardware wallets are designed to keep your private keys secure. Most do a good job against remote attackers, shielding all sensitive information from your regular computer. This makes it hard for malicious wallet applications, malware or targeted remote attacks to steal your coins. Physical security is even harder. Specialized equipment allows an attacker to get access to information on the MCU, for example by reading information directly from inside a chip. Some ways to do this include decapsulating the chip with a laser or using acid and then reading out all the data. There can be some expensive equipment involved, but an attacker does not necessarily require a lab: services like this are available online, in countries where reverse engineering is legal.

General purpose MCUs are designed to focus on performance, functionality and cost above other considerations. They are not built to withstand such physical attacks. Secure chips are designed first and foremost with these attacks in mind, and are made to resist decapsulating, probing, fault injection and voltage glitching, buffer overflows or side-channel attacks.

We think it’s safe to say that physically protecting the data in a hardware wallet without using a secure chip is a lost cause.

The closed-source drawback

Secure chips are not even that expensive, so why does not every hardware wallet use them? The main drawback is that secure chips are closed source. Firmware running on a secure chip cannot be released as open source due to enforced non-disclosure agreements.

When it comes to firmware securing your bitcoin, creating random seeds and signing transactions, trusting closed source software that cannot be independently audited is just not good enough. In our opinion, you should not need to trust the manufacturer of your hardware wallet (and all its individual employees) to belong to the “good guys”, diligently finding their own bugs without independent reviews and then actually fixing them.

Best of both worlds

Still, general purpose MCUs are simply not up to the task of keeping a digital secret. In the best of all worlds, we would be able to run open-source firmware on an open-source secure chip. There are projects that aim to create such a chip, like TropicSquare, but no open-source chip is commercially available today. The next best option is to use the advantages of both open-source firmware and secure chip by combining them in a way that

the hardware wallet only runs open-source firmware,

the device is hardened against physical attacks using a secure chip, and

the secure chip does not need to be trusted, as it cannot learn any of the secrets.

The BitBox02 security architecture is designed towards these goals. We use two chips, a general purpose MCU and a secure chip in parallel, both with their unique strengths. Instead of running Bitcoin firmware directly on the secure chip, we run it on the MCU, meaning the code is fully open-source and auditable by anyone. Secrets are also stored on the MCU, but encrypted using multiple keys, including a key stored on the secure chip that can only be accessed using dedicated key derivation functions (KDF).

Compared to only using an MCU, this setup provides additional security features:

reading the encrypted data directly from the MCU is useless in itself

enforcing a delay during each unlock attempt to slow down brute-force attacks

limiting the maximum number of unlock attempts over the whole lifespan

a true random number generator (RNG), without the need to trust it

secure storage of a unique attestation keys to ensure only officially signed firmware can be used

Again, we don’t want to trust the secure chip. This is why our security architecture makes sure that the secure chip can never learn any cryptocurrency-related secrets. In the unlikely case that the secure chip is compromised and behaves maliciously, the overall security degrades to the security level of not using a secure chip in the first place, still securing your secrets using the user password and the MCU key.

How does it actually work?

Securing the seed

The master secret, also known as the wallet seed from which all private keys are derived, is encrypted and stored on the flash of the MCU. To gain access to the seed, three individual secrets are necessary, as described in the following illustration.

Of course, if an attacker is allowed to try out millions of device passwords per minute, such an architecture could easily be brute-forced. To limit these unlock attempts, two counters are used:

On the MCU, a counter limits the number of unlocks to 10 consecutive unsuccessful tries before resetting the device. As a second line of defense, the lifetime counter on the secure chip renders the device unusable after ~730’000 unlocks.

To slow down brute-force attempts, the key stretching to get the secret (K) from the secure chip needs to be run 3 times by using the KDF slot, causing a delay.

What does that mean for a potential thief? If you used an alphanumeric 8-character password, the thief would need on average over 1000 years to brute force the password, although the counter on the secure chip would brick the device already after about one day of trying. This scenario assumes that the counter on the MCU could be bypassed such that the device was not reset after only the first 10 unlock attempts.

Unlocking the seed

The seed becomes available to the open source firmware once the device is unlocked successfully. If even one of the three required secrets is missing, the encrypted seed stays inaccessible.

Don’t trust the secure chip

In this architecture, trusting the secure chip can be avoided. The chip is not able to learn any cryptocurrency-related secrets or degrade randomness used to create the wallet seed.

Secure device attestation

It is important that you know that your BitBox02 is a genuine device, and not a malicious clone. This is why the secure chip creates a unique attestation key that is then signed by Shift during the BitBox02 factory setup.

The secure chip creates

a private key that cannot be exported from the secure chip, and

the corresponding public key, which is signed by a Shift root key.

When you connect the BitBox02 to your computer, the BitBoxApp sends a challenge (a random number) to the device, which is signed and sent back, together with the corresponding public key previously signed by Shift.

The app is able to verify the whole certification path and shows a warning if this check fails.

By using this security architecture, we add and use a secure chip to significantly improve physical security without compromising our open-source values or potentially damaging overall security, even taking worst-case scenarios into account.

Interested in more security transparency regarding the BitBox02? Have a look at our extensive threat model!