Protection against the nonce covert channel attack was released for the BitBox02 in the 01.2021 Monte Rosa update.

What is this about?

Hardware wallets such as the BitBox02 create digital signatures to authorize your transactions. They use private keys for that. Without knowing the correct private key, it is practically impossible to forge a signature. A signature is mathematically constructed with the help of a nonce, a secret number which can be freely chosen by the hardware wallet.

A malicious hardware wallet can leak private keys through the signatures it creates by manipulating these nonces. Since signatures are part of the transactions recorded in the public blockchain, a remote attacker can read them and reconstruct your private keys, gaining control over all your funds.

We can mitigate this attack by provably including a nonce contribution from the host software, like the BitBoxApp, preventing any such manipulation from taking place.

This attack is particularly interesting in two regards:

  • Even if you verify every detail of the transaction in a completely safe environment and use a completely air gapped system to sign the transaction, you are still not protected, unless the anti-klepto protocol is active.
  • This attack sidesteps any involvement with computers and mobile phones. It applies even if your computer or mobile wallet that you use to interact with your hardware wallet is not compromised.

The anti-klepto protocol can prevent this attack by enabling your computer or mobile wallet to check that no malicious manipulation of the signatures has taken place, and to react appropriately if it detected any manipulation.

Why is this helpful?

We are big believers in defense in depth and the “don’t trust, verify!” slogan.

As part of our effort to increase transparency and to reduce the trust you need to put into the supply chain, we have continuously rolled out features and tooling that helps you verify the integrity and security of your BitBox02 and your seed, for example:

  • Only firmware officially signed by Shift Crypto can run on the BitBox02.
  • Each computer and mobile wallet automatically performs an attestation check (genuine check) to ensure the BitBox02 was factory programmed by Shift, before proceeding to the device unlock.
  • All our code is open source, covering the BitBox02 firmware, BitBoxApp, and all our libraries used in third party wallet integrations.
  • You can verify that the firmware binary files we publish are actually built from the published source code. For instructions, refer to our guide on “Reproducible builds”.
  • You can configure the BitBox02 to display a checksum of the firmware on the screen before it executes the firmware, and verify independently that it corresponds to the official release.
  • Since the 01.2021 Monte Rosa release, you can generate your own seed without relying on the BitBox02’s random number generation process, for example by throwing dice. Follow our guide “Roll your own Bitcoin seed”.

The anti-klepto protocol is our latest addition to this list. Just like the other features, it increases the cost and effort needed to perform a successful supply chain attack.

Manipulating the seed generation, and leaking the seed in a nonce covert channel, are probably among the most effective ways to perform a large scale attack. Both of these issues are addressed in our recent 01.2021 Monte Rosa release.

A mini primer: private keys, public keys

A private key is simply a large number, large enough that it cannot be guessed, for example:

92193805913277071008055984303319191614197341949664602874511898854633635443214

For each private key, there is a corresponding public key, which translates to your Bitcoin address. Funds sent to an address can only be moved by knowing the corresponding private key. Knowing a public key alone does not reveal any information about its private key.

Nowadays, instead of managing many private keys, a wallet manages only one seed, from which it derives subkeys on demand. The seed is what you backup onto your microSD card when initializing your BitBox02, or what you write on paper with 24 recovery words.

The formula to derive a public key from a private key is publicKey = privateKey×G, where G is some predefined value.

The values are technically part of a mathematical group, where addition has a special meaning. If you want to learn more about this, an excellent introduction to this topic can be found in the blog series “Elliptic Curve Cryptography: a gentle introduction”.

Apart from division being impossible here (otherwise you could compute the private key from the public key!), most of the usual math works the same way. Familiar laws like the distributive law hold: (a + b)×G = a×G + b×G. This law is what enables the computer wallet to prevent the covert nonce channel attack, as we will see later.

Covert nonce channel attack

