search

btcguide / btcguide.github.io

https://btcguide.github.io/
MIT License
89 stars 49 forks source link

General Brainstorming #1

Closed hodlwave closed 4 years ago

hodlwave commented 4 years ago

Hi Michael,

I'm glad to see you've started writing this guide as I had been planning to do something very similar. After looking at what you've already written, I thought I'd add some other considerations that have been swirling around in my brain. I hope I can be of help to this project and apologies for the brain dump :)

Dimensions of HD Multisig Security

Verifiably correct bitcoin / crypto logic

It goes without saying that any discrepancies in the wallet or crypto logic between what user expects the software to do and what the software actually does leaves users vulnerable to loss of funds. The classic attack vector that you touch upon is the chosen nonce attack. How can users minimize the risk that the security critical software they're running is incorrect? Some considerations...

Open source Without fully open source code, it is impossible for users or trusted authorities to verify that the code is doing what it's supposed to. Of the three hardware wallets in the guide so far, all but the Cobo Vault, which uses closed source Android code, is 100% open source.

Reproducible builds If firmware cannot be built from source reproducibly, then users are merely trusting that the binaries the software developers sign are actually derived from the correct source. Unless users build the firmware themselves, this is essentially the same tradeoff as just using closed source code. Note that developers working on the project needn't be malicious for issues to occur as their computers could be hacked.

Supply chain attacks It's impractical and/or impossible for users to verify the integrity of the hardware they're using to perform security-critical operations. For this reason, in my opinion there is a larger supply chain attack risk associated with Bitcoin-specific hardware than general-purpose hardware because it's such an obvious honeypot for attackers.

I think about supply chain risk on a spectrum going from lowest risk to highest risk from left to right... Bitcoin-specific hardware -> Wallets limited to one general purpose hardware -> General Purpose Hardware All commerical hardware wallets -> Specter-DIY -> Glacier Protocol, Electrum

With the latter category you start running into a separate issue of running a full operating system (with all its associated complexity) as opposed to just embedded device logic.

Nevertheless, what are your thoughts about adding Electrum 4.0 and Proof Wallet (my thin wrapper around the Bitcoin Core wallet, which requires more testing as of 2020-08-22) as two more offline signers in this guide?

Generating keys

Computers are deterministic by design so they need access to high quality entropy sources to be useful as Bitcoin wallets. For a hardware device like the Coldcard with a TRNG or a general purpose computer that can use /dev/random, generating 256 bits of entropy is really not a big problem at least in theory. I think the bigger issue with generating keys is with the last dimension: i.e. how can a user be sure that the code they're running is doing what it's supposed to as opposed to reading an entry from a rainbow table. Assuming the code is correct, however, one way entropy concerns can be mitigated is by mixing in user-supplied entropy as the Coldcard and Glacier Protocol do with dice or, less ideally, adding a strong BIP39 passphrase.

Registering multisig quorum

Each offline wallet needs to know about its cosigners' account extended public keys for the quorum to be secure. A clever process users can perform to ensure the quorum is in full consensus is to check the first receiving address on each offline device. This guarantees two things:

1) each offline device is attesting to its own xprv -> xpub 2) if all N devices agree on the first receive address then the quorum must be in consensus because the first address is a determinisic function of M and the N xpubs

With the assumption that at least M of N devices is trustworthy across all other dimensions, this is a guarantee that your multisig quorum is composed of only your xpubs and not an attacker's.

Secure receiving

You touch upon this in the guide already: with the assumption that the hardware wallets are trustworthy, users must verify a receive address on at least M devices for a receipt to be secure.

Secure sending

The two potential footguns I can think of with sending bitcoins securely are... 1) Change address verification. Is the offline signer sufficiently restrictive in the change paths it permits users to spend bitcoins to? Or is simply displaying the change paths to users sufficient? Personally, I think hardware wallets should be extremely conservative about this. 2) Segwit bug. What safeguards do the offline signers employ to prevent the Segwit exploit Salim Rashid discovered? The most conservative option is to fall back to the PSBT_IN_NON_WITNESS_UTXO field; Coldcard took an alternative approach by caching previously signed transactions.

Will probably think of some more stuff, but I'll just leave it here for now...

mflaxman commented 4 years ago

Sorry for the delay, I've been trying to get as far along as I can before people notice my guide is out there.

