Decent breakdown. Good job.

8. You can usually export it more conveniently. 10-13 is overkill. Most wallets have some reasonable way to move txes between hardware wallet and online system (like SD card). They don't really compromise the practical security and are a much better UX.

3. checking if hardware really have no internet connectivity is indeed a thing. You could use Faraday Cage to be certain. Some wallets like ColdCard are translucent so you can inspect the components.

6. It is maximally secure to generate seed phrase manually using dices and paper lookup table. If you enter it into two wallets from two different vendors, you can see if they generate same addresses.

There's one attack you're missing: Hardware wallets could possibly slowly leak your private key by biasing bits in the signatures by grinding nonce. It would take whole lot of txes, but it is theoretically possible.

There's also possibility of someone just analyzing the electromagnetic waves during hw wallet signing txes to extra a key. Very very sophisticated and unlikely, but since we already have the tin foil hat on... just invest in Faraday Cage. :D

For maximum tin foil hat security, use multisig between two or more different devices (and/or parties), signing in different locations.

Edit: Oh. And since you're so into it it's worth mentioning that using seed passphrase is always a good idea!

> There's one attack you're missing: Hardware wallets could possibly slowly leak your private key by biasing bits in the signatures by grinding nonce. It would take whole lot of txes, but it is theoretically possible.

That's really cool. I had never thought of that.

All these points make me think that the best way is ditching the hardware wallet, and creating your own hardware wallet on a generic, airgapped PC where you write your own software (you always hear don't roll your own crypto, but in these case where you don't have to worry about side channel attacks, and you would do the random generation with dice, it should be fine).

In such case you're only relying on lets say, Intel, an airgapped generic Linux, GCC and maybe something else. But all these are things that would be extremely hard to modify in a way to affect your custom written software on an airgapped PC.

Plus the incentives to do some sophisticated but funny business on a commercial Hardware Wallet is quite high. While adding such sophisticated attack to GCC or Intel chips somehow would be extremely unlikely.

Add to this multisig with other methods, and the probability of some technical attack is so unlikely compared to a rubberhose attack, that it might as well be 0.

It turned out that the hardware wallet does not sign the whole transaction data but only a hash of it. So it cannot change the nonce.

But it is even worse:

The act of signing the hash is not deterministic:

https://medium.com/@simonwarta/signature-determinism-for-blo...

So it seems that:

    1: Every hardware wallet can phone home
    2: There is nothing that can be done about it

8: Using an SD card seems to completely throw the trustlessness regarding the hardware wallet out of the window? How do you know it does not write your seed phrase to the SD?

The "leak via grinding nonce" seems scary. That means signing a transaction is not a deterministic process? The same transaction can be signed in multiple ways?

> How do you know it does not write your seed phrase to the SD?

What's the point of an attack that writes the seed to the SD card that you are holding in your hand and can possibly easily notice that something was written there and attacker has no access to it? Sure, it's theoretically possible but it's such a ineffective approach that it's highly, highly unlikely.

The hardware wallet using power consumption modulation to generate signal with electromagnetic waves that leak your private keys is far easier, stealthier and effective. With sophisticated equipment it could be detected from quite far away.

So I would worry about getting a Faraday's Cage, before bothering with not using SD card. :)

> That means signing a transaction is not a deterministic process

Indeed. Signing with secp256k1 consist of signer picking an arbitrary nonce. I'm not sure if that's the case with Schnorr Signatures that are used for Taproot addresses.

There is no way you can check if additional data was written to the SD.

It can be hidden in file creation times, file modification times, file access times, file permissions and infinite other parameters of the file system. You can probably write a file to a arbitrarily chosen position on the block device and have it stil be a valid filesystem. So the position becomes the message.

The attacker has access to it if he in some way runs software on your computer. That might be the software wallet you use or some other code that got onto your machine.

"picking an arbitrary nonce" - that seems to be the biggest problem so far. So even an air gapped wallet can send out data to the world. Every bit it can send out halves the security of your seed phrase. So a tiny amount of data will quickly make it brute forceable.

That's true, but again - it requires hacking the online computer AND malicious device.

I guess one could use some offline machine to copy over only the file with the signed tx to be certain. :D

