Authenticate network messages

[ch1bo]

Why

The Hydra Head protocol should be safe from adversaries which try to impersonate protocol actors via the L2 network.

When comparing the HydraV1 specification with the current implementation, we saw that we do not authenticate messages from the network layer.

Not addressing this, will allow anyone to trick the Head protocol into thinking a message came from one of the other parties. This can be used, for example, to ingest forged ReqSn messages to make the Head stuck (because they likely will not be consistent with other messages delivered).

However an attacker would not be able to sign snapshots nor create valid layer 2 transaction to spend funds. Both require the respective signing (private) keys.

What

Within this feature we add application-level signatures & verification (in contrast to transport level authentication of messages).

• Network messages submitted on the L2 are signed the Hydra signing key
• Received network messages are verified against the Hydra verification key of the sender (included)
  • If not, drop the message
• It is checked that the sender is one of the known Head participants
  • If not, drop the message
• Ensure that the signer of the message is the party that is present in the message itself.
• Dropped messages are logged.
• Explore replay attack

About the replay attack, we note that there are three kinds of messages that could be replayed and we don't see no issues with replaying them:

• ReqSn -> includes the snaphotNumber so will ignore an already seen ReqSn
• AckSn -> includes the snaphotNumber so will ignore an already seen ReqSn (and, anyway, the payload of an ackSn is true forever and this message is suppose to be idempotent)
• ReqTx -> the ledger rule will prevent the transaction to be applied again on the ledger (you can't spend the same thing twice), especially since we don't support reference script inside a head.

The only exception to this might be if someone posts a transaction that only spend reference inputs. Then, maybe, one could repost this transaction to the ledger if there are no fees, which could be the case inside a head. But that raises several questions:

• Is it really possible to forge transaction like that?
• Why would someone forge a transaction like that in the first place (you need that for a replay attack)
• Why would that be a problem if someone could replay that kind of transaction anyway?

So we'll consider the current solution fine at this stage.

How

• Hydra keys are Ed25519 keys - use EdDSA to sign / verify; functions from Hydra.Crypto
• ReqTx, ReqSn and AckSn contents need to have a SignableRepresentation
• The sender Party shall not be part of the signed body
• Connected and Disconnected events shall not be affected by this
• Likely requires some restructuring of data types
• Whether sender is part of the head needs to be in the HeadLogic layer.
• Authenticity of the message itself can be checked on the networking layer or the HeadLogic layer.

[pgrange]

Marking as 🔴:

• is it only a denial of service issue of a worst security problem?
• would the solution match the authenticated channel assumption from the specification?