Thanks for the feedback!

There's a ton in here (might make more sense as separate github issues?) but to respond to a few Qs / actionable parts.

Re reproducible builds, would you like to you quote to https://btcguide.github.io/known-issues/cobo? I'm happy to do it for you, but didn't want to steal your git commit stats:

If firmware cannot be built from source reproducibly, then users are merely trusting that the binaries the software developers sign are actually derived from the correct source. Unless users build the firmware themselves, this is essentially the same tradeoff as just using closed source code. Note that developers working on the project needn't be malicious for issues to occur as their computers could be hacked.

Re proof-wallet, for now my goal is to make multisig as streamlined as possible for mainstream adoption, so unfortunately this means GUI-only (no CLI). I'm happy to add an experts-only area and include it there.

Re TRNG, I think solutions like seedpicker are actually by far the best from both a security and usability perspective. I think HW wallets have been focused on dice because people have an intuitive understanding of it, but the UX is worse and it is less secure (harder to verify). It's not the most important thing though, and more wallets will add 24th-word checksums in the future. Again, my focus is on mainstream adoption of imperfect multisig as it's still massively more secure (and can be improved over time).

I have open-source code in electrum/python, seedpicker is adding root fingerprint support, and I have unreleased code in golang that's blocked by a PR that I want to release soon. Users should be able to perform this step easily and verifiably reproduce the result, which is awesome!

hodlwave commented 4 years ago

Hi Michael,

Thanks for the feedback!

There's a ton in here (might make more sense as separate github issues?) but to respond to a few Qs / actionable parts.

Thank you! Agreed, separate issue would make more sense, but I don't want to overload you with issues at this early stage, so will add more as the project progreses.

Re reproducible builds: I think this quote would not only apply to Cobo, but also to Coldcard because neither support reproducible builds; however, Coldcard is more verifiable because its firmware is fully open so users can at least compile it themselves. In any case, feel free to add the quote :)

Re proof-wallet: understood, not a problem! Once I get it to a production-ready state, I might take you up on the suggestion to add it to an experts-only area.

Re TRNG: I hadn't looked through your Paper Wallet section before opening this issue, but I really like the idea of generating 23 words of the seed so users can intutively understand where the randomness is coming from. Option B (HumanRNG Electrum Console) in particular is great for a few reasons:

I'm curious why you think choosing slips of paper out of a hat are superior in terms of UX and security. UX is somewhat subjective, but I think the process should be similarly verifiable if a guide such as this pdf from Bip39-diceware is employed.

mflaxman commented 4 years ago

Thanks, I added your note about reproducible builds in https://github.com/btcguide/btcguide.github.io/commit/3f6c650bae51ef75be1adf5f7aa6ffad7f7a400e. I'm going to close this issue now because it seems like the main actionable step, but if you want to file issues (or PRs!) for specific things please feel free. I appreciate you didn't want to overload, but FWIW I think it's less overload having 1 place to discuss/commit each specific issue (vs megathreads on many topics).

I'm curious why you think choosing slips of paper out of a hat are superior in terms of UX and security.

For a 24 word bip39 seed (23 words + checksum), that would be:

23x4 = 92 dice rolls
+
23x1 = 23 coin tosses
115 picks tied to human actions (consulting a table at each step)

It also took me a few minutes to follow what the guide was suggesting, and I'm the perfect target audience for this. I'd imagine most would struggle much harder. You also need 4 dice which is not expensive, but just one more barrier to getting started

The main reason to avoid simply picking the words out of a hat (23 picks vs 115 would be difficulty in getting the 2048 printed out words (perhaps because the cutting is a lot of work). Anyone can figure out how to pull 23 of them out of a hat. For example, people are already used to this with ping-pong balls when it comes to lotteries.

Another in-between linked to in the advanced section is to use seedpicker cutouts (see #3 for discussion/details), which only requires 342 raffle tickets + a dice. But again, you get more complexity to reduce your cutouts which are fundamentally very cheap (I imagine them being included for free as cutouts with most reputable hardware wallets in the future).

I'd be happy to add a link to a diceware like that in the advanced section, but that specific one seems problematic. It refers to the seed phrase as a passphrase, which is dangerously misleading (for example, my guide recommends passphrases only to expert users but all seeds by definition use seed phrases).