Prevent BalanceProof replay attacks for different Registries and Ethereum networks

[konradkonrad]

With #287 we implement a replay attack mitigation scheme, that relies on the state of one (and only one) raiden network. We assume, that a channel will have a limited number of messages per lifetime and apply a starting nonce scheme, based on the block number.

Since anyone can start a new raiden network by just deploying another instance of the Registry contract, there is no guarantee that Alice and Bob will never have a channel for the same asset opened at the same block number in two raiden networks R and R' (which would lead to the same nonce ranges being valid in channel AB(R) and AB(R')).

Level One State Specific Replay Attack Mitigation

A state specific replay attack mitigation scheme would (instead of relying on the opening block number) use something specific to the channel contract instance, e.g. hashing the channel contract address into each signature.

Note, that this potentially still leaves replay attack vectors open for raiden instances on different blockchains (i.e. testnet vs mainnet), across forks, etc...

Level Two State Specific Replay Attack Mitigation

For further hardening, the opening party could provide a blockchain specific piece of information (e.g. genesis block hash/fork block hash) that would become part of the channel data and should be concatenated with the channel contract address for signatures.

Whether we need this second level of replay protection should be discussed.

See also #93

[LefterisJP]

Let's also add to the discussion of this issue whether we would like to have this as part of the MVP or if the nonce ranges are enough for it.

[hackaugusto]

Note: Added a test case for a replay attack using the same Registry but different Token that should be fixed with this issue.

[LefterisJP]

Related to this issue is the reported issue for lack of a check of the recipient address in the contract (#601) and its solution of adding said check (#602).

As specified in this ticket though there also the scenario of different token networks, different raiden networks, or even different blockchains/forks. Instead of introducing specific checks for all we can handle them by implementing the "Level One State Specific Replay Attack Mitigation" and "Level Two State Specific Replay Attack Mitigation" respectively.

[hackaugusto]

Update: We have added the chain_id to the balance proof (ref. raiden-network/spec#15 (comment)), this fixes replay attacks across some blockchains, but doesn't fix replay attacks on hard forks, because the chain_id is not available in EVM and it's provided in the constructor of the smart contracts.

The current unique identifier of the channel is composed by: ref

chain_id, token_network_address, channel_identifier

This ties the balance proof to a given chain, a version of the deployed smart token network contract, and a given channel in that token network

[LefterisJP]

To detect replay attacks across forks we would need to have a fork Oracle, just like with ETH/ETC fork oracles. We can't know in advance about hard forks so this is something we would need to be solving in a case by case basis. We can have a connection with a fork oracle from the very beginning of the contract deployment and just have control of the Oracle that can update the contracts in case of a fork.

[hackaugusto]

Closing in favor of the more specific issue raiden-network/spec#88