pull down to refresh
111 sats \ 5 replies \ @justin_shocknet 2 Jul \ on: We are BitBox, makers of the open source BitBox02 - AMA! AMA
This looks like the most promising hardware signer to date, but I'm still suspicious of anything tailored for these purposes.
If a manufacturer is sophisticated enough to address the concerns of paranoid people like myself, then surely they're sophisticated enough to implement some kind of exfiltration? (Your address of klepto is excellent, but should also give people pause to think about the attacks they don't know about)
#1008583
IIUC, there are still closed source chips on the board and the mitigation for that is published xrays and an industry certification? Have any 3rd parties done an EMC test?
How would you overcome the objection that obscurity is a last line of defense and that HWW's cary an inherent targeting risk?
Why do you suppose there's not a more general, industry-scale HSM, that supports Bitcoin transactions? Like if YubiKeys supported Bitcoin curves...
I think the gist of this question is a general mistrust in hww. This is totally fine, and we do a lot to address these questions. There are many different aspects to this.
A blog post of mine goes into the details of how we combine a secure chip (which we don't trust) with open-source firmware. It's more important to build a robust security architecture that can handle untrusted components (for example, they never learn any secrets) and avoid singe-points of failures.
Unfortunately, verifying hardware is much more complicated than verifying software. You can't run a checksum over hardware, and there's no "reproducible build" process. All you can do as a verifyer is physical spot checks.
This is why open-source firmware is so important. You can verify the "logic" of the device, how it works, what it does, and what it does not do. It also keeps us as a manufacturer accountable.
EMC tests are part of the FCC certifaction process, and of course the BitBox underwent these checks. But these are not security checks, and no amount of them will give assurance for every BitBox, as these are just spot-checks.
Again, open-source firmware helps. The best a malicious hardware chip that is not supposed to be there can do is try a side-channel attack, for example listening in on a wire, as there's provably no code or logic that would actively use this chip. So if the chips never learn any secrets, that's the best guarantee.
For ultimate protection, to completely eliminate any trust in a specific manufacturer, there's multi-vendor multi-sig. As multiple signers from multiple vendors are involved, all of them would need to collude to pull of a targeted attack. With open-source, that can't be done in secret, so it would be a "burn all bridges and run" attack. As publicly listed companies, this is not feasible.
reply
Thanks.
It seems to be an impossible challenge to obviate multi-vendor setups with the hardware supply chains that are currently available, but you're definitely raising the bar with these mitigations.
Keep up the good work.
We always aim to reduce trust, however there is always some level of trust needed in the hardware wallet manufacturer. If you want to significantly reduce the trust needed in a particular company, then it is probably best to set up a multisig using hardware wallets from different companies. /Jad
reply
I'll leave the very specific questions to my colleagues, but to your question about 3rd party chips on the PCB:
Even though we have a closed source secure element and now a bluetooth chip, we do not trust these chips. The secure element does not store the private keys, it only stores one of the three secrets to decrypt the seed stored on the MCU. Of course the bluetooth chip never gets access to private key information and is only used for communication purposes.
/Joko
reply