BitcoinAndLightningLayerSpecs / lsp

API specifications for Lightning Service Providers
MIT License
112 stars 32 forks source link

JIT/HTLC Interception - Failed payment attack #4

Open SeverinAlexB opened 2 years ago

SeverinAlexB commented 2 years ago

Issue #3 proposes two different ways to implement Just-In-Time (JIT) channel openings. JIT are an important feature especially for mobile wallets.

Option a) and b) proposed in the issue, are both vulnerable to an attack I call here the "Failed payment attack". This vulnerability allows an attacker to make the LSP open a channel without it being paid a fee.

Here I will show how such an attack could look like and potential mitigations.

Attack description

Prerequisits

The attacker owns 2 nodes:

Base attack

  1. The receiver node registers an incoming payment at the LSP.
  2. The receiver node sends the invoice to the funded node.
  3. The funded node pays the invoice.
  4. The LSP recognizes the incoming payment and opens a turbo-channel to the receiver node.
  5. The LSP forwards the HTLC to the receiver node.
  6. The receiver node rejects the HTLC and therefore fails the payment.

In this case, the attacker made the LSP open a channel without a fee.

Systematic attack

The base attack can be turned into a systematic attack cheaply. Multiple receiver nodes can be created without any costs as they need zero funded channels. The funded node can be reused. The used HTLC recovers instantly because the receiver node failed the payment. Due to LN sender privacy, the funding node stays anonymous.

Therefore the attacker can repeat the base attack as often as they want without any costs. They can make the LSP open a huge number of channels without it being able to charge a fee and therefore inflict huge costs on it. In case the receiver node refuses to coporatively close the channel, the funds will be stuck in limbo multiple days blocking the LSP onchain funds.

Mitigations

I define two potential attackers here.

I am mostly concerned about b).

Potential mitigations

  1. Close the channel instantly again. This prevents (a) from using the channel and therefore gaining anything from the attack.
  2. Hold the HTLC for several hours in case the payment fails. This could potentially slow down (b) but will not stop them.
  3. Share the preimage with the LSP when the receiver node registers the payment initially. This would shift the problem from the receiver node (can fail the HTLC) to the LSP (can just claim the HTLC without opening a channel). This would effectively prevent (a) and (b) but give the LSP a lot of power. In an environment where LSPs have to keep a good reputation, this could be a workable solution.

Personal note

I believe this attack has a good potential to be abused by either competitors or state-level actors. The costs are high especially with high on-chain fees. We should think about mitigations.

Maybe somebody comes up with a better mitigation strategy than 3. Sharing the preimage but so far I see this as the most practical solution. 3. is far from perfect.

Severin

SeverinAlexB commented 2 years ago

Some additional inputs:

ZmnSCPxj-jr commented 1 year ago

See also: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003939.html (not a reliable fix, by the way).