Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols
> It seems pretty easy to me to detect the difference between the normal > case (Alice's chaintip is old but she's still successfully downloading> > blocks) and the pathological case (Alice's chaintip is old and she's > unable to obtain more recent blocks). I think if alarm is implemented at the validation level it's not going to be reliable due to IBD. While connecting and validating headers, it's okay to process headers timestamp that's hours or days old. Current IsInitialBlockDownload logic returns false if tip is less than a day old. By slowing blocks announcement I could pin you indefinitely in IBD and alarms are not going to be triggered. The issue being than the comparison point can be manipulated by the attacker. Now, if alarm is implemented at the net_processing level, I think that's something like CheckForStaleTipAndEvictPeers is doable but tricky. If you're past headers-sync from one peer and best block header announced by a peer is too way in the past, disconnect it. Still, you can't be sure because maybe this node was buggy or its connection was faulty, so you need to repeat this few times and if all these peers announce block in the past there something is wrong and raise an alarm. But it seems hard to have detection without doing active peer rotation and this may have bad side effects on connectivity.. You want a reliable detection mechanism because if it's cheaply triggered you now have DoS attack vectors on the LN layer, like delaying blocks knowing it's going to trigger alarm and than a LN processing node will close its channels. You want scoping the issue beyond "something is wrong" (and like you mention there is also the edge case of a legit several hours delay) that's why fetching headers thanks to some redundant communication channel seems to me better. > To a point, transaction censorship just looks a failure to pay a > sufficient feerate---so a node will probably fee bump a > commitment/penalty transaction a few times before it starts to panic. I don't do the assumption of hashrate-attackers but yes that's interesting than you may combine with some mempool tricks to optimize the attack. Antoine Le lun. 16 déc. 2019 à 10:29, Matt Corallo a écrit : > Right, I kinda agree here in the sense that there are things that very > significantly help mitigate the issue, but a) I'm not aware of any > clients implementing it (and the equivalent mitigations in Bitcoin Core > are targeted at a different class of issue, and are not sufficient > here), and b) its somewhat unclear what the "emergency action" would be. > Even if you implement detection, figuring out how to do a fallback is > nontrivial, especially if you are concerned with user privacy. > > Matt > > On 12/16/19 9:10 AM, David A. Harding wrote: > > On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote: > >> If well executed, attacks described stay stealth until it's too late > >> to react. > > > > I suspect the attacks you described are pretty easy to detect (assuming > > block relay is significantly delayed) by simply comparing the time of > > the latest block header to real time. If the difference is too large, > > then an emergency action should be taken.[1] > > > > You mention IBD as confounding this strategy, but I don't think that's > > the case. Compare the normal case to the pathological case: > > > > - Normal: when Alice is requesting blocks from honest nodes because > > she's far behind, those nodes are telling her their current block > > height and are promptly serving any blocks she requests. > > > > - Pathological: when Alice is requesting blocks from a eclipse attacker, > > those dishonest nodes are telling her she's already at the chain tip > > even though the latest block they serve her has a header timestamp > > that's hours or days old. (Alternatively, they're reporting the > > latest block height but refusing to serve her blocks/headers past a > > certain point in the past.) > > > > It seems pretty easy to me to detect the difference between the normal > > case (Alice's chaintip is old but she's still successfully downloading > > blocks) and the pathological case (Alice's chaintip is old and she's > > unable to obtain more recent blocks). > > > > A possibly optimal attack strategy would be to combine > > commitment/penalty transaction censorship with plausible block delays. > > To a point, transaction censorship just looks a failure to pay a > > sufficient feerate---so a node will probably fee bump a > > commitment/penalty transaction a few times before it starts to panic. > > Also to a point, a delay of up to several hours[2] just looks like > > regular stochastic block production. By using both deceits in the same > > attack to the maximum possible degree without triggering an alarm, an > > attacker can maximum their chance of stealing funds. > > > > -Dave > > > > [1] There is an interesting case where a large miner or cartel of miners > > could deliberately trigger a false
Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols
Right, I kinda agree here in the sense that there are things that very significantly help mitigate the issue, but a) I'm not aware of any clients implementing it (and the equivalent mitigations in Bitcoin Core are targeted at a different class of issue, and are not sufficient here), and b) its somewhat unclear what the "emergency action" would be. Even if you implement detection, figuring out how to do a fallback is nontrivial, especially if you are concerned with user privacy. Matt On 12/16/19 9:10 AM, David A. Harding wrote: > On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote: >> If well executed, attacks described stay stealth until it's too late >> to react. > > I suspect the attacks you described are pretty easy to detect (assuming > block relay is significantly delayed) by simply comparing the time of > the latest block header to real time. If the difference is too large, > then an emergency action should be taken.[1] > > You mention IBD as confounding this strategy, but I don't think that's > the case. Compare the normal case to the pathological case: > > - Normal: when Alice is requesting blocks from honest nodes because > she's far behind, those nodes are telling her their current block > height and are promptly serving any blocks she requests. > > - Pathological: when Alice is requesting blocks from a eclipse attacker, > those dishonest nodes are telling her she's already at the chain tip > even though the latest block they serve her has a header timestamp > that's hours or days old. (Alternatively, they're reporting the > latest block height but refusing to serve her blocks/headers past a > certain point in the past.) > > It seems pretty easy to me to detect the difference between the normal > case (Alice's chaintip is old but she's still successfully downloading > blocks) and the pathological case (Alice's chaintip is old and she's > unable to obtain more recent blocks). > > A possibly optimal attack strategy would be to combine > commitment/penalty transaction censorship with plausible block delays. > To a point, transaction censorship just looks a failure to pay a > sufficient feerate---so a node will probably fee bump a > commitment/penalty transaction a few times before it starts to panic. > Also to a point, a delay of up to several hours[2] just looks like > regular stochastic block production. By using both deceits in the same > attack to the maximum possible degree without triggering an alarm, an > attacker can maximum their chance of stealing funds. > > -Dave > > [1] There is an interesting case where a large miner or cartel of miners > could deliberately trigger a false positive of block delay > protection by manipulating Median Time Past (MTP) to allow them to > set their header nTime fields to values from hours or days ago. I > don't believe the fix for the time warp proposed in the consensus > cleanup soft fork fixes this, since it only directly affects the > first block in a new difficulty period (preventing difficulty gaming > but not header time gaming). This problem is partly mitigated by > miners keeping MTP far in the past being unable to claim fees from > recent time locked transactions (see BIP113), though I'm not sure > how many transactions are actually using nLockTime-as-a-time (LN and > anti-fee sniping use it as a height). > > [2] If we suddenly lose half of Bitcoin's hashrate so that the average > time between blocks is 20 minutes, there's a once-in-a-century > chance of a block taking more than 310 minutes to produce: > > 1 / (exp(-310/20) * 144 * 365) > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols
On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote: > If well executed, attacks described stay stealth until it's too late > to react. I suspect the attacks you described are pretty easy to detect (assuming block relay is significantly delayed) by simply comparing the time of the latest block header to real time. If the difference is too large, then an emergency action should be taken.[1] You mention IBD as confounding this strategy, but I don't think that's the case. Compare the normal case to the pathological case: - Normal: when Alice is requesting blocks from honest nodes because she's far behind, those nodes are telling her their current block height and are promptly serving any blocks she requests. - Pathological: when Alice is requesting blocks from a eclipse attacker, those dishonest nodes are telling her she's already at the chain tip even though the latest block they serve her has a header timestamp that's hours or days old. (Alternatively, they're reporting the latest block height but refusing to serve her blocks/headers past a certain point in the past.) It seems pretty easy to me to detect the difference between the normal case (Alice's chaintip is old but she's still successfully downloading blocks) and the pathological case (Alice's chaintip is old and she's unable to obtain more recent blocks). A possibly optimal attack strategy would be to combine commitment/penalty transaction censorship with plausible block delays. To a point, transaction censorship just looks a failure to pay a sufficient feerate---so a node will probably fee bump a commitment/penalty transaction a few times before it starts to panic. Also to a point, a delay of up to several hours[2] just looks like regular stochastic block production. By using both deceits in the same attack to the maximum possible degree without triggering an alarm, an attacker can maximum their chance of stealing funds. -Dave [1] There is an interesting case where a large miner or cartel of miners could deliberately trigger a false positive of block delay protection by manipulating Median Time Past (MTP) to allow them to set their header nTime fields to values from hours or days ago. I don't believe the fix for the time warp proposed in the consensus cleanup soft fork fixes this, since it only directly affects the first block in a new difficulty period (preventing difficulty gaming but not header time gaming). This problem is partly mitigated by miners keeping MTP far in the past being unable to claim fees from recent time locked transactions (see BIP113), though I'm not sure how many transactions are actually using nLockTime-as-a-time (LN and anti-fee sniping use it as a height). [2] If we suddenly lose half of Bitcoin's hashrate so that the average time between blocks is 20 minutes, there's a once-in-a-century chance of a block taking more than 310 minutes to produce: 1 / (exp(-310/20) * 144 * 365) signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols
> The proposed countermeasure here of "raising alarms" in case the > best-block nTime field is too far behind is compelling in a > SPV-assumption world, though it is far from sufficient if the time delay > is small No that simple without interfering with IBD. While IBDing, alarms should be off to avoid raising false positives so attacker who succeeds to eclipse you before you synced to top won't raise it. And your validation software needs to remember than you're out of IBD to avoid being pinned back in the past, fallback to IBD and disable alarms. > This is useful if and only if the Bitcoin fullnode we use is differently eclisable from the Lightning node we use, e.g. the Bitcoin fullnode is openly on an IPv4 address while the Lightning node is on a Tor hidden service. I don't consider than your Lightning node is eclipsed. It needs further research but IMO it's harder to eclipse without detection on LN due to node pubkeys. And given than connectivity is cheaper than base layer (no per-peer inventories to maintain) if we have such header protocol, you should open connections to well-known LN pubkeys. Even if you assume an infrastructure attacker, given encrypted transport, it's hard to drop 80-bytes headers without tampering others messages and so being easily detected. Now how are you sure than LN pubkeys you get are the ones you intended to connect to ? That's an authenticity problem and not sure than copy-pasting from LN search engines is the best practice.. > I guess the sophisticated attacks try to trick the victim into believing that no attack is underway, but I may be wrong. Yes, a basic eclipse attack where you halt blocks update would be easily detectable. Eclipsing by discarding commitment/penalty txn still let CLTV/CSV time for the victim to react and you can't be sure than victim doesn't have a fallback way to broadcast tx. If well executed, attacks described stay stealth until it's too late to react. I think for analysis we should split detection from reaction, even if in practice we use same communication channel for both. Le sam. 14 déc. 2019 à 19:07, Orfeas Stefanos Thyfronitis Litos < o.thyfroni...@ed.ac.uk> a écrit : > I guess the sophisticated attacks try to trick the victim into believing > that no attack is underway, but I may be wrong. > > Orfeas > > On 14 December 2019 19:54:19 CET, "David A. Harding" > wrote: >> >> On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote: >> >>> Time-Dilation Attacks on Offchain Protocols >>> -- >>> >> >> What is the advantage of these sophisticated attacks over the eclipse >> attacker simply not relaying the honest user's commitment or penality >> transactions to miners? >> >> -Dave >> >> The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols
I guess the sophisticated attacks try to trick the victim into believing that no attack is underway, but I may be wrong. Orfeas On 14 December 2019 19:54:19 CET, "David A. Harding" wrote: >On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote: >> Time-Dilation Attacks on Offchain Protocols >> === > >What is the advantage of these sophisticated attacks over the eclipse >attacker simply not relaying the honest user's commitment or penality >transactions to miners? > >-Dave The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols
On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote: > Time-Dilation Attacks on Offchain Protocols > === What is the advantage of these sophisticated attacks over the eclipse attacker simply not relaying the honest user's commitment or penality transactions to miners? -Dave signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols
Nice writeup! In further in-person discussions today, it was noted that the key last-resort fallback Bitcoin Core has to week out peers in case of an Eclipse Attack does not protect from this style of attack. While it is only of limited concern for most Bitcoin Core users, it very much may expose lightning nodes to theft. More importantly, while Bitcoin Core has some protections against generic sybil-based Eclipse attacks, they are far from sufficient in a model like Lightning where much more is at stake from simple no-hashrate Eclipse attacks. The proposed countermeasure here of "raising alarms" in case the best-block nTime field is too far behind is compelling in a SPV-assumption world, though it is far from sufficient if the time delay is small (eg for lightning HTLC delays or if the to_self_delay is gratuitously insecure, eg under 144). Sadly, however, "raising alarms" is not sufficient to protect users, as countermeasures likely need to be taken automatically for any kind of compelling security. I'd encourage Lightning node authors and operators to ensure they have multiple, redundant, trusted methods of receiving Bitcoin block data in a timely fashion. To shill my own bags, of late I've been thinking about such systems and expose services to fetch header/BIP157 filter data over DNS [1, 2], header data over arbitrary radio interfaces [3] and full block data over HTTP. Finally, there is also a parallel P2P implementation which attempts to make different tradeoffs from the existing Bitcoin Core P2P implementation and is much more aggressive about seeking additional connections if there is evidence of headers which are better than our current chain at [5], relying on some of the other mechanisms to seek header data. Note that the Bitcoin Core-based work here also includes what I hope can be used as an arbitrary easy-to-write-additional-block-fetch-methods framework. [1] https://github.com/bitcoin/bitcoin/pull/16834 [2] https://twitter.com/TheBlueMatt/status/1200585905163112449 [3] https://github.com/TheBlueMatt/bitcoin/commit/2019-10-rusty-all-da-stuff%5E1 you should be able to pick up headers in the 915 MHz band over LoRa with this patch in the New York City area already :) [4] https://github.com/bitcoin/bitcoin/pull/16762 [5] https://github.com/bitcoin/bitcoin/pull/17376 Matt On 12/9/19 6:04 PM, Antoine Riard wrote: > Time-Dilation Attacks on Offchain Protocols > === > > Lightning works on reversing the double-spend problem to a private > state between parties instead of being a public issue verified by every > network peer. The security model is based on revocation of previous > states and in case of broadcast of any of them, being aware of it to > generate justice transactions to claim misbehaving peer onchain outputs > before contest period expiration. This period is driven by the blockchain > which is here the system clock. > > Eclipse attacks's end-goal is to monopolize a victim's incoming and > outgoing connections, by this way isolating a node from the rest of its > peers in the network. A successful Eclipse attacks lets the attacker > filter the victim's view of the blockchain, i.e he controls transactions > and blocks announcements [0]. > > Every LN node must be tied to a bitcoin full-node or light-client to > verify independently channels opening/closing, HTLCs expiration and > previous/latest state broadcast. To operate securely, the view of the > blockchain must be up-to-date with the one shared with the rest of the > network. By considering Eclipse attacks on the base layer, this assumption > can be broken. > > First scenario : Targeting the CSV security delay > -- > > Alice and Mallory are LN peers with a channel opened at state N. They > use a CSV of 144 blocks as a security parameter for contestation period. > Mallory is able to identify Alice full-node and start to eclipse it. > When done, it keeps announcing blocks to Alice node but delaying them by > 2min. Given a variance of 10min, after 6 blocks, Mallory will have a > height ahead of Alice of 1, after 24 blocks, a lead of 4, after 144, > a lead of 24, after 1008, a lead of 168. > > After maintaining the eclipse for a week, Mallory will have more than a > day of height advance on Alice view of blockchain. The difference being > superior at the CSV timelock, Mallory can broadcast a previous > commitment transaction at state N - 10 with a balance far more favorable > than the legit one at height H, the synchronized height with the rest > of the network. > > At revoked commitment transaction broadcast, Alice is slow down at > height H - 168. At H+144, Mallory can unlock its funds out of the > commitment transaction outputs and by so closing the contestation period > while Alice is still stuck at H-24. When Alice learn about revoked > broadcast at H, it's already too late. Mallory may have stopped the > Eclipse attack after