> Every bit it can send out halves the security of your seed phrase.

The device still needs to produce valid signatures in a reasonable time, so practically it can only leak handful of bits at the time.

> "picking an arbitrary nonce"

Yet, it's just random bytes. You could generate that with dice, and customize the wallet to take it as user input.

Assuming the hardware wallet isn't following convention and impliments RFC 6979 (a huge red flag) that is. At that point the hardware wallet can be considered to do all kinds of messed up stuff - what about a wallet that deletes the private keys after X transactions?

This is actually a realistic failure mode - hardware wallets do fail even if rare.

(as others have noted multi-sig schemes may be a better option but here are a few infos regarding your questions)

> 1: Create a seed phrase with dices

You can do that but you'll need a way to generate the checksum for the seed phrase. A 24 words BIP39 seed contains 264 bits (24 x 11 bits): 256 bits for the seed and 8 bits for the checksum.

> There is not an easy way to check if the hardware wallet really has no internet connectivity.

Indeed but you can at least open / disassemble some of them easily (there are even docs by the manufacturers explaining how to verify that the hardware wallet's PCB looks legit).

Seed exfiltration, even without connectivity, is an issue too.

And some hardware wallets are extremely noisy and impossible to use totally offline (there are mandatory firmware upgrades and mandatory connectivity needed to install the "apps" that allow to sign transactions), so you have to trust the vendor.

> There is no way to check if the hardware wallet really uses the seed phrase to create the extended public key.

Yes there is. Use an airgapped/offline computer which has physically no network connectivity options (no wifi / no ethernet / no bluetooth / no nothing), no HDD, booted from, say, a live Linux CD with contains for example Ian Coleman's BIP39 tools. Then you enter your seed and verify that the extended public key / keys derived is the same as the one shown by your hardware wallet. Data exfiltration from such a computer is still technically possible but I wouldn't worry too much about it: you power that computer for a few minutes, turn it off, and you'll be fine.

> You can do that but you'll need a way to generate the checksum for the seed phrase. A 24 words BIP39 seed contains 264 bits (24 x 11 bits): 256 bits for the seed and 8 bits for the checksum.

In theory, you could pick 23 words at random with 11 * 23 coin flips, every 11 flips representing an index in the dictionary. Now to find which 24th word passes the checksum, you could guess it in at most 2048 attempts on your hardware wallet :)

More realistically, it might be possible to develop a Ledger app that, given 23 words, finds the "checksum-passing" 24th word for you.

> More realistically, it might be possible to develop a Ledger app that, given 23 words, finds the checksum passing 24th word for you.

Ah that's an interesting thought: I don't know about other hardware wallets but indeed the Ledger allows anyone to develop "nano apps" and it doesn't seem crazy to write one that'd compute the checksum after you gave it the 23 words you got throwing dice (well, 23 words + the three first bits of the 24th word really).

Maybe it even already exists?

I couldn't find one. I'm tempted to give it a shot. I will comment here if I succeed :)

Yes, once you have 23 words, there is a finite set of possible words that can be used as the 24th to make checksum valid, and you could pick one at random.

But as I understand the private key can be any number, so you do not need to even use the seed phrase technique to create a private key, or if you do it isn’t required that it has a valid checksum in order to operate on the network.

That's true but I think the idea was to generate a passphrase that can subsequently be entered into a hardware wallet. And most hardware wallets only support entering seed phrases with a valid checksum.

> no HDD, booted from, say, a live Linux CD

I so wish there was a USB stick on the market where you can toggle read-only mode with a physical switch. (And where you had reasonable confidence that the firmware is hard to attack, I guess.)

Instead of a hardware wallet you could buy or build an airgapped PC with no wireless hardware.

Of course it’s possible to exfiltrate data even without dedicated wireless hardware (TEMPEST etc) so I guess build a faraday cage if you’re really paranoid.

Also: https://glacierprotocol.org/

