Tell HN: It looks like even air gapped Bitcoin hardware wallets can phone home
This is the good ol&#x27; Trusted System issue. I&#x27;ve roamed in this area before, both in terms of creating a chain of trust in crypto systems and also at a more philosophical context for voting systems. I&#x27;ll decompose the issue into more abstract questions:<p>&gt; Can we ever trust any system?<p>Yes, to an extent. There is no such thing as a system that can be trusted completely, but we don&#x27;t need it to be in 99% of cases. One might say &quot;you can trust crypto primitive XYZ. If you use it, it would take 1 billion years to break&quot;. That might be true, but side-channel attacks, leaks, statistical biases and whatnot will always be an issue.<p>To get as close as possible to trust in a system, it needs to be formally verified with proofs. That&#x27;s the best we can do program&#x2F;algorithm wise, but even if we trust the program, it cannot trust the system it resides on.<p>&gt; How can we achieve trust then?<p>You know how bitcoin is based on a distributed consensus algorithm? It protects the whole system from collapsing due to a bad actor in the system. Even if thousands of people decides to cheat, it won&#x27;t have any considerable effect.<p>Let&#x27;s say you buy a hardware wallet from a reputable vendor - if they decide to cheat, you will be at their mercy. To combat this, you need a way to verify that what it does, it does so correctly, but also without side effects.<p>This is again something that needs to be formally verified. Any deviation from the spec will stand out like a sore thumb. To achieve this, we need to introduce a verifier.<p>The verifiers job is to check if the hardware wallet did it&#x27;s job, but without being in the possession of the private key. There are lots of ways to do this, but a hot topic today is zero knowledge proofs, where the wallet would need to stand up to scrutiny.<p>The verifier would also need to check the results on the blockchain. Not just that the result generated is correct, but also that it is without side-effects.<p>&gt; But then we have to trust the verifier!<p>Yep, and each time we introduce a verifier for the verifier, we will have made the system more trusted. Let&#x27;s say we have N verifiers, whos best interest is that your wallet did the right thing.<p>In a transaction, it is not only in _your_ best interest that the transaction is correct (and without side-effects), but also the other party. We can extend this system to be a small group of people in _any_ transaction. If a small group of verifiers all agree with a certain level of consensus, then we can trust the system beyond a reasonable doubt.<p>This might sounds familiar to those who work with blockchains - and you would be right. It is eerily similar to how it works today. However, the blockchain covers only the cryptographic guarantees. The system needs to be extended to cover formal verification of the system as well.<p>&gt; Example<p>Formal verification is a mostly academic exercise for most, so I&#x27;ll give a small example for those of you who are unfamiliar with it.<p>Let&#x27;s say person A and B make a transaction. Both have super secure hardware wallets and the crypto used it state-of-the-art. It should be secure right?<p>We can review the code of the system, but it is hard to identify mistakes. Who knows, maybe there will be a new area of vulnerabilities in a few years, and we never saw it coming.<p>Within the area of &quot;correctness&quot;, we first need to make a formal specification. We create some testable properties about the system that needs to hold true, no matter the transaction or who is involved (these are called invariants).<p>So person A transfers 1 bitcoin to person B, they do so by signing a nonce with a private key. Person A checks the nonce and ensures it is indeed random (test 1). The signature is sent to person B, which then tests if the signature is no different than random data (test 2).<p>Howe test 1 and 2 are performed are incredibly important and very difficult to do, but not impossible.<p>If test 1 or 2 happens to be non-random, then we can just reject the transaction. We don&#x27;t know if it was non-random by chance or on purpose, but since it does not live up to our criteria, we will reject it.<p>This means Person A will check what they got from person B and vice versa. However, why not have a bunch of random people participating in the block chain do the same checks?<p>If 0.1% of all in people in the blockchain checks the transaction between person A and B, and they all have a say if the transaction gets rejected, then we can trust the system beyond a reasonable doubt.<p>And no, this system is not perfect. We don&#x27;t need it to be. We need it to be good enough so it becomes incredible hard to cheat. Also note that I&#x27;ve omitted a lot of details for brevity as well.