Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-01 📝 Original message: Hi Alex, Let's say the ...
📅 Original date posted:2022-09-01
📝 Original message:
Hi Alex,
Let's say the adversary targeting your high-value "LiFi" infrastructure is
a nation-state sponsored hacking-group with strong capabilities (as we're
seeing today in the cryptocurrencies DeFi space). This hacking group avails
hundreds of bitcoins to fund channels, is able to setup thousands of sybil
peers across the base-layer p2p network, has built a fine-grained knowledge
of the miner mempools, controls few Internet ASNs and has bought
second-hands mining chips on the market to own limited hashing capabilities.
As of today, they would have a marked embarrassment on which attack pickup
to target your Lightning infrastructure. They could start with an "old
known" jamming attack to permanently cut your channel links from the rest
of the wider network topology [0].
Or they could launch time-dilation attacks by building on BGP disruptions,
until your chain view is so far in the past from the network tip that your
on-chain HTLC-claiming safety reaction timers are useless [1]. Or they
could exercise pinning attacks to prevent you to claim back routed HTLC, as
a malicious commitment transaction sleeps in the network mempools until
it's too far [2]. Or they could target your pre-0.24 Bitcoin Core
full-node to provoke a memory crash thanks to a long-chain of low-work
headers [3].
And I would say that's only a subset of the attack surface of a Lightning
node.
Considering all those factors, moving a LN implementation architecture from
a single, monolithic process towards a collection of processes, where the
critical components of the LN active defense security model are replicated
and distributed, redundant access to the chain view guaranteed, sandboxing
access between processes enforced and data flow monitored to react on
anomalies, all things your #6843 would make easier, sounds a reasonable
direction. I think it's needed if you aim for your infrastructure to
survive strong attacks.
On the LDK-side, inheriting from the adversarial thinking and safety-first
mindset development culture from Bitcoin Core, we've always considered that
type of scenarii since the early days and designed our software in
consequence. We have been working and we'll keep working on many
security/safety hardening: external signing [4], replicated chain
monitoring [5], dynamic fee-bumping of time-sensitive transactions, various
attack vectors mitigations [6]. All that said, we're looking forward to
collaborate with the wider Lightning community on reusable security modules
across implementations (e.g jamming mitigations) and wished
"fix-the-annoying-holes" changes in Bitcoin Core (e.g package relay).
Cheers,
Antoine
[0] https://jamming-dev.github.io/book/
[1] https://arxiv.org/abs/2006.01418
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
[3] https://github.com/bitcoin/bitcoin/pull/25717
[4] https://github.com/lightningdevkit/rust-lightning/pull/214
[5] https://github.com/lightningdevkit/rust-lightning/pull/679
[6] https://github.com/lightningdevkit/rust-lightning/pull/1009
Le jeu. 1 sept. 2022 à 13:56, Alex Akselrod via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> At NYDIG, we're considering ways to harden large LND deployments. Joost
> and I discussed that currently, when external untrusted peers make inbound
> connections, LND must verify the identity of the peer during the noise
> handshake, and it must do this before enforcing any potential key-based
> allow lists. This is done in the same process as the node's other critical
> tasks, such as monitoring the chain.
>
> To reduce the attack area of the main node process, we'd like to propose a
> means to optionally separate the peer communication into a separate
> process: something like CLN's connectd, running separately, and the
> connections would be multiplexed over a single network connection initiated
> from the node to the proxy. The core of our current idea is demonstrated in
> a draft PR: https://github.com/lightningnetwork/lnd/pull/6843
>
> I'd love some early feedback on the general direction of this. If this
> would be interesting, I'll build it out into a fully working feature.
>
> Thanks,
>
> Alex Akselrod
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220901/d81ca8c8/attachment-0001.html>;
📝 Original message:
Hi Alex,
Let's say the adversary targeting your high-value "LiFi" infrastructure is
a nation-state sponsored hacking-group with strong capabilities (as we're
seeing today in the cryptocurrencies DeFi space). This hacking group avails
hundreds of bitcoins to fund channels, is able to setup thousands of sybil
peers across the base-layer p2p network, has built a fine-grained knowledge
of the miner mempools, controls few Internet ASNs and has bought
second-hands mining chips on the market to own limited hashing capabilities.
As of today, they would have a marked embarrassment on which attack pickup
to target your Lightning infrastructure. They could start with an "old
known" jamming attack to permanently cut your channel links from the rest
of the wider network topology [0].
Or they could launch time-dilation attacks by building on BGP disruptions,
until your chain view is so far in the past from the network tip that your
on-chain HTLC-claiming safety reaction timers are useless [1]. Or they
could exercise pinning attacks to prevent you to claim back routed HTLC, as
a malicious commitment transaction sleeps in the network mempools until
it's too far [2]. Or they could target your pre-0.24 Bitcoin Core
full-node to provoke a memory crash thanks to a long-chain of low-work
headers [3].
And I would say that's only a subset of the attack surface of a Lightning
node.
Considering all those factors, moving a LN implementation architecture from
a single, monolithic process towards a collection of processes, where the
critical components of the LN active defense security model are replicated
and distributed, redundant access to the chain view guaranteed, sandboxing
access between processes enforced and data flow monitored to react on
anomalies, all things your #6843 would make easier, sounds a reasonable
direction. I think it's needed if you aim for your infrastructure to
survive strong attacks.
On the LDK-side, inheriting from the adversarial thinking and safety-first
mindset development culture from Bitcoin Core, we've always considered that
type of scenarii since the early days and designed our software in
consequence. We have been working and we'll keep working on many
security/safety hardening: external signing [4], replicated chain
monitoring [5], dynamic fee-bumping of time-sensitive transactions, various
attack vectors mitigations [6]. All that said, we're looking forward to
collaborate with the wider Lightning community on reusable security modules
across implementations (e.g jamming mitigations) and wished
"fix-the-annoying-holes" changes in Bitcoin Core (e.g package relay).
Cheers,
Antoine
[0] https://jamming-dev.github.io/book/
[1] https://arxiv.org/abs/2006.01418
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
[3] https://github.com/bitcoin/bitcoin/pull/25717
[4] https://github.com/lightningdevkit/rust-lightning/pull/214
[5] https://github.com/lightningdevkit/rust-lightning/pull/679
[6] https://github.com/lightningdevkit/rust-lightning/pull/1009
Le jeu. 1 sept. 2022 à 13:56, Alex Akselrod via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> At NYDIG, we're considering ways to harden large LND deployments. Joost
> and I discussed that currently, when external untrusted peers make inbound
> connections, LND must verify the identity of the peer during the noise
> handshake, and it must do this before enforcing any potential key-based
> allow lists. This is done in the same process as the node's other critical
> tasks, such as monitoring the chain.
>
> To reduce the attack area of the main node process, we'd like to propose a
> means to optionally separate the peer communication into a separate
> process: something like CLN's connectd, running separately, and the
> connections would be multiplexed over a single network connection initiated
> from the node to the proxy. The core of our current idea is demonstrated in
> a draft PR: https://github.com/lightningnetwork/lnd/pull/6843
>
> I'd love some early feedback on the general direction of this. If this
> would be interesting, I'll build it out into a fully working feature.
>
> Thanks,
>
> Alex Akselrod
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220901/d81ca8c8/attachment-0001.html>;