Secure against interception of RevealSecret messages

[hackaugusto]

Problem Definition

For a mediated transfer ABC, where B is the attacker, B is choosing the expiration for the lock BC and is in a position to choose a low expiration time, given that C receives the BC mediated transfer and send a SecretRequest to A, followed by the SecretReveal message from A to C, if B is in a position to intercept the message he can learn the secret while making sure that C won't, that means B can wait for the BC lock to expire and then unlock the AB lock.

Note: Assuming that an attacker can intercept and drop messages and that we don't have guaranteed delivery of messages.

Solution

Possible solutions:

1. Use transport provided E2E encryption
2. Encrypt the secret with C's public key
3. Allow C to choose the secret (or part of it, related Provide a receipt for payments #368 )
4. Enforce constant lock expiration through out the path

Tasklist

• Implement a test case where the attack is simulated
  • Implement one fix

Related

Provide a receipt for payments #368
Add Ack authentication #44

[LefterisJP]

As we had discused in the Berlin meeting we would need message encryption for this issue. As we can have message encryption with Matrix transport this could be handled easily then but for Red Eyes we don't want to switch encryption on. As such this issue is going out of Red Eyes.

[Zerim]

Hey folks, came across the link to this issue while reading the docs, and wanted to make sure I understand what's being described correctly.

As it is written, this line is a bit confusing to me:

if B is in a position to intercept the message he can learn the secret while making sure that C won't

When would B be able to intercept a message that is being passed to C and prevent C from receiving? Isn't the path through the overlay network only meant to represent the path of the payment channels? Why would messages also be sent along this path, rather than just directly from A to C?

Or is this describing a man-in-the-middle attack where somehow B has also compromised A or C's access to the internet?

Thanks in advance for the clarification.

[hackaugusto]

Hi @Zerim ,

It describes the second case [...] a man-in-the-middle attack where somehow B has also compromised A or C's access to the internet

[hackaugusto]

Enforce constant lock expiration through out the path

Having a constant lock expiration is sufficient only if the secret is revealed on-chain, if the secret is revealed off-chain then the constant expiration is not sufficient.

[pirapira]

I had a discussion about this with @hackaugusto and @LefterisJP .

I prefer encryption with the receiver's Ethereum public key because

• the same solution works for all transport layer alternatives, and
• we can easily be sure that the target of the encryption is the target of the payment.

1. RequestSecret message should contain the public key of the target.
2. The initiator should check the public key against the address of the target.
3. The initiator should encrypt the secret in RevealSecret using the public key of the target.

It's possible to encrypt data with Ethereum public keys: https://github.com/LimelabsTech/eth-ecies.