search

anoma / anoma-archive

Reference implementation of the Anoma protocols in Rust.
https://anoma.net
GNU General Public License v3.0
425 stars 176 forks source link

Atomic MASP Transaction Signing #1189

Closed murisi closed 2 years ago

murisi commented 2 years ago

We will soon be working on integrating MASP transactions with hardware wallets. These low-performance/low-power devices receive transactions from the computer, sign them with the key securely stored inside it, and send the signed transaction back to your computer.

One issue is that since signed MASP Transactions are stored inside signed Transfers, two rounds of communication have to happen with the hardware wallet. The first communication gets the inner Transaction signed, and the second communication gets the outer Transfer signed. So one important task to increase simplicity and security is to eliminate these two rounds and make the signing operation atomic.

The transaction formats (both in this repo and the MASP crate) might have to be changed so that it is possible to (1) construct most of a transaction and proofs (if possible) without the spending key, and (2) to sign everything at once (even theoretically on a different machine). It would be nice if this could be done without affecting too much other code (especially the code handling transparent Transfers and other non-MASP ledger code).

leontiad commented 2 years ago

That needs more unwrapping, things that we need to clarify:

murisi commented 2 years ago

Thanks for these questions. I believe the hardware wallet team will be taking care of authentication, communication, and data flows. (They will be reading our code, specs, and data formats in order to produce their system.)

I think the core issues brought up is that (1) our current nested signed transaction format is not compatible with a single single signing round and (2) we should not need to use nested signed transactions. Perhaps @joebebel and @juped can provide more context on this.

joebebel commented 2 years ago

This seems rather difficult. The HW wallet generates the rerandomized key before the proving step, so there has to be some amount of communication. Signing the inner and outer tx simultaneously might be tricky too - once the inner tx is signed, the HW wallet would have to add the signature and hash the outer tx (I suppose not completely infeasible)

How hardware wallet and computer are authenticate themselves to each other? What is the data flow? How communication between each of them is secured? Are we assuming always the computer is trusted and the hardware as well? What is the overall workflow here? What do we assume the hardware wallet is holding?

This is documented precisely in section 4.15 Spend Authorization Signature of the Zcash Sapling protocol, and the details don't change for MASP. The short answer is that the model looks like:

  1. The hardware wallet is the "trusted" platform and holds the spending key/computes the signatures
  2. The host computer is computationally powerful (memory and CPU) to write the proofs
  3. The host computer must have full "viewing" capability but not spending capability (never sees the spending keys)
  4. There is generally no authentication or security between the HW wallet and the host computer - usually it is a USB connection (there are bluetooth HW wallets - in which case the channel has standard bluetooth security)
Scar26 commented 2 years ago

Currently, there doesn't seem to be a scenario where an atomic signature will be required assuming that transactions only support a single source. Depending on whether the source is transparent or shielded, we only need one of the 2 signatures for a given transaction.

  1. Transparent source: There are no shielded coins being spent = no spend descriptions = no spend auth signature required
  2. Shielded source: Spend auth signatures are required but the wrapper (Transfer object) is signed with MASP's sentinel key which is public anyway, so this doesn't need to be offloaded to the hardware wallet
leontiad commented 2 years ago

It is is not very clear case 1. There is always a need for a signature authorizing spending of coins within a transaction, or there is sth else here?

Scar26 commented 2 years ago

Spend auth signature here refers to the MASP SpendAuthSigs (4.15 in the zcash spec). We need 1 such signature to go with every Spend Description. In case 1, there are only transparent inputs meaning there's no shielded coins being spent, so SpendAuthSig won't be required