Implicit Authentication

[m-schmoock]

Rationale

Using EPS without a SSL tunnel or other transport layer security is not recommended as:

1. Privacy: Malicious users may separate your addresses from others by asking your EPS and trying around.
2. Connectivity: EPS currently only supports one session and has no anti-spam protection yet.
3. Connectivity: The electrum botnet is still actively trying to connect to electrum nodes, if you use port 50002, chances are your EPS will be blocked eventually.

Having users to figure out transport layer security or tunneling setup on their own will result in most users skipping that and thus harming their privacy. Especially as it will become more and more normal to use EPS for mobile clients, i.e. such as eclair.

I see users wanting to run one simple docker command to get a EPS maybe including BTC node online without having to care for tunneling.

Problem statement

We need to distinguish legit users (in charge of private keys) from non-legit users (trying and messing around).

Concept

First: Implicit Authentication Mechanism can be an optional config option that the EPS operator decides on if and how to use it, as it may impact compatibility with his wallet.

Electrum protocol uses JSON RPC which supports sending responses out of order. We can utilize that in order to delay responses until we know sure enough that a client connection is done by a legit user. Non legit users connections should be dropped.

Hard authentication:

• Whenever a client subscribes or requests a history for a known unused address the EPS knows for sure the client connection is legit. The EPS can respond all other pending requests normally and can keep that state until the connection is closed by the client.
• If a users session is authenticated, a config option may decide temporarily whitelist further sessions from that public IP address for a given timeout.

Weak authentication:

• The user uses an IP address that is temporarily whitelisted by a prior successful hard authentication.
• all requests done by the user up to a given threshold are belonging to a known wallet, but no requests to an unused address has been made yet. The threshold may be chosen to be compatible with common clients, i.e. around 30 requests. This is required for Wallets with lots of addresses, that may turn out to request a vast history at first. Having a malicious user knowing or trying out a complete set of i.e. 32 addresses all belonging to the user offers reasonable security against privacy attacks, especially as we will not leak information about the non belonging address we detected.

dis-authentication:

If the user not yet hard authenticated, we can assume a connection to be not legit on the first request that is made to an address that not known.

initial thoughts from IRC:

< m-schmoock> belcher_: instead of trying to get a login/password into the electrum protocol
(which will totally remove the point for EPS anyway) can't we just authenticate a user by
subscribing to a known chains pubkey hash that has not seen onchain activity before
(the next free address). this way an attacker could not figure your addresses out by trying
unspend outputs.
< m-schmoock> only the holder of the privkey should know (and subscribe) to any of the next
unused addresses
< m-schmoock> a user that does not subscribe to an known but unused is by usage and
definition not authenticated, as he does not proof to be in charge of the privkey

[chris-belcher]

Good idea.

If wallets open up several connection, we could utilize temporary IP whitelist

Can you elaborate on this? When do wallets open several connections, what problem is solved by a temporary IP whitelist

[m-schmoock]

@chris-belcher I updated the issues main text to be more accurate.

The IP whitelist is just to skip implicit authentication method from the same IP address for a give timeframe. I think some wallets may open up multiple connections (for whatever reason). Maybe we do not need this at all, t.b.d.

[chris-belcher]

I've reviewed the edited OP and it seems like a good idea.

[m-schmoock]

Quick note on Explicit Authentication

If we are going to implement authentication RCP calls, we should not introduce username/password credentials settings, as this requires additional UX stuff, that is not necessary. We can already use the preknowledge of the xPubKey and let the client submit the correct specially derived pubkey of i.e. m/0/ or m/42/ or whatever that proofs the client is in charge of the correct xpubkey chain. Something can be done in the other direction, if the server needs to authenticate itself towards the client, it can ECDSA sign a message with derived pubkey m/0/ or m/42/ or whatever.