---

Mitigation

Existing Mitigation Techniques

Hardware Security Defences

The primary mitigation for malicious signer attacks is to prevent malevolent firmware from ever being loaded in the first place. Not all signing devices provide security features that inhibit loading of malicious firmware. These may include:

• Various hardware security techniques including secure boot and locked JTAG/SWD interfaces.
• Securing physical access to the device (secret places, personal safes, or maybe even tamper-evident bags (cumbersome)).
• Reproducible and vendor signed firmware builds.
• Various other security features offered by devices on the market.

Protocol-based Mitigations

1. Anti-exfil protocols - an anti-exfil protocol has been implemented in the secp256k1-zkp library. This works by having the software wallet securely add randomness to the signature so that the signing device cannot produce it on its own. This protocol has been adopted sparingly among Bitcoin signing devices in part due to the increased number of communication rounds which are undesirable within 'airgapped' signing workflows.
   
   Anti-exfil is currently only supported for ECDSA but efforts are being made to add similar functionality for Schnorr signing.
   
   Currently, the two systems that employ this strategy are:
   • Blockstream's Jade - when signing over USB cable alongside various wallet software.
   • ShiftCrypto's BitBox - when signing alongside any of their client libraries.

   At the moment this is for ECDSA only, but progress is being made towards a Schnorr anti-exfil protocol.

2. Deterministic nonces - Checking that the signing device uses a deterministic nonce stops all kinds of nonce covert channel attacks, and many devices produce deterministic signatures in accordance with RFC 6979.
   
   However, checking deterministic nonces on every signature is not only unwieldy (no one does this) but also potentially risky since it requires another device has access to the secret key.
   
   To verify a device is using deterministic signatures a user must sign on a second independent device and manually check that the signatures match. You also need to ensure that deterministic nonces are used with every signature, since a malicious signer could conditionally exfiltrate based on the transaction (e.g., on the Nth transaction).
   
   A sophisticated alternative is to use a protocol such as Purify from MuSig-DN, where signers provide a zero-knowledge proof that deterministic nonces have been used in signing.
   
   Many hardware devices form deterministic nonces following RFC6979.

Our Recommendation

The main goal of these recommendations is to come up with something that is compatible with PSBTs so they have a high chance of actually being used.

1. Nonce hash randomization - There is already an early proposal that would be compatible with a PSBT field and make Dark Skippy impossible (as well as predetermined nonce attacks). This is in the form of Scheme 2 in this excellent mailing list post by Pieter Wuille.
   
   Note this does not solve the nonce grinding attack since the attacker can still keep sampling the final public nonce with different choices of the internal nonce.
   
   Update 2024-08-20: Initially there was another idea here that wasn't as good as what the community had already come up with so we replaced it


2. Mandatory nonce "proof-of-work"- To make the 'nonce grinding attack' impractical, the software wallet can demand that the public nonce $R$ conforms to some random challenge like $SHA256(k || R)$ starts with x number of 0s where $k$ was randomly chosen by the software wallet. $k$ can even be the same value as provided in the nonce hash randomization scheme.
   
   Mandatory nonce proof-of-work significantly disrupts the attacker's ability to nonce grind since each candidate must also satisfy the challenge. Imagine that the proof of work challenge is set so that signing should take around 5 seconds. Then to embed one bit of secret data in the public nonce you would double this to 10 seconds, to embed another it would take 20 seconds and so on. This allows the user to potentially notice the attack and significantly reduces the amount of data that can be embedded.
   
   There are some drawbacks of this approach given that computational power varies from device to device, and that it requires the user or accompanying wallet to notice signing is taking a suspiciously long time. However, requiring even a small amount of PoW is much better than none at all.

With mitigation (1) alone, attackers are left with only nonce grinding to exfil a secret via signatures. This stops Dark Skippy and predetermined nonces, leaving the attacker with only the nonce grinding approach. Therefore in our eyes signature exfil would no longer be the best attack vector. With both mitigations, we are moderately confident that these attacks are universally impractical and unlikely to be attempted, though a weakened nonce grinding attack is still possible.