Provide a dedicated "component" for off- and on-chain signing

[ghost]

Which entity has access to signing keys defines the security and trust model of a system relying on asymmetric cryptographic primitives like Hydra. The current situation is that the hydra-node executable holds both off-chain (for signing snapshots in the Head) and on-chain (for signing transactions on L1 chain) signing keys, which implies that:

1. hydra-node users are safe if and only if they operate the nodes (both hydra-node and cardano-node) themselves,
2. All cryptographic operations are done within the hydra-node process.

This has several consequences:

1. It severely limit the reach of Hydra Head: Most users either won't have the technical know-how to run such a service, or wouldn't be bothered to and would rather rely on a service provider's expertise to run the nodes on their behalf. Yet, users would certainly want to retain control over the protocol and transactions that appear inside the Head and most of them would be reluctant to delegate acceptance of potential impactful transactions to a third-party system,
2. It makes it impossible to use external key management system, like cloud-based KMS, HSM, or trusted hardware.

I therefore propose the introduction of another component along the lines of ADR-007 and ADR-002 that would be responsible for signing both on-chain and off-chain transactions.

Here is a sketch of the possible interface:

data SignReq tx = SignSnapshot Snapshot | SignTx tx
data SignResponse tx = 
  SignedSnapshot SnapshotNumber Signature | SignedTx tx | SigningFailed SigningError

newtype Signer m msg = Signer { sign :: msg -> m () }

type SigningCallback m msg = msg -> m () 

type SigningComponent m msg a = SigningCallback m msg -> (Signer m msg -> m a) -> m a

here is how it would be introduced in the HeadLogic:

data Event tx = ...
  | SigningEvent (SignResponse tx)

data Effect tx = ...
  | SigningEffect (SignReq tx)

Then we would need to:

1. Add a SignReq/SignResponse sequence of messages within the update function for both snapshots and OnChain transactions,
2. Modify Direct chain component to not delegate signing to internal TinyWallet but instead report to Callback and only post a properly signed tx.

This component could be implemented in various ways of which I can think of at least 2:

1. Internal signer, which is just the same as what we have now,
2. Client-based signer, whereby SignReq are routed to a client through the Server API which can then do the signing on its side, retaining full control over keys.

[ch1bo]

Your code examples seem to refer to the off-chain snapshot signing, but then the consequent changes and possible implementations suggest that these would be used for signing on-chain protocol transactions. Are you suggesting to out-source both using the same mechanism?

As you also mention in the intro, there are two kinds of signatures required in the system:

1. Hydra off-chain snapshot signatures, performed by Hydra signing keys (right now EdDSA, later Schnorr signatures/musig2)
2. Chain-specific protocol transaction signatures, in our case Cardano, performed by Cardano signing keys (EdDSA)

I basically concur and believe there are use cases for having options to outsource both:

1. Hydra signatures done on the client side in small (I would even claim 2-party only) Hydra Heads, where every transaction shall be signed by the client (application). This allows for "lighter" ways to participate in Hydra Heads, but consequently require all clients to be online for any progress in the Head.

2. Cardano signatures for protocol transactions (init, commit, collect, close, contest and fanout) performed outside of the hydra-node by external wallets:

   • We would not need to "top up" the hydra-node wallet (the signing key currently given as --cardano-signing-key) with funds to fuel hydra protocol transactions, also no funds would be at risk given the (currently) insecure nature of these integrated signing keys.
   • Any state transition would need to get external approval, which can be quite manual in case of warm or cold wallets. Especially contest may be problematic, depending on the contestation period.
   • An alternative could be to only "externalize" commit transactions, where where the funds to be committed would already reside under control of some external wallet. We have a roadmap feature about this already.

Even if this is not new info to most readers, I wanted to add that context and maybe we can discuss these use cases / alternatives. Or at least clarify whether we want to distinguish them in the architecture design or not?

[ghost]

I did not separate the 2 signatures and only detailed the off-chain case which is a bit more contentious, or less obvious. But yes, I am definitely thinking of off-loading the 2 kind of signatures and I agree we should separate them in the design.

[ghost]

The interface I envisioned would take care of both, so it's a first step in the direction of hydra-node not holding any secrets. BTW, in a previous company, where I was working on a similar piece of code, it was definitely a strong requirement from Enterprise customers to completely separate sensitive crypto operations from the core consensus logic, e.g in order to be able to use specialised hardware or software.

[ch1bo]

Signing chain transactions does not involve the HeadLogic right now and in my opinion we should not introduce another roundtrip to do so. Alas, signing cardano txs via external wallets (use case 2 from my comment) would be responsibility of the Chain component/layer altogether?

If you agree, this would mean to me that we are speaking about two distinct features / architectural design decisions / discussions to be had?

[ghost]

It seemed to me initially that having a single component responsible for all the client-side sensitive operations would make sense but I agree those 2 live in different parts of the system. It would be convenient to leverage the existing client-facing API to do both, for simplicity's sake, which is my original rationale for shoving both off- and on-chain signature in the same interface.
How would you see the on-chain txs signing process happening?

[pgrange]

This discussion is somehow related to Client side snapshot signing for which we want to have an issue in our roadmap.

The following picture shows the different kind of keys that are used currently in the system named, in the picture:

• participant key (can post hydra head transaction on layer 1)
• snapshot key (can sign a snapshot)
• payment key (can validate the spending of a given UTxO)

The picture is about hydraw but we can generalize. We have three configurations:

1. What we have Today
2. External Commit
3. Client Side Signing

Today (1), the three keys are all on the same system running both hydra-node and cardano-node. Which means that the hydra-node operator can:

• post hydra head transactions to layer1
• sign hydra head snapshots
• spend UTxO inside the head

In External Commit (2), someone could commit funds to the head from an external wallet. That is, a wallet owned by none of the hydra-node operators of the head. After that, when the head is open, for this UTxO to be spent inside the head, an honest hydra-node would require this transaction to be signed by the corresponding payment key. If all the hydra-node operators are corrupted and collude, then they can build and sign a snapshot where this UTxO has be spent without having it being signed. So the external commiter have to trust that at least one hydra-node operator is honest.

In Client Side Signing (3), the hydra-node operator still own a participant key. That means it can post transactions about the head on layer 1. However, a user, not operating the node, would own the snapshot key and would only accept to sign a snapshot proposed by the hydra-node if it considers it valid.

[pgrange]

☝️ this is discussing the case where some client wouldn't trust a hydra-node operator or a hydra-node operator group (remember, we only need to trust one of them for the transaction to be legit in a head). It's probably different and more involved than the original topic which were maybe more towards protecting key material with some external hardware, right?

[ch1bo]

Has been promoted to a roadmap item via #635