One part of a digital signature is the nonce. The nonce is just like a private key, but it is created randomly each time a signature is made. Like any private key, there is a corresponding public key nonce×G. This public key is part of the signature, which ultimately is recorded in the blockchain along with the transaction.

Because of the many pitfalls in using random nonces, most wallets have switched to using deterministic nonces. They do not rely on random number generators, but are instead derived by hashing the private key, the message to be signed, and optional additional data. Unfortunately, by looking at such a nonce alone, it is impossible to tell whether it was generated randomly, deterministically, or in the case of the covert channel attack, maliciously.

In order for a malicious hardware wallet to extract the wallet seed (from which all other private keys are derived), it simply needs to encode parts of it in the nonce public key, which will be recorded in the public blockchain as part of a transaction signature. After a certain number of these malicious signatures make it onto the chain, the attacker can look for them and recompose your seed.

There are a few obstacles for the malicious hardware wallet:

  • It needs to randomly try many different nonces until the nonce public key exhibits the desired pattern. Since this is a slow process, only very few bytes of the whole signature can be influenced by the malicious hardware wallet at a time.
  • The signature also needs to contain some sort of hidden marker, so the attacker (and only the attacker) can recognize them when scanning the blockchain.

As a consequence, the seed cannot be extracted with only one signature, multiple are necessary. Depending on the method and environment, a few dozen signatures can be sufficient to extract the full seed.

Prevention: the anti-klepto protocol

The attack is thwarted by limiting the hardware wallet’s ability to choose the nonce freely. To do so, the BitBoxApp (or any other software that interacts with the BitBox02) will require the hardware wallet to choose a nonce of its own like before, but it will also force it to add a nonce chosen by the BitBoxApp itself.

The protocol goes as follows and is run for each signature.

Note that I’ll describe a simplified protocol aimed to explain the concept at a high level. The full protocol with all details is documented alongside the implementation in the code and can be found here.

Let’s dive in:

The hardware wallet is first required to commit to the nonce it intends to use by sending the device nonce public key to the host wallet:

deviceNoncePublicKey = deviceNonce × G

By revealing this to the host wallet, the hardware wallet cannot change it later on.

The host wallet chooses a random nonce of its own, hostNonce, and sends it to the hardware wallet.

The hardware wallet will then use a combined nonce
nonce = deviceNonce + hostNonce for the final signature. The resulting nonce public key in the signature then is:

nonce×G = (deviceNonce + hostNonce) × G

The host wallet can verify that its nonce contribution indeed was used and is present in the final nonce public key by checking that:

nonce×G = deviceNonce × G + hostNonce × G (distributive law)
= deviceNoncePublickey + hostNonce × G

The host can do this by using the deviceNoncePublicKey received earlier. If this verification fails, the host wallet will abort the operation and not broadcast the transaction, preventing a covert leak of any secrets by the device.

There are a few details which are very important to get right in the actual implementation:

  • The hardware wallet must not learn about the host nonce before it reveals its original nonce, otherwise it has full freedom again in choosing the final nonce. The host wallet must ensure this.
  • The hardware wallet must not use the same nonce for two different host nonces, otherwise the private key will leak immediately to the host. This is accomplished by sending a hash commitment of the host nonce to the device upfront. The device can use this to create different nonces depending on the host nonces.

Rollout

Jonas Nick first implemented the anti-klepto protocol for use with Schnorr signatures, an upcoming soft fork. Based on this, I implemented the same for ECDSA signatures, and opened a pull request for review in the secp256k1 library. ECDSA is the signature scheme currently used in Bitcoin and many other altcoins, so support for it is required to make use of the anti-klepto protocol already today.

We released support for the protocol update in the BitBox02 firmware version 9.4.0 with the 01.2021 Monte Rosa update. The BitBoxApp, starting from version 4.25, contributes nonces and verifies that the BitBox02 uses them when signing a Bitcoin or Litecoin transaction. In future releases, we plan to also add support for the anti-klepto protocol when signing Ethereum transactions, as well as when signing Bitcoin and Ethereum messages. At some point, we would like to enforce this protocol, which will require a firmware upgrade.

All our open source BitBox02 software libraries were also updated to support anti-klepto. This means that integrations of the BitBox02 in third party wallets such as HWI, Electrum, MyEtherWallet etc. will automatically gain support over time.

Shoutout and a word on open source collaboration

Many thanks to Stepan Snigirev for drawing attention to, and providing a great explanation of this topic with his blog post. It played a big part in motivating me to work on a production grade implementation of this protocol for the BitBox02 and other hardware wallets.

The BitBox02 relies on the open-source secp256k1 cryptographic library, the same which also powers the Bitcoin Core full node and wallet.

Many thanks to Jonas Nick, who generously went through many iterations of review of my contribution. The process was paused for a while as Jonas got busy with BIP-Schnorr, MuSig2 and other interesting projects. Thanks to Andrew Poelstra for picking up my work and seeing it through until it was finally merged in secp256k1-zkp. Thanks also to Tim Ruffing for providing additional review.

A large benefit is that the work is open source and part of a well-vetted library, so it can be used by anyone. We expect and look forward to many other hardware wallets and offline signers to adopt this protocol. Blockstream already announced that they will add support to their recently launched Jade hardware wallet.

Useful resources

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.

Grab one in our shop!

Frequently Asked Questions (FAQ)

What is the nonce covert channel attack?
The nonce covert channel attack involves a malicious hardware wallet leaking private keys through the signatures it creates by manipulating nonces. These signatures are part of the transactions recorded in the public blockchain, allowing a remote attacker to read them, reconstruct your private keys, and gain control over all your bitcoin.

How does the anti-klepto protocol work?
The anti-klepto protocol prevents the nonce covert channel attack by enabling your computer or mobile wallet to check that no malicious manipulation of the signatures has taken place. It does this by requiring the hardware wallet to choose a nonce and then forcing it to add a nonce chosen by the host software, like the BitBoxApp. This ensures that the hardware wallet cannot freely choose the nonce, preventing any covert leak of secrets.

Why is the anti-klepto protocol important?
Even if you verify every detail of a transaction in a completely safe environment and use an air-gapped system to sign the transaction, you are still not protected against the nonce covert channel attack unless the anti-klepto protocol is active. The protocol sidesteps any involvement with computers and mobile phones, ensuring protection even if your devices are compromised.

What is a nonce in the context of digital signatures?
A nonce is a secret number used in the creation of digital signatures. It can be freely chosen by the hardware wallet and is mathematically constructed to authorize transactions. A malicious hardware wallet can manipulate these nonces to leak private keys through the signatures it creates.

How does the BitBox02 ensure the integrity and security of its operations?
The BitBox02 has several features to ensure its integrity and security: Only firmware officially signed by Shift Crypto can run on the BitBox02. Each computer and mobile wallet automatically performs an attestation check to ensure the BitBox02 was factory programmed by Shift. All code is open source, covering the BitBox02 firmware, BitBoxApp, and all libraries used in third-party wallet integrations. Users can verify that the firmware binary files are built from the published source code. The BitBox02 can display a checksum of the firmware on the screen for verification. Users can generate their own seed without relying on the BitBox02’s random number generation process."

What is the difference between a private key and a public key?
A private key is a large number that cannot be guessed, and for each private key, there is a corresponding public key which translates to a Bitcoin address. Funds sent to an address can only be moved by knowing the corresponding private key. Knowing a public key alone does not reveal any information about its private key.

Shift Crypto is a privately held company based in Zurich, Switzerland. Our international team of specialists across engineering, cryptosecurity and Bitcoin core development build the BitBox products and provide consulting services. The BitBox02, a second generation hardware wallet, equips individuals to easily store, protect, and transact cryptocurrencies. Its companion, the BitBoxApp, provides an all-in-one solution to securely manage your digital assets with ease.