Hacker News Reader

Comment by JonathanBeuys | Hacker News Reader

Writing your own code is not what my post is about.

It is about the fact that even air gapped hardware wallets can phone home.

You've missed the point entirely. Your post is claiming one cannot use BTC in a "trustless" way. The GP is saying "You have to either choose to trust a third party at some point, or go to these extreme lengths that still don't ensure your security unless your opsec is 100% perfect, every time."

OTOH, your post also doesn't prove that the mass-manufactured hardware in question is actually malicious. At best, you've shown a way that it could be. Show me an actually malicious hardware wallet that behaves as you've described, and you'll have made your point. Until then, all you have is speculation and improbabilities.

In other words, charitably interpreted, you've shown that the hardware equivalent of the C compiler in "Reflections on Trusting Trust" could exist, just as the paper itself showed that such a C compiler could exist[0]. That is all. There is no evidence either one exists at all in the wild.

---

[0]: Which, I'll admit, is a pretty cool thought exercise, but has precisely zero real world impact.

> Show me an actually malicious hardware wallet that becaves as you've described, and you'll have made your point.

I'm not the OP and although I agree with you, you may be interested in the corollary for a "stronger" attack than OP defined:

https://bitcointalk.org/index.php?topic=581411.0 and https://github.com/tintinweb/ecdsa-private-key-recovery

Constructing such an airgapped hardware wallet is as trivial as a raspberry pi running a patched bitcoin client. In my opinion the more realistic construction than a that of "Reflections in Trusting Trust".

He just showed that Bitcoin is not mathematically secure.

In fact someone should prove that mathematically secure is a meaningless concept, if your devices are not physically secure.

That's also not true. What was shown is that BTC is not secure if you don't follow the correct transaction protocol. That's obvious. So is it also obvious that mathematical security and physical security are different. Here, the attack also involves not following the correct protocol.

Why do you think that was even worth posting? It's not a profound concept to say "if you don't follow the secure transaction protocol, your transaction will not be secure."

What do you mean “phone home”?

Posting a signature on a public ledger does not give information about nonce k which I think is what you are referring to. Each time a new transaction is signed, the k value will be a new random big integer.

If your wallet is able to leak bits in this way it would imply the value k is not chosen uniformly randomly. This is my understanding of ECDSA at least.

"phone home" is not really the right way to describe it. The attack proposed is that a hardware wallet (being a black box) can give the hardware wallet developers information about the private key.

Note that I have very little understanding of blockchain crypto, so I am unable to confirm/deny the information OP gave. However, the way I understand the attack is:

Hardware wallet generates a private key. It keeps this key in internal storage. When a transaction is made, the wallet makes a signature. According to OP, there is a variable here (I'm guessing either multiple private keys, or the ability to choose a signature algorithm, or even embedding a timestamp in the transaction) which the hardware wallet can use to "leak" information.

Let's say the wallet decides to embed a timestamp. Whenever a bit in the private key is 0, the timestamp is even, and when a bit is 1, the timestamp is uneven.

After 4096 transactions, presumably the whole private key is now stored in the blockchain as even/uneven timestamps.

This is of course a very slow way of leaking the private key, but does illustrate the problem of having unverified devices be responsible for crypto results.

But this comes down to “trusting a compromised device is bad.” The device could steal your funds from the moment you send your first transaction (it could only generate a set of known private keys).

Assuming the mode of key signing is not compromised and is producing robust uniform randomness (whether it’s a hardware wallet, airgapped device or your own hand-rolled code) it shouldn’t leak anything per transaction that would lead to your private key being more easily discoverable.

The point of such an airgapped device is that you can validate its outputs to make sure that it is not using your private key to do shady stuff.

OP's post is that since signatures are not deterministic you have no way to inspect device output and make sure that nothing subvert is going on.

Obviously you should not trust compromised devices, but you cannot know if such a device is compromised.

A “wallet” is just a series of math operations over standard cryptographic primitives. An airgapped device can be a calculator and pencil, or software that you have programmed and verified yourself in Python[1] or another language. At some point you need to trust that your tools and environment aren’t compromised; but this is a different argument than suggesting that the ‘k’ nonce in ECDSA is the only thing keeping Bitcoin from being able to be used trustlessly.

[1] http://karpathy.github.io/2021/06/21/blockchain/

My point was different; you can compute a hash (or any other deterministic computation) trustlessly by having multiple independent parties compute it separately and then checking if the result is the same.

You cannot necessarily do the same for nondeterministic computations in general. In this case you can easily verify that the signature is valid, but unless you control the rando parameters you cannot verify that a few bits of entropy have been exfiltrated by one or more parties in the computation.

In the simplest case you could with statistical methods but not with slightly more sophisticated attacks.

k is chosen by the wallet. You don't know if it was chosen randomly. A malicious wallet would chose k so that it results in a signal. For example it could chose k so that the sum of the bits in the signature are odd or even. That would signal one bit.

If your example is OK with a dice roll to generate a random mnemonic, i.e. it is uniformly random enough for your scenario, then you can do the same to generate random parameter k so that the wallet is not doing it for you.

You can also code your own wallet like I mentioned before if you do not trust a hardware wallet manufacturer, but somewhere along the line you will probably need to trust something (like trusting the room you are doing this in is not bugged).

Reply on news.ycombinator.com