Account Handling

[konradkonrad]

Problem Definition

Raiden needs to create signatures on behalf of the user. The interaction model doesn't allow to actively query for account passwords on-demand. This is different from the designed account interaction model in ethereum, where wallets can ask the user for the account unlock password on demand in order to sign transactions.

Keeping the account password and/or privatekey in memory is a potential security risk for the user's funds. We should aim to minimize the exposure.

Solution

There are two potential paths that I can think of at the moment, both of which are independent:

1. Provide the user with a simple way of migrating only the necessary amount of funds (ETH & ERC20) into a special purpose account.

The interaction could be, that in order to join a token network, an account assistant asks the user for the amount of ERC20 funds that shall be used and a recommendation of an ETH amount for gas for on-chain transactions. The funding of the special purpose account would then happen via regular interactive unlock requests. The special purpose account can stay unlocked.

2. Separate signing into a different process to minimize the attack surface of the process that holds the private key.

By separating memory of the main process and the signing process we could achieve further hardening: leaking memory of the (more complex) main process would not expose the privatekey that is used for signing.

[hackaugusto]

related: #1402

[andrevmatos]

Related approach that's going to be taken by the light-client: raiden-network/light-client#172
It doesn't need to be followed by python client, nor requires further changes on it beyond what's being done in raiden-network/raiden-contracts#1123 , as the subkey is seen as just a normal key by the peers.
This allows a local private key (called subkey) to be used only for messages signature, and a main key to be kept locked remotely and just unlocked on-demand for on-chain transactions, possibly with some auto-unlock/validation/whitelisting of specific transactions. This could also be used by the python client, if the improvement is deemed relevant.