Analyzing Signature Variations
The ECDSA protocol provides certain leeways for signers when generating a valid signature, such as the choice of nonce, a temporary variable employed during the signing process. This leeway can be exploited by malicious firmware to embed key information within signatures that are still able to pass validation checks. The introduction of BIP461 addresses these issues by enforcing a specific deterministic method.
Merely accepting a Bitcoin signature does not guarantee that the private key was protected during its creation. A standardized specification exists to provide a reference output that enables verification of the signer’s actions.
To perform this comparison, the inputs must be identical, and there should be adherence to the same standard, which includes access to the private key from another independent signer. This additional exposure is a necessary trade-off for re-creating the signature. If different results are obtained for the same key and message hash, it indicates that at least one signer is not adhering to BIP461 guidelines.
A legitimate implementation utilizing an alternative valid ECDSA method can also yield differing results. Such discrepancies warrant an investigation into adherence to guidelines, although the underlying cause may remain unclear. Simply comparing signatures does not conclusively identify a malicious device or prove theft.
The outlined algorithm restricts signatures to a maximum of 70 bytes when using standard DER encoding, not counting Bitcoin’s one-byte sighash flag.
The Dark Skippy report highlighted how compromised firmware can conceal seed material within transaction signatures. In their initial report, the researchers noted that they had yet to observe this technique in real-world applications.
While Dark Skippy initially demonstrated this vulnerability using Schnorr signing, BIP461 specifically addresses ECDSA. Taproot employs the distinct BIP340 Schnorr method, hence this draft does not directly provide a solution to that demonstration.
The researchers also noted that a malicious signer may leak data selectively on a specific transaction, meaning a device could produce compliant signatures for testing while revealing information on another transaction.
During the review in September, a reviewer indicated that test vectors and a reference implementation were essential for BIP461 to move towards completion.
For wallet users, the proposed standard holds promise as a common benchmark that could reveal discrepancies. However, realizing this potential relies on compliant implementations and comparisons that consider both detection limits and the risks associated with managing sensitive data.