Comment by Genbox | Hacker News Reader

Comment by Genbox | Hacker News Reader

Parent Full thread

"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.

Reply on news.ycombinator.com