Mostly agree with your steps except that to sign a transaction, you need all of its data, not just the hash. So it would be impractical to manually type it in a hardware wallet (also, most hardware wallets don't have a keyboard).

Hardware wallets like Ledger instead connect directly to a computer via USB to receive/transmit transactions to sign. They also transmit the extended public key to the wallet software so you don't have to type it manually. You have to trust the hardware wallet vendor to some degree.

Regarding, your comment on number 6, that's an interesting thought that I hadn't considered. Since you are not supposed to enter your seed on a computer, there really isn't any way to verify that the hardware wallet is really using the seed you provided and not some seed that can be predicted by the hardware manufacturer. I guess you could enter it on a hardware wallet from a different vendor, or on an air-gapped computer[0], and see if it matches.

[0] Make sure that the computer is never connected to the Internet again in case there was a key logger running and waiting for Internet connectivity.

Wow, the signing of a transaction needs the whole transaction, not just a hash?

I thought there are air gapped hardware wallets?

Without a keyboard, how do you enter your seed phrase?

Connecting the hardware wallet to the computer brings up a bunch of complex security questions.

> Wow, the signing of a transaction needs the whole transaction, not just a hash?

You sign the hash; but you need the entire transaction to verify it does what you want (send funds to the expected addresses).

Ah, you are right. The transaction data is just required to display what is to be signed in a human-readable format. This lets the user decide whether it wants to proceed with the signature or not. Otherwise, some malware could intercept transaction signature requests and replace them with arbitrary data (e.g. a transaction that empties the user's wallet). That's also why manually typing a hash in an air-gapped computer/device isn't going to work, you need the full transaction data.

Aha! That changes everything again!

You can create the transaction hash on as many untrusted machines as you like. To make sure the hash represents the correct transaction.

Then you can enter only the hash into the hardware wallet.

That solves the problem of how to operate an air gapped hardware wallet!

I think this also does away with the "wallet publishes your seed via nonces" problem? I would hope signing the transaction hash is deterministic?

When you type the signature on your computer, how do you know you are not unknowingly transmitting your seed? If your hardware wallet is malicious the "signature" it displays could be your seed instead of an actual signature.

> I would hope signing the transaction hash is deterministic?

Not really. A signer can generate an arbitrary number of valid signatures for the same message, using the same private key because the signature algorithm requires a secret random number. There are ways to generate the signature deterministically by deriving that secret random number from the private key but AFAIK, the only way to verify this was actually done requires knowing the private key in the first place.

I believe you a malicious signer could iterate through valid signatures until the first n bits correspond to bits it wants to leak.

That's actually an even bigger problem that I hadn't considered before.

https://medium.com/@simonwarta/signature-determinism-for-blo...

You can check that the signature signs the transaction on an air gapped computer.

That signing the transaction is not deterministic but involves a "random" number is indeed huge.

Now we are back to square one. The hardware wallet can phone home. No way to use Bitcoin in a trustless way.

This is not true, or at least a huge red flag for a client implimentation. Bitcoin the network cannot tell the difference, but by convention clients should use RFC 6979.

In theory, you can compute the signature using a pen and paper. Or you can build a computer from first principles and then program it. In both cases, it would take a long, long time.

> I thought there are air gapped hardware wallets?

I had to Google that and they do indeed exist. It seems they use QR codes to send and receive data. It's probably a step up from USB since you can visually inspect how much data is transferred. But then again, the device could theoretically transmit your seed to your computer camera and you might not even notice[0]. Probably a step up from USB in terms of security but at the cost of some convenience.

> Without a keyboard, how do you enter your seed phrase?

They have a very rudimentary virtual keyboard which takes forever to type.

[0] As part of the QR code itself, as a separate QR code that flashes too quickly to be noticed to the naked eye, encoded as slight pixel brightness variations within the QR code itself, etc. It could even exfiltrate the seed one bit at a time which would make it pretty much impossible to detect (but would take ~256 transactions to complete).

QR codes seem like a terrible choice to transfer data in a trustless way.

There are infinite ways to hide data in them.

Bingo. It would be interesting if there was a sort of generic touchscreen device that acted as a USB firewall. It would prompt you and display the data before allowing it to go through. But even if such a device existed, how would you tell whether a transaction signature is really a signature of your transaction and not some encoding of your seed? It seems that no matter how you look at it, there will always be some level of trust involved[0].

For maximum security, the best would probably be to use an airgaped/secured/encrypted general-purpose computer and use a SD card to transmit transaction data. You could even use pre-bitcoin computer hardware if you are super paranoid.

Also, if I recall correctly, there are fully open source hardware wallets like Trezor. In theory, you could review the firmware and flash it yourself. You then just need to trust the hardware isn't backdoored to steal Bitcoin seeds. But that would require some rather large companies like ARM to get in the Bitcoin seed stealing business (and for your computer to be infected by ARM-developed seed stealing malware).

[0] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

QR can have ECC turned off so there can't be any hidden information. Of course, it makes it more susceptible to errors.

Air gapped wallets can utilize QR codes to sign transactions. Look into PSBTs (partially signed bitcoin transactions).

Gist is you can create a transaction from any device that doesn’t have your private key … send that transaction via a QR code to your cold wallet, then your cold wallet can sign transaction and create a new QR code for the other device to use.

You can't. You have to live with the fact that there's some amount of risk and weigh whether it's an acceptable level compared to what you're securing. See Reflections on Trusting Trust for the canonical example.

Even though the terms are related, I did not talk about "risk" but about "trust".

If you think there is no way around trusting some party, then please name which party that would be. And why one cannot use Bitcoin without trusting them.

Considering collectively all your comments here, the answer for you, personally, is simple: DON'T USE BITCOIN. It cannot provide the impossible level of perfection and assurance that you seem to be striving for. This what both GP above, and I have told you already

Just use traditional finance and traditional banks. Because then at least you will have more hope of getting transactions reversed if you get scammed by any of the elaborate and unlikely device subversion or middlemanning methods that Bitcoin transactions are also susceptible to (those methods that you've alluded to already here)

> Just use traditional finance and traditional banks.

That's a very first world centrist view. In my country the banks/government have outright stolen people's money in the past[1]. Most people don't trust the banks here, with good reason. When you put your money in the banks, you are trusting the "system" with your money.

And for shitty countries, something like Bitcoin is more trustworthy than the banking system.

[1] https://en.wikipedia.org/wiki/Corral%C3%B3n

Bitcoin was designed with a specific trust model in mind.

The most well known point of trust in 51% attacks. Lesser known is bitcoin master nodes. Even lesser realised is the trust that your client is connected to the broader bitcoin network (and not segregated somehow). This also assumes trust in your client, which can also perform all kind of attacks (such as not reusing R values: https://bitcointalk.org/index.php?topic=581411.0)

There's no such thing as no trust, only different threat models. I'd reccomend reading https://www.threatmodelingmanifesto.org/

I think you can't. You're right about 3 and 6, which are the same basic issue of needing to trust the vendor, their hardware suppliers, their employees, and the delivery chain to you. (You can be more secure, but you can't be totally secure)

Or, for example, what if all your communications and actions are being monitored continuously by state-level actors with cameras and hidden bugs, recording every keystroke? Or what if we are living in a simulation, and the malicious operators can extract data from your brain, or just alter reality at will?

But I think you can provide a "practical" level of trustless. That means that, if your adversary was powerful enough to steal your Bitcoins, then they'd be so powerful that they could destroy you in many other ways. So it's a moot point.

A practical solution to your question could be to take all the precautions you've said above, and then simply gradually increase the amounts you are transacting, using a variety of methods, and see if anything gets stolen.

Call it a bribe or a bug bounty or a tax. It's quite effective, because organizations are comprised of individuals, who are subject to human temptations. At least two federal agents independently stole funds from the Silk Road marketplace while investigating it, and they were imprisoned later

I don't think the bug bounty approach helps.

Say an attacker compromised a certain batch of Ledger wallets.

They might very well wait for a few years before they reap coins of the wallets. Because as soon as they do it for the first time, there will be an uproar and people will analyze whats up and transfer their funds to other wallets.

Think about that situation from the attacker's POV. They have invested extensive resources, but they still haven't got anything.

What if they're not the only one who compromised the insecure wallets? If they could do it, then probably someone else also could, and that other hacker could empty all the wallets first.

Meanwhile, users like you will be occasionally moving their Bitcoins around, sometimes to wallets that the attacker cannot access.

If an attacker just wants to make money, they're unlikely to wait for years to exploit an old vulnerability.

In the real world, most security vulnerabilities get exploited quickly, because they are very likely to lose value as time passes. You can find numerous real examples of this attitude, such as weak brain wallet keys which are exploited in seconds, instead of waiting and hoping that more money will accumulate in the address before someone else steals it

And, like I suggested already, a practical best case solution for the paranoid is diversifying your assets and security methods, so you can identify vulnerability sources early and be unlikely to lose everything

Edit : Bottom line though is that you cannot use Bitcoin in totally trustless way, I think. Nothing in security or in real life is totally trustless. So do your best to employ reasonable precautions and mitigations and then get on with your life

If you're willing to accept that an individual MOSFET won't be bugged, build your own hardware from individual transistors to do all the necessary cryptographic steps. Run it on a battery supply to avoid power line information leakage[0]. Run the hardware inside a Faraday cage to avoid RF information leakage.

[0]: using a lead acid battery so you can disassemble it and verify it isn't bugged.

And then, of course, you simply have to rewrite the entire software stack.

You've missed step 0 (and earlier): how did you trustlessly obtain the bitcoin in the first place? Your options aren't good here:

a) Buy it on an exchange: You need to trust that the exchange won't just run off with/sell your real money/credit card details (but at least in the real world you have a chance of clawing back stolen cash)

b) Buy it via a service like localbitcoins, where you meet a stranger in an alley and hand them hard cash. Not very trustless!

c) Mine the coins yourself. But unless you build a bitcoin miner from scratch, you need to trust the hardware and software (how do you know for sure that it isn't mining to someone else's account?) And your miner needs to be connected to the internet, so hackers could get your coins.

There are no good trustless options. You have to accept some risk.

EDIT: I missed the only tried and true trustless way to get bitcoins:

d) Hack/phish/con someone else out of their bitcoins!

Why is this relevant? It doesn’t matter how OP obtained their bitcoins — trustlessly or not — what matters is that OP now has them and want to keep them without trusting a hardware wallet company.

> You've missed step 0 (and earlier): how did you trustlessly obtain the bitcoin in the first place? Your options aren't good here:

You're missing an easy and obvious option.

You plan to buy 10 Bitcoin (not saying it's a good idea): you wire tx enough to buy one on Gemini or Coinbase (or whatever exchange fits you), wait for the tx to clear, buy one Bitcoin, move it to your hardware wallet. Rinse and repeat 9 more times.

At any one time you're never exposed to more than 1/10th of the amount you planned to buy.

I think a lot of highly speculative investors but still cautious people proceeded that way.

There are even sites tracking the Bitcoin and Ethereum and whatnots addresses accumulating coins on a regular basis.

Huh? This doesn't solve the original problem at all, and only results in larger tx fee losses.

This is the world outside of Bitcoin, and is irrelevant to this question. For these transactions, you have faith in your legal system, government, democracy etc. If you're scammed by an exchange, you sue them and you should get your money back.

With a typical currency the answer of "how to get money" is to get a job. Trustless usually isn't a concern, in that paychecks are reliable and worker protection laws exist. (Not saying it's perfect, just stating the status quo). The lack of a bitcoin economy prevents or frustrates this approach.

With typical currencies, you can exchange at a currency exchange counter at the border/airport or use your bank/credit card which handles the conversion behind the scenes. I suppose the equivalent for bitcoin is a bitcoin ATM or bitcoin credit card.

With typical currency a central bank can arbitrarily inflate (read as dilute) the purchasing power of your savings and there is nothing you can do to prevent it.

You can obtain them via as many small transactions as you like. Never trusting anyone with more than the transaction amount.

That minimizes risk, but trust is still involved.

Where is the risk with a? Seems like you yourself explain why it would work fine. If you get the coins, great. If not, you do a classic charge back.

Either way, trust of everything outside of owning your coins is irrelevant to the exercise. If you're going to play devil's advocate, you need to come up with relevant counter examples.

And the reverse is even more important: having spent immense time and effort to acquire the output of a random number generator, how can you ensure it preserves its value when you want to actually exchange it for something? Given the 2/3 fall from the peak against the stabledollar this is a real risk.

This is an irrelevant tangent in this case, the question is about using bitcoin in a trustless way.

Bisq - P2P trading, pay by cash deposit into a strangers bank account

The solution is to replace the hardware wallet with a Raspberry Pi, or similar hardware device, and use open source wallet software. However you need to be able to disable the Wi-Fi of the hardware device so that the device that holds the keys is offline.

Check out https://seedsigner.com/ which does precisely this.

If the threat model includes side channel and supply chain attacks then something like the Precursor would be a better bet because you still need a rusted input method and screen.

If your threat model includes side channel and supply chain attacks then you're pretty much fucked in modern society. Might as well just use cash or attempt to self sustain a cabin in the woods.

> the Precursor

What’s this?

Background: https://media.ccc.de/v/36c3-10690-open_source_is_insufficien...

Purchase: https://www.crowdsupply.com/sutajio-kosagi/precursor

You’ll need to first discover if you can trust yourself. Make sure you don’t sleepwalk, test your susceptibility to hypnotic suggestion, and talk to a medical professional you trust about other possible health conditions that could jeopardize your assets. Unfortunately, there are few cryptographically verifiable medical professionals.

Step 1 is going to be figure out what you are prepared to trust and work upwards from there.

There will always be an infinitely recursive list of trust issues or potential attack vectors, they will just become less and less likely.

What if the hardware wallet is backdoored? Use a Faraday cage. What if both the hardware wallet and Faraday cage is compromised? etc.

There is still some trust hidden away in step 10 that you didn't call out, which is that you're trusting the software wallet. The software wallet that you use to create the transaction could under the hood create a different transaction than what you expect and show you the hash of that transaction. A hardware wallet that signs a raw hash will always be vulnerable to this kind of attack. To really eliminate the need to trust the software wallet, you should send the whole transaction to the hardware wallet so the hardware wallet can calculate the hash. You're still trusting the hardware wallet to some extent but you entered your seed phrase into the hardware wallet so you're implicitly trusting that no matter what.

This method is still vulnerable to rubber hose cryptanalysis - which is what I'd worry about.

Everything that is non-verifiable, requires trust. So, if you can verify that your hardware works correctly, you don't need to trust the manufacturer or supply chains. There are ways to verify that hardware works correctly.

3: You measure RF signals to verify that there's no wireless connection of any kind.

6: You can verify the public key by using multiple devices from different vendors with the same seed.

Practically speaking, you don't need to verify everything yourself. It's guaranteed that any information about attacks will be quickly available, if someone is able to verify everything.

Your hardware might either leak the private key via a non-internet connection (bluetooth, nfc, physical interface, some non-standard protocol). Also, it might use weak crypto to generate the private key (see ROCA vulnerability). Trusting non-trivial hardware is hard as it takes very little to have it behave maliciously under very specific circumstance.

Download green wallet by blockstream and call it a day. Make sure to close all other apps before opening it. Write your seed phrase down and give it to your Mom.

Instead of trying to eliminate trust, a better approach would be to decentralize trust.

There are various solutions for that, e.g. multi-sig, Shamir's Secret Sharing, etc.

if you don't fully trust your hardware wallet, you could try multisig with multiple wallets of different vendors. also see BLS signatures.

Ethereum is much better in these scenarios.

Regarding 7-10: any recommendations for good software wallets?

1. How can you know for sure that the dice are not rigged?

It's recommended to test dice used for fairness. Also - they would have to be really, really rigged to weaken the security in any meaningful way.

The same way that you can trust that we aren't brains in vats. At some point you have to have some trust.

You can use casino grade dice which are translucent specifically for this reason. And on top of that you can also test them yourself to verify.

runinga vm linux distro with a wallet that connects to internet would probably make it less or the same degree of trustlessness while being more practical

And yes you must still trust Coinomi, Apple, TSMC, certificate signing entities, etc..

To be totally sure you could do all the math on a piece of paper and send crypto to the public key you generated by hand.

brain wallet + coinb.in offline. you're welcome

you buy monero

> you buy monero

You realize you could s/bitcoin/monero/ and OP would pretty much have the same relevance right?

You don’t.