From omer.shlomovits at gmail.com  Wed Dec 16 07:26:10 2020
From: omer.shlomovits at gmail.com (Omer Shlomovits)
Date: Wed, 16 Dec 2020 09:26:10 +0200
Subject: [Lightning-dev] Battlement: A Quorum Based Design for Lightning
 Network Key Management
Message-ID: <8DA5D760-60C0-41E3-9AB1-8AC3D9A2C838@gmail.com>

Hi list, 

Sharing here a project I started a while ago and recently managed to materialise in writing, 
In this work I decided to take the traditional cyber security approach, while assuming channels security is sound. 
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. 
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 deleting them or delete some keys while not been able to steal them.  We analyse the different scenarios and what an attacker can achieve - surprisingly it seems that due the the unique key structure and usage in lightning, it is not trivial how an attacker may profit from this situation (as opposed to bitcoin where any access to key material equal profit to an attacker). 

In the second part of the work we offer a quorum based design that mitigates the attacks. We use threshold cryptography for this. I believe this is one  viable solution but for sure not the only one and we discuss the tradeoffs. One nice thing about this approach is that it allows to somewhat re-use the existing watchtowers - we basically only require that watchtowers will become connected and run some new protocols. 

In the last part we present a simple bribing attack on the current watchtower design, and hand wave on how game theory shows that  a quorum structure like ours may provide a path to solving it. 

Link to the writeup is here: 
https://static1.squarespace.com/static/5f3a45dc0638305e031b7419/t/5fd877e477d7f03dcdb5b3f9/1608022219533/Battlement.pdf <https://static1.squarespace.com/static/5f3a45dc0638305e031b7419/t/5fd877e477d7f03dcdb5b3f9/1608022219533/Battlement.pdf>

The paper is written at a high level only so we will be able to focus on the several new ideas I mentioned above.  This work is thus far from complete: 
No formal security arguments are given and I avoid describing real world considerations like fee structure and parameters . 
I think however it is a good breaking point to share it and get some feedback.

All the best, 
Omer. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201216/f8f826e5/attachment.html>