Antoine Riard [ARCHIVE] on Nostr: ð Original date posted:2019-12-09 ð Original message: Time-Dilation Attacks on ...
ð
Original date posted:2019-12-09
ð Original message:
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 H+144, or he may pursue the attack on Alice because
of targeting multiple of her channels in parallel.
Second scenario : Targeting the per-hop CLTV-delta
-------------------------------------------------------------------
Alice, Bob and Caroll are LN peers with channel Alice-Bob and Bob-Caroll.
Bob enforce a cltv_delta of 12 blocks on incoming HTLCs. Alice and Caroll
are both malicious and start to eclipse Alice full-node until they gain a
lead of 15 blocks on Alice.
At height N, Alice route a payment E to Caroll through Bob with a base
delta of 24 blocks. On channel AB, HTLC will expire at height H+24, on
channel BC, it will expire at height H+12 while Alice ticking herself
at height H-15.
When real-network blockchain height reaches H+24, Caroll provides
preimage P to Bob and following protocol rules she gets a new
commitment transaction with balance increased of HTLC E. At same time,
Alice broadcast unilaterally commitment transaction for AB and claim
back HTLC E with a HTLC-timeout transaction as its nLockTime is already
final. Bob wrongly clocking at height H+9, HTLC on channel BC won't have
been timeout by him and provided preimage is now useless as HTLC as
already claimed back on mainnet blockchain.
Attack difficulty
-------------------
Following Eclipse attack paper publication, multiple counter-measures
have been implemented [1], [2]. Even if it's far harder, this kind of
attacks may still be possible for an off-path attacker. Including recent
changes, research should be done to ascertain it. Beyond, it still
widely feasible for attackers controlling key infrastructure between
the victim and the network [3]. A simple Tier 3 ISP doing deep packet
inspection and delaying your blocks may be able to practice this class
of attacks.
The case of LN nodes using light clients, like BIP157 or Electrum, as a
backend should be specially considered. Given the low number of servers
providing these services today it should be trivial for an attacker to run
swarm of them and from then control blockchain view of this class of LN
nodes.
Another difficulty of the attack, is to map the LN node to its full-node.
This can range from being trivial if both run in clear with same ipv4
address. It would be interesting to scan both networks and see how many
nodes pair are in this case. Learning the mapping can still be doable if
they are using an anonymous network like Tor with same exit node base on
message timing.
Further inter-layer mapping techniques could be developped like funding
transaction broadcast and seeing its propagation on the base layer. Or
knowledge of onchain utxo graph leaked by addressed reused to fund
channels.
On the LN-side, depending of the scenario, cost of the attack ranges
between opening one or two channels and paying the related onchain fees.
That being said, an attacker can also target victim-initiated channels
and costs would be reduced only to operating LN nodes.
Onchain counter-measures
-----------------------------------
Warnings could be triggered by full-node when the block issuance rate
becomes weird but first it's hard to dissociate weirdness from edges of
block variance and secondly the algo being public it should be easy for
an attacker to stay under the radar by choosing the right announcement
delay.
Raising alarms based on nTime of block headers being to far in the past
compare to local clock wouldn't make sense due to IBD.
A practical solution would be to have multiple bitcoin full-nodes
with multi-homing and doing reconciliation of blockchain views every
N hour/minute. This kind of method, already deployed by some bitcoin
infrastructures, would raise attack difficulty for off-path attackers
but wouldn't counter in-path attackers. Nevertheless, it would already
be a good step, the issue is the current absent of implementing this
in open-source software for hobbyists.
A defense in depth would require to have multiple data links, like
receiving headers from space/radio or tunneling through
some other protocols [4].
Even learning discrepancies between your local view of the blockchain
and the mainnet one, the right move to do isn't clear as an automatic
system may be triggered by false positives to halt operation of your LN
node, a human intervention to double-check may seem preferable. And
it's really likely the attacker control you ability of transactions
on the base layer. BIP324 may help there.
Offchain counter-measures
-----------------------------------
Some LN errors messages may be triggered at abnormal rate like
`expiry_too_soon` due to victim using a HTLC base in the past and may
be used to guess oddities.
A measure orthogonal to running multiple bitcoin full-nodes should be
to have multiples watchtowers running their own blocks provider (full-node
or light clients). Assuming attacker don't control your connection to them,
if at least one of them isn't eclipsed, it should be able to time-out HTLC/
justice revoked transaction efficiently.
Another option would be to use the control plane as a safety mechanism.
When a LN node learns a channel_announcement to far in the future it
would ask to this LN node, few next headers through this communication
channel and connect these headers to its full-node. Based on this
information, full-node may trigger alarms more accurately. This mechanism
would work assuming one of your gossiping LN node is honest. It may ask
for fine-tuning to avoid there too false-positives but it seems an
interesting topic of research to use L2 information to correct L1 blockchain
view and even further to use L2 communications channels as an emergency
transaction broadcast.
Further research could be lead to investigate attacks combining eclipsing
victim
view of both layer, that's said the LN one may seem harder to take on as
nodes
have persistent identities.
Eclipse attacks were already known to be very bad, offchain protocols
relying on time for their security model make them worst at it lower the bar
to exploit them from being a miner to being party to an offchain contract.
After talking with LN implementations teams, they don't think funds are at
risks,
given than light clients have low-value channels right now and it's not
worthy the
attack setup, but they acknowledge the issue on the long term for
processing nodes.
Thanks to Gleb Naumenko for fruitful discussions/review.
Cheers
[0] https://eprint.iacr.org/2015/263.pdf
[1] https://github.com/bitcoin/bitcoin/pull/9037
[2] https://github.com/bitcoin/bitcoin/pull/8282
[3] https://erebus-attack.comp.nus.edu.sg/
[4] https://github.com/bitcoin/bitcoin/pull/16834
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191209/cd6947dc/attachment.html>;
ð Original message:
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 H+144, or he may pursue the attack on Alice because
of targeting multiple of her channels in parallel.
Second scenario : Targeting the per-hop CLTV-delta
-------------------------------------------------------------------
Alice, Bob and Caroll are LN peers with channel Alice-Bob and Bob-Caroll.
Bob enforce a cltv_delta of 12 blocks on incoming HTLCs. Alice and Caroll
are both malicious and start to eclipse Alice full-node until they gain a
lead of 15 blocks on Alice.
At height N, Alice route a payment E to Caroll through Bob with a base
delta of 24 blocks. On channel AB, HTLC will expire at height H+24, on
channel BC, it will expire at height H+12 while Alice ticking herself
at height H-15.
When real-network blockchain height reaches H+24, Caroll provides
preimage P to Bob and following protocol rules she gets a new
commitment transaction with balance increased of HTLC E. At same time,
Alice broadcast unilaterally commitment transaction for AB and claim
back HTLC E with a HTLC-timeout transaction as its nLockTime is already
final. Bob wrongly clocking at height H+9, HTLC on channel BC won't have
been timeout by him and provided preimage is now useless as HTLC as
already claimed back on mainnet blockchain.
Attack difficulty
-------------------
Following Eclipse attack paper publication, multiple counter-measures
have been implemented [1], [2]. Even if it's far harder, this kind of
attacks may still be possible for an off-path attacker. Including recent
changes, research should be done to ascertain it. Beyond, it still
widely feasible for attackers controlling key infrastructure between
the victim and the network [3]. A simple Tier 3 ISP doing deep packet
inspection and delaying your blocks may be able to practice this class
of attacks.
The case of LN nodes using light clients, like BIP157 or Electrum, as a
backend should be specially considered. Given the low number of servers
providing these services today it should be trivial for an attacker to run
swarm of them and from then control blockchain view of this class of LN
nodes.
Another difficulty of the attack, is to map the LN node to its full-node.
This can range from being trivial if both run in clear with same ipv4
address. It would be interesting to scan both networks and see how many
nodes pair are in this case. Learning the mapping can still be doable if
they are using an anonymous network like Tor with same exit node base on
message timing.
Further inter-layer mapping techniques could be developped like funding
transaction broadcast and seeing its propagation on the base layer. Or
knowledge of onchain utxo graph leaked by addressed reused to fund
channels.
On the LN-side, depending of the scenario, cost of the attack ranges
between opening one or two channels and paying the related onchain fees.
That being said, an attacker can also target victim-initiated channels
and costs would be reduced only to operating LN nodes.
Onchain counter-measures
-----------------------------------
Warnings could be triggered by full-node when the block issuance rate
becomes weird but first it's hard to dissociate weirdness from edges of
block variance and secondly the algo being public it should be easy for
an attacker to stay under the radar by choosing the right announcement
delay.
Raising alarms based on nTime of block headers being to far in the past
compare to local clock wouldn't make sense due to IBD.
A practical solution would be to have multiple bitcoin full-nodes
with multi-homing and doing reconciliation of blockchain views every
N hour/minute. This kind of method, already deployed by some bitcoin
infrastructures, would raise attack difficulty for off-path attackers
but wouldn't counter in-path attackers. Nevertheless, it would already
be a good step, the issue is the current absent of implementing this
in open-source software for hobbyists.
A defense in depth would require to have multiple data links, like
receiving headers from space/radio or tunneling through
some other protocols [4].
Even learning discrepancies between your local view of the blockchain
and the mainnet one, the right move to do isn't clear as an automatic
system may be triggered by false positives to halt operation of your LN
node, a human intervention to double-check may seem preferable. And
it's really likely the attacker control you ability of transactions
on the base layer. BIP324 may help there.
Offchain counter-measures
-----------------------------------
Some LN errors messages may be triggered at abnormal rate like
`expiry_too_soon` due to victim using a HTLC base in the past and may
be used to guess oddities.
A measure orthogonal to running multiple bitcoin full-nodes should be
to have multiples watchtowers running their own blocks provider (full-node
or light clients). Assuming attacker don't control your connection to them,
if at least one of them isn't eclipsed, it should be able to time-out HTLC/
justice revoked transaction efficiently.
Another option would be to use the control plane as a safety mechanism.
When a LN node learns a channel_announcement to far in the future it
would ask to this LN node, few next headers through this communication
channel and connect these headers to its full-node. Based on this
information, full-node may trigger alarms more accurately. This mechanism
would work assuming one of your gossiping LN node is honest. It may ask
for fine-tuning to avoid there too false-positives but it seems an
interesting topic of research to use L2 information to correct L1 blockchain
view and even further to use L2 communications channels as an emergency
transaction broadcast.
Further research could be lead to investigate attacks combining eclipsing
victim
view of both layer, that's said the LN one may seem harder to take on as
nodes
have persistent identities.
Eclipse attacks were already known to be very bad, offchain protocols
relying on time for their security model make them worst at it lower the bar
to exploit them from being a miner to being party to an offchain contract.
After talking with LN implementations teams, they don't think funds are at
risks,
given than light clients have low-value channels right now and it's not
worthy the
attack setup, but they acknowledge the issue on the long term for
processing nodes.
Thanks to Gleb Naumenko for fruitful discussions/review.
Cheers
[0] https://eprint.iacr.org/2015/263.pdf
[1] https://github.com/bitcoin/bitcoin/pull/9037
[2] https://github.com/bitcoin/bitcoin/pull/8282
[3] https://erebus-attack.comp.nus.edu.sg/
[4] https://github.com/bitcoin/bitcoin/pull/16834
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191209/cd6947dc/attachment.html>;