From c1.devrandom at niftybox.net Sun Jan 10 23:48:31 2021 From: c1.devrandom at niftybox.net (Devrandom) Date: Sun, 10 Jan 2021 15:48:31 -0800 Subject: [Lightning-dev] Battlement: A Quorum Based Design for Lightning Network Key Management In-Reply-To: <8DA5D760-60C0-41E3-9AB1-8AC3D9A2C838@gmail.com> References: <8DA5D760-60C0-41E3-9AB1-8AC3D9A2C838@gmail.com> Message-ID: 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 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: