When we talk about self-custody and protecting our bitcoins, we understand that the seed used to generate our private keys must be completely isolated and stored securely. The best-known solutions on the market for solving this problem are hardware/cold wallets.
These impenetrable fortresses seem perfect for this task. Isolated from the internet, protected by passwords to prevent unauthorized access, equipped with secure chips to resist physical attacks, and designed to prevent any kind of information leak. After all, the operations they perform are critical when it comes to cryptocurrency management.
It seems impossible to attack these devices if access is completely restricted. But… what if, just like Agamemnon’s army infiltrated Troy with the famous wooden horse, an attacker managed to gain access to the hardware wallet without the user’s knowledge?
The Dark Skippy case
A few years ago, Lloyd Fournier, Nick Farrow, and Robin Linus discovered a vulnerability affecting probabilistic signing devices that allows private keys to be ex-filtrated secretly through the signatures they generate. This discovery was named Dark Skippy and exploits the random value in the signature, which in principle should be generated deterministically (RFC 6979), by embedding secret information known only to the attacker within the signature.
The attack they demonstrated is a covert channel attack using the nonce of probabilistic signatures. By modifying the device’s firmware, it is possible to alter the way signatures are generated in order to produce a predictable “random” value derived from a seed. When a transaction is made on a public network, e.g., the blockchain, the attacker can identify the transaction and, with some effort, recover the ex-filtrated critical data.
Figure 1. Graphic representation of Dark Skippy disclosure
Some of you might be thinking, “Domènec, there’s an inconsistency here, you told us that hardware wallets are isolated, password‑protected and very secure; how could anyone modify the device firmware?” You’re right, these attacks are genuinely difficult to carry out. Still, extremely sophisticated methods exist that can succeed.
For example, imagine a classic supply‑chain attack: a factory produces thousands upon thousands of these devices. One day the company executives do the math and realise the value stored on their devices is worth several times the firm’s annual profit. They hear about these kinds of attacks and decide to go ahead. They modify the firmware, ship out malicious devices, and wait for months. Time passes and users begin making transactions meanwhile the “attackers” monitor the blockchain. Gradually they recover seeds, and eventually they decide they have enough. Once they have the private keys they start moving users funds. At this point, Alice, who bought one of the company’s devices a few months earlier, checks her hot wallet and sees transactions she did not author, notices funds moving to unknown addresses, and discovers her wallet is completely empty. Naturally, she panics.
As the previous example shows, Alice made only a couple of transactions with the compromised device and did not realise she’d been attacked until it was too late. That’s because these attacks are very hard to detect, the device continues to function correctly and produces signatures that look valid and secure to everyone except the attacker. Who, by dealing with the discrete‑log problem, can recover parts of the seed.
A proposed solution: Anti‑Exfil
Not everything is hopeless. Andrew Poelstra and Jonas Nick proposed a way to prevent the nonce generation from depending solely on the hardware wallet. Their proposal prevents this class of attacks by sharing secrets between the hot wallet and the cold wallet. Concretely, the scheme forces both participants to commit to shared secrets so that the signature’s randomness is partly derived from those secrets. That way, when a transaction is signed the hot wallet can verify that the nonce was generated correctly, and the user can be confident the hardware wallet produced the value honestly at random.
Figure 2. Diagram of the Anti‑Exfil protocol.
Today this solution is implemented by the Jade and BitBox wallets. Each implements its own Anti‑Exfil system, which unfortunately means the protocol can only be fully validated using the corresponding hot wallet provided by the same vendor.
However, the solution has a usability problem. As shown in Figure 2, the protocol is a two‑round exchange. In practice this is unnoticeable when the devices are physically connected by cable. Unfortunately, with air‑gapped devices you have no choice but to perform the operations twice (usually via QR codes) to complete the protocol.
Although effective, this approach is impractical for cable‑free devices. That leaves an open research question: is it possible to design a single‑round protocol? The Discrypt group will continue researching and testing new ideas until we find a solution that is both practical and secure.
Stay tuned, we might have some fresh news to share sooner rather than later!
