š
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>;
Devrandom [ARCHIVE] /
npub1j0ā¦w9k8n
2023-06-09 13:01:52
in reply to nevent1qā¦6z8r
Author Public Key
npub1j0js72tmnxzmrtd6j0j5wcvfuhsqwgqxdwkpmw28rmmuy22y3wzsdw9k8nPublished at
2023-06-09 13:01:52Event JSON
{
"id": "6a662d14b82fa38fd302dbe7709874effcbb50068991745aadff6386b9b2904e",
"pubkey": "93e50f297b9985b1adba93e5476189e5e00720066bac1db9471ef7c229448b85",
"created_at": 1686315712,
"kind": 1,
"tags": [
[
"e",
"b1557a5aa8d4a703580ae50c9a93d327382ca7b500bbcd99113edadcfde47e7b",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "š
Original date posted:2021-01-10\nš Original message:\nHi Omer,\n\nThank you for raising the topic of quorum key management for Lightning. I\nbelieve this approach is an important direction for securing Lightning\nnodes. Please see comments below.\n\nOn Tue, Dec 15, 2020 at 11:26 PM Omer Shlomovits \u003comer.shlomovits at gmail.com\u003e\nwrote:\n\n\u003e The attacker model is intuitive: an attacker attacks a machine which\n\u003e happens to run a lightning node. The attacker is *not* part of the\n\u003e network.\n\u003e\n\nWell, that's an assumption. :) In general, an attacker may also control\none or more peers, either because they compromised them or because they\ninitiated a connection to the target node.\n\n\n\u003e Usually the attacked machine/device will have security measures in place:\n\u003e write/read permissions for different users. Our assumption is that the\n\u003e attacker does not necessarily\n\u003e\nachieve full control over the node but only *some* elevated access: it may\n\u003e have only read or only write access for example which means it can steal\n\u003e some keys while not\n\u003e\n\nAlso a significant assumption, since in many cases an attacker can\ncompletely compromise a system. It would be a much stronger security\nposture if we defended against this too. What is the motivation for these\nassumptions? Did you feel it's too difficult to defend against arbitrary\ncompromise?\n\nI also want to mention that there are many ways funds can be lost in\nLightning once we assume that the node software can be fully compromised.\nI believe we can defend against all these, but it requires implementation\nof a relatively large set of controls in the key management layer. In the\nLightning Signer project we attempt to enumerate these controls - see:\nhttps://gitlab.com/lightning-signer/docs/-/blob/master/policy-controls.md\n\nFor example - one of the more complex policy controls is \"HTLC receive\nchannel validity - the funding UTXO of the receive channel must be active\non-chain with enough depth\". i.e. we have to check that routed HTLCs are\ncoming from a valid channel or we could have all funds siphoned off over\ntime.\n\nLooking forward to further work on this.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210110/4dad4d0e/attachment.html\u003e",
"sig": "db59fca46320f9a4fb67ba8221f2229984367956c202346267227eb8f5f3c5ba6894156fb08765830ed92d97db009b62c8adb875dccbeaae33db5dd057fa4341"
}