Devrandom [ARCHIVE] on Nostr: 📅 Original date posted:2021-01-10 📝 Original message: Hi Omer, Thank you for ...

📅 Original date posted:2021-01-10
📝 Original message:
Hi Omer,

Thank you for raising the topic of quorum key management for Lightning. I
believe this approach is an important direction for securing Lightning
nodes. Please see comments below.

On Tue, Dec 15, 2020 at 11:26 PM Omer Shlomovits <omer.shlomovits at gmail.com>
wrote:

> The attacker model is intuitive: an attacker attacks a machine which
> happens to run a lightning node. The attacker is *not* part of the
> network.
>

Well, that's an assumption. :) In general, an attacker may also control
one or more peers, either because they compromised them or because they
initiated a connection to the target node.


> Usually the attacked machine/device will have security measures in place:
> write/read permissions for different users. Our assumption is that the
> attacker does not necessarily
>
achieve full control over the node but only *some* elevated access: it may
> have only read or only write access for example which means it can steal
> some keys while not
>

Also a significant assumption, since in many cases an attacker can
completely compromise a system. It would be a much stronger security
posture if we defended against this too. What is the motivation for these
assumptions? Did you feel it's too difficult to defend against arbitrary
compromise?

I also want to mention that there are many ways funds can be lost in
Lightning once we assume that the node software can be fully compromised.
I believe we can defend against all these, but it requires implementation
of a relatively large set of controls in the key management layer. In the
Lightning Signer project we attempt to enumerate these controls - see:
https://gitlab.com/lightning-signer/docs/-/blob/master/policy-controls.md

For example - one of the more complex policy controls is "HTLC receive
channel validity - the funding UTXO of the receive channel must be active
on-chain with enough depth". i.e. we have to check that routed HTLCs are
coming from a valid channel or we could have all funds siphoned off over
time.

Looking forward to further work on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210110/4dad4d0e/attachment.html>;