<div dir="ltr"><div dir="ltr">Time-Dilation Attacks on Offchain Protocols<br>===================================<br><br>Lightning works on reversing the double-spend problem to a private<br>state between parties instead of being a public issue verified by every<br>network peer. The security model is based on revocation of previous<br>states and in case of broadcast of any of them, being aware of it to<br>generate justice transactions to claim misbehaving peer onchain outputs<br>before contest period expiration. This period is driven by the blockchain<br>which is here the system clock.<br><br>Eclipse attacks's end-goal is to monopolize a victim's incoming and<br>outgoing connections, by this way isolating a node from the rest of its<br>peers in the network. A successful Eclipse attacks lets the attacker<br>filter the victim's view of the blockchain, i.e he controls transactions<br>and blocks announcements [0].<br><br>Every LN node must be tied to a bitcoin full-node or light-client to<br>verify independently channels opening/closing, HTLCs expiration and<br>previous/latest state broadcast. To operate securely, the view of the<br>blockchain must be up-to-date with the one shared with the rest of the<br>network. By considering Eclipse attacks on the base layer, this assumption<br>can be broken.<br><br>First scenario : Targeting the CSV security delay<br>--------------------------------------------------------------<br><br>Alice and Mallory are LN peers with a channel opened at state N. They<br>use a CSV of 144 blocks as a security parameter for contestation period.<br>Mallory is able to identify Alice full-node and start to eclipse it.<br>When done, it keeps announcing blocks to Alice node but delaying them by<br>2min. Given a variance of 10min, after 6 blocks, Mallory will have a<br>height ahead of Alice of 1, after 24 blocks, a lead of 4, after 144,<br>a lead of 24, after 1008, a lead of 168.<br><br>After maintaining the eclipse for a week, Mallory will have more than a<br>day of height advance on Alice view of blockchain. The difference being<br>superior at the CSV timelock, Mallory can broadcast a previous<br>commitment transaction at state N - 10 with a balance far more favorable<br>than the legit one at height H, the synchronized height with the rest<br>of the network.<br><br>At revoked commitment transaction broadcast, Alice is slow down at<br>height H - 168. At H+144, Mallory can unlock its funds out of the<br>commitment transaction outputs and by so closing the contestation period<br>while Alice is still stuck at H-24. When Alice learn about revoked<br>broadcast at H, it's already too late. Mallory may have stopped the<br>Eclipse attack after H+144, or he may pursue the attack on Alice because<br>of targeting multiple of her channels in parallel.<br><br>Second scenario : Targeting the per-hop CLTV-delta<br>-------------------------------------------------------------------<br><br>Alice, Bob and Caroll are LN peers with channel Alice-Bob and Bob-Caroll.<br>Bob enforce a cltv_delta of 12 blocks on incoming HTLCs. Alice and Caroll<br>are both malicious and start to eclipse Alice full-node until they gain a<br>lead of 15 blocks on Alice.<br><br>At height N, Alice route a payment E to Caroll through Bob with a base<br>delta of 24 blocks. On channel AB, HTLC will expire at height H+24, on<br>channel BC, it will expire at height H+12 while Alice ticking herself<br>at height H-15.<br><br>When real-network blockchain height reaches H+24, Caroll provides<br>preimage P to Bob and following protocol rules she gets a new<br>commitment transaction with balance increased of HTLC E. At same time,<br>Alice broadcast unilaterally commitment transaction for AB and claim<br>back HTLC E with a HTLC-timeout transaction as its nLockTime is already<br>final. Bob wrongly clocking at height H+9, HTLC on channel BC won't have<br>been timeout by him and provided preimage is now useless as HTLC as<br>already claimed back on mainnet blockchain.<br><br>Attack difficulty<br>-------------------<br><br>Following Eclipse attack paper publication, multiple counter-measures<br>have been implemented [1], [2]. Even if it's far harder, this kind of<br>attacks may still be possible for an off-path attacker. Including recent<br>changes, research should be done to ascertain it. Beyond, it still<br>widely feasible for attackers controlling key infrastructure between<br>the victim and the network [3]. A simple Tier 3 ISP doing deep packet<br>inspection and delaying your blocks may be able to practice this class<br>of attacks.<br><br>The case of LN nodes using light clients, like BIP157 or Electrum, as a<br>backend should be specially considered. Given the low number of servers<br>providing these services today it should be trivial for an attacker to run<br>swarm of them and from then control blockchain view of this class of LN<br>nodes.<br><br>Another difficulty of the attack, is to map the LN node to its full-node.<br>This can range from being trivial if both run in clear with same ipv4<br>address. It would be interesting to scan both networks and see how many<br>nodes pair are in this case. Learning the mapping can still be doable if<br>they are using an anonymous network like Tor with same exit node base on<br>message timing.<br><br>Further inter-layer mapping techniques could be developped like funding<br>transaction broadcast and seeing its propagation on the base layer. Or<br>knowledge of onchain utxo graph leaked by addressed reused to fund<br>channels.<br><br>On the LN-side, depending of the scenario, cost of the attack ranges<br>between opening one or two channels and paying the related onchain fees.<br>That being said, an attacker can also target victim-initiated channels<br>and costs would be reduced only to operating LN nodes.<br><br>Onchain counter-measures<br>-----------------------------------<br><br>Warnings could be triggered by full-node when the block issuance rate<br>becomes weird but first it's hard to dissociate weirdness from edges of<br>block variance and secondly the algo being public it should be easy for<br>an attacker to stay under the radar by choosing the right announcement<br>delay.<br><br>Raising alarms based on nTime of block headers being to far in the past<br>compare to local clock wouldn't make sense due to IBD.<br><br>A practical solution would be to have multiple bitcoin full-nodes<br>with multi-homing and doing reconciliation of blockchain views every<br>N hour/minute. This kind of method, already deployed by some bitcoin<br>infrastructures, would raise attack difficulty for off-path attackers<br>but wouldn't counter in-path attackers. Nevertheless, it would already<br>be a good step, the issue is the current absent of implementing this<br>in open-source software for hobbyists.<br><br>A defense in depth would require to have multiple data links, like<br>receiving headers from space/radio or tunneling through<br>some other protocols [4].<br><br>Even learning discrepancies between your local view of the blockchain<br>and the mainnet one, the right move to do isn't clear as an automatic<br>system may be triggered by false positives to halt operation of your LN<br>node, a human intervention to double-check may seem preferable. And<br>it's really likely the attacker control you ability of transactions<br>on the base layer. BIP324 may help there.<br><br>Offchain counter-measures<br>-----------------------------------<br><br>Some LN errors messages may be triggered at abnormal rate like<br>`expiry_too_soon`  due to victim using a HTLC base in the past and may<br>be used to guess oddities.<br><br>A measure orthogonal to running multiple bitcoin full-nodes should be<br>to have multiples watchtowers running their own blocks provider (full-node<br>or light clients). Assuming attacker don't control your connection to them,<br>if at least one of them isn't eclipsed, it should be able to time-out HTLC/<br>justice revoked transaction efficiently.<br><br>Another option would be to use the control plane as a safety mechanism.<br>When a LN node learns a channel_announcement to far in the future it<br>would ask to this LN node, few next headers through this communication<br>channel and connect these headers to its full-node. Based on this<br>information, full-node may trigger alarms more accurately. This mechanism<br>would work assuming one of your gossiping LN node is honest. It may ask<br>for fine-tuning to avoid there too false-positives but it seems an<br>interesting topic of research to use L2 information to correct L1 blockchain<br>view and even further to use L2 communications channels as an emergency<br>transaction broadcast.<br><br></div><div dir="ltr"><br></div><div dir="ltr">Further research could be lead to investigate attacks combining eclipsing victim<br>view of both layer, that's said the LN one may seem harder to take on as nodes<br>have persistent identities.<br><br>Eclipse attacks were already known to be very bad, offchain protocols<br>relying on time for their security model make them worst at it lower the bar<br>to exploit them from being a miner to being party to an offchain contract.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><div>After talking with LN implementations teams, they don't think funds are at risks,</div><div>given than light clients have low-value channels right now and it's not worthy the</div><div>attack setup, but they acknowledge the issue on the long term for processing nodes.<br></div></div><div dir="ltr"><br></div><div dir="ltr"><br>Thanks to Gleb Naumenko for fruitful discussions/review.<br><br>Cheers<br><br>[0] <a href="https://eprint.iacr.org/2015/263.pdf">https://eprint.iacr.org/2015/263.pdf</a><br><br>[1] <a href="https://github.com/bitcoin/bitcoin/pull/9037">https://github.com/bitcoin/bitcoin/pull/9037</a><br><br>[2] <a href="https://github.com/bitcoin/bitcoin/pull/8282">https://github.com/bitcoin/bitcoin/pull/8282</a><br><br>[3] <a href="https://erebus-attack.comp.nus.edu.sg/">https://erebus-attack.comp.nus.edu.sg/</a><br><br>[4] <a href="https://github.com/bitcoin/bitcoin/pull/16834">https://github.com/bitcoin/bitcoin/pull/16834</a></div></div>