[ZIP 305] Best practices for hardware wallets supporting Sapling and Orchard

[daira]

Document how a hardware wallet (that has a trusted path to the user) should construct or verify transactions in order to protect its user, as far as possible, against attacks from the untrusted computer.

In the general case we have a hardware wallet, an untrusted computer, a delegated prover, a user, and a network connection, something like this:

             network
                ↕
h/w wallet ↔ computer ↔ prover
      ⤡       ⤢
         user

The h/w wallet should not trust the computer or the prover with spend authority, and should not allow a transaction confirmed by the user on the wallet's UI to be malleated while remaining valid. Similarly the computer should not trust the prover with spend authority (this is automatic when the computer is not trusted with that authority), or ability to malleate the intended transaction.

We believe that the Sapling design supports this without requiring the h/w wallet to be able to either prove or verify Spend or Output proofs. A h/w wallet should only need to implement:

• Pedersen commitments using Jubjub arithmetic (for note and value commitments)
• BLAKE2b and BLAKE2s (and the various PRFs / CRHs they are used in)
• Nullifier check (using Jubjub arithmetic)
• KDF plus either encryption or decryption (AEAD_CHACHA20_POLY1305)
• SignatureHash algorithm
• Signatures (RedJubjub, i.e. randomized EdDSA on the Jubjub curve)
• A source of randomness.

[str4d]

TREZOR's transparent transaction workflow is documented here: https://wiki.trezor.io/Developers_guide:Message_Workflows

[str4d]

Extracts from the discussion that led to me posting the above comment:

• RedJubjub is the operation that defines spend authority. Everything else in the list above is for the HW to check it is signing what it thinks it is.
• Note that there's sharing of code between the Pedersen commitments, the nullifier check, and the RedJubjub signatures: you only need to implement Jubjub curve arithmetic once.
• TREZOR fragments transactions when sending to its HW due to memory limitations. This should be compatible with Sapling.
  • If you look at how our current Sapling verification is organised (Sapling proving and verifying API librustzcash#30) we only need data for a single input or output at a time (which is at most 948 bytes), with only 32 bytes of context. In this case, we also need the private data for each input or output to be cached by the device for at least one round-trip.
• Ledger seems to use a much lower-level approach, and it has a memory model that restricts the use of pointers (https://ledger.readthedocs.io/en/latest/userspace/memory.html), which means that any libraries used would need to be reviewed for conformance with that model.