benma
commented
3 months ago Hi
Thanks for these excellent questions.
Point one:
The host wallet automatically verifies this. To a user using the wallet, this check is invisible unless it fails. If the check fails, there is supposed to be an appropriate error message. Developers can verify that this check is happening by inspecting the source code, but this requires some expertise.
Point two:
There is no grinding because grinding does not work trivially in combination with the anti-klepto protocol. Normally, the signer locally grinds nonces until the signature has the smaller size, but with anti-klepto, the signer does not now the final nonce upfront, as the final nonce is computed in interaction with the host. In theory this is solvable, but adds some complexity, which we did not think was worth it for the small gain.
Point three:
If both the host computer and the device are compromised, then there is no protection. The anti-klepto protocol is primarily a defense-in-depth protection against attacks from the vendor itself, as the BitBox02 does not run unsigned firmware (third party malicious firmware does not run unless there is an exploit). If the host computer is compromised by a third party (not the vendor), they cannot pull off this attack, unless they manage to find a way to have the BitBox02 run the malicious firmware as well.
In this sense, BitBoxApp users are still somewhat exposed, as they get both the app and the firmware from the same source. Advanced users that compile the app from source are protected though (if of course they verify that the source is good).
Using third party wallets helps somewhat in this case, as they are independent. It is less likely that say BitBox and some popular third party host wallet collude.
In an ideal world, the BitBoxApp binaries are reproducible from the source and users verify their copy is legit (similar to how it can be done with the firmware).
Point four:
As far as I know, they all perform this check, at least the ones that use our client libraries.
About enforcement: the blog post you linked mentions this:
At some point, we would like to enforce this protocol, which will require a firmware upgrade.
Anti-klepto for BTC was introduced in firmware v9.4.0, but the BitBoxApp and many others do not force users to upgrade to this or a newer version, which means that effectively, the protocol may not be enforced. Our Rust and NPM libraries however do enforce the anti-klepto check (users have to upgrade to be able to sign correctly). The plan is still to enforce a firmware upgrade also in the BitBoxApp and in the Python library, so the check is enforced for good also in the BitBoxApp and HWI (which uses the Python lib).
Other notes:
Anti-klepto currently only exists for ECDSA sigs, so for segwit v0 inputs. Taproot uses Schnorr sigs, for which this protocol is not deployed yet.
Hello bitbox team,
I'm in the middle of testing a Bitbox02 device and have a couple of questions I can't get my head around.
Background: signing the exact same tx with multiple signers produces the same signature. An exception being Bitbox02. As a non-technical user I assume this is not because I have a compromised device but rather because of the use of "Anti-Klepto" as described in this blog post https://bitbox.swiss/blog/anti-klepto-explained-protection-against-leaking-private-keys/. By using different hardware wallets - and these producing deterministic signatures as per RFC 6979 - by loading the exact same mmnemonic onto them and comparing signatures I am able to assume they act non-maliciously by exclusion principles. Of course this is no 100% security but on the other hand the assumption would be that all well-known devices are backdoored as well as DIY solutions and popular software wallet implementations. Though computing signatures on multiple hardware is impractical this at least gives the user peace of mind.
Now, since BB02 is apparently using a different scheme,
1) can one verify that the Bitbox02 device is not leaking private information through its signatures and functions as advertised? How? What to verify against?
2) my Bitbox02 signatures are 71 bytes long, contrarary to the signatures e.g. bitcoin core, sparrow and my hardware wallets produce, which are 70 bytes long. Is there no grinding?
3) is "Anti-Klepto" protecting against a compromised host computer in conjunction with a compromised BB02 device? Since most users probably use one machine (e.g. for upgrading the device firmware as well as using it as a provider for the HostNonce when signing transactions) what are security benefits?
4) are there any differences in the signing process using the BitBoxApp vs. using the Bitbox02 device with Electrum/Sparrow/HWI? Do 3rd party implementations verify the additional data mixed in? Or in other words do these wallets enforce Anti-Klepto?
Thanks in advance.