WIP: Security and Privacy of the Lightning network#524
WIP: Security and Privacy of the Lightning network#524aantonop merged 16 commits intolnbook:developfrom
Conversation
|
Related to #400 |
a812170 to
ff0ca46
Compare
security_privacy_ln.asciidoc
Outdated
|
|
||
| * No risk: do not accept any incoming channels; | ||
| * Low risk: only accept channels from nodes that have been present in the graph for a longer period, and have some long-lived channels; | ||
| * Medium risk: only accept channels from |
add linebreak before unnumbered list add (short) section on payment amounts add section on definitions of privacy add section on anonymity set fix a few typos add section on privacy in LN vs Bitcoin
Added "Cross-Layer Deanonymization" section Started the Topology-related section
2dae9cd to
44cea84
Compare
carlaKC
left a comment
There was a problem hiding this comment.
Nice to read all of this coming together!
| The important properties of the Lightning Network are mostly centered around confidentiality and availability. | ||
| Here are some of the properties we may want to ensure: | ||
|
|
||
| * nobody except the sender and the receiver knows the payment amount |
There was a problem hiding this comment.
should these be capitalized?
|
|
||
| * nobody except the sender and the receiver knows the payment amount | ||
| * nobody can link senders and receivers | ||
| * nobody can block an honest user from sending and receiving payments |
There was a problem hiding this comment.
nit: if we are going to refer to CIA here, then mention HMAC/that people can't meddle with the integrity of payments/messages that nodes send
security_privacy_ln.asciidoc
Outdated
| Such an adversary might seem convoluted. | ||
| However, the single most central node can already observe close to 50% of all LN payments, while the four most central nodes observe an average of 72% payments. |
There was a problem hiding this comment.
Flatten these into one sentence?
| In that case, Alice is unable to forward the payment and returns the "insufficient balance" error to Mallory. | ||
| Mallory updates her estimation from "between zero and 1 million" to "between zero and 500 thousand." | ||
|
|
||
| Note that in any case, Mallory's estimation becomes twice as precise after just one probing! |
There was a problem hiding this comment.
This is a great paragraph 🕺
| Remember that regular nodes don't know balance distributions in remote channels. | ||
| Therefore, payments can (and often do) fail because of insufficient balance at an intermediary hop. | ||
| Error messages allow the sender to exclude the failing channel from consideration when constructing another route. | ||
| A popular Lightning wallet Zap even performs probing internally to check whether a constructed route can really handle a payment. |
There was a problem hiding this comment.
Safe to say that many applications do this, it's not just zap
|
|
||
| References: | ||
|
|
||
| * Mizrahi, A., Zohar, A. https://arxiv.org/abs/2002.06564[Congestion Attacks in Payment Channel Networks] |
There was a problem hiding this comment.
I think there's another paper I need to link here, anybody remember one specifically about liquidity lockup?
| While the public announcement of IP addresses may be unavoidable for those nodes that wish to have incoming channels in the LN, linkability across nodes of the same user can be mitigated if the clients for each node are hosted with different service providers and thus IP addresses. | ||
|
|
||
| *Cross-Layer Linking: Lightning Nodes and Bitcoin Entities* | ||
| Associating LN nodes to Bitcoin entities is a serious breach of privacy that is exacerbated by the fact that most LN nodes publicly expose their IP addresses. |
There was a problem hiding this comment.
Isn't the biggest threat here eclipse attacks on the bitcoin node?
|
Dear authors: @renepickhardt, @Roasbeef and @aantonop! We are ready with our first feature-full draft. We would greatly appreciate if you could have a review of this chapter. Please let us know your thoughts, comments, critique! :) |
|
We are reviewing! Thank you @seresistvanandras and others |
Roasbeef
left a comment
There was a problem hiding this comment.
Chunking my review a bit to avoid a massive dump of comments, will likely have 2/3 more review chunks to complete my final pass.
My initial impression though is that this is an amazing document, and I don't think there exists another comparable approachable single piece of writing that attempts to approach security+privacy of LN from a similarly objective angle. Amazing contribution!
| Then, they describe the relevant properties of the system and check whether it conforms to the requirements. | ||
| A security model is based on a set of underlying _security assumptions_. | ||
| In cryptographic systems, they are often centered around the mathematical properties of the cryptographic primitives such as ciphers, signatures, and hash functions. | ||
| The security assumptions of the Lightning Network are that the ECDSA signatures, SHA-256 hash function, and other cryptographic functions used in the protocol behave within their security definitions. |
There was a problem hiding this comment.
Only an intro paragraph, but I think one thing worth mentioning here is that since LN is a networked protocol, any security model must also factor in how interaction with the network and also topological constraints affect the privacy of the network. As an example, since we use an onion routing protocol for HTLC extension, we by default don't assume "protection" against a global passive adversary, as such an adversary can use packet+timing information to deduce payment flows.
| A regular "honest-but-curious" forwarding node can observe payment amounts, the immediately preceding and following nodes, the graph of announced channels with their capacities. | ||
| A very well-connected node can do the same but to a larger extent. | ||
| For example, consider the developers of a popular wallet who maintain a node that their users connect to by default. | ||
| This node would be responsible for routing a large share of payments to and from the users of that wallet. |
There was a problem hiding this comment.
I think there's an implicit/missing conclusion here? Seems y'all intend to convey that this wallet author learns information about the payments/patterns of each user that they serve?
|
|
||
| An attacker might be interested in learning the sender and/or the receiver of a payment to reveal certain economic relationships. | ||
| This breach of privacy could harm censorship resistance, as an intermediary node could censor payments to or from certain receivers or senders. | ||
| Ideally, linking senders to receivers should not be possible to peers other than the sender and the receiver. |
There was a problem hiding this comment.
Yep, such techniques can allow us to achieve sender-receiver privacy (sender doesn't know the true node ID of the receiver, the reverse already exists as is).
| In the first step of this attack scenario, a potent off-path adversary deduces the individual balances in each payment channel via probing (described in a subsequent section) and forms a network snapshot at time _t_. | ||
| It then runs the attack sometime later at time _t'_ and uses the differences between the two snapshots to infer information about payments that took place by looking at paths that have changed. | ||
| In the simplest case, if only a single payment occurred between time _t'_ and _t_, the adversary observes a single path where the balances have changed by the same amounts. | ||
| Thus, the adversary learns everything about this payment: the sender, the recipient, and the amount. |
There was a problem hiding this comment.
Though it's a simple model, I think this should also mention the existence of unadvertised channels as well, and the potential that a "shadow" network exists beyond the graph view of this attacker.
| Therefore, the payment will fail. | ||
| The question is: how exactly will it fail? | ||
|
|
||
| There are two scenarios. |
There was a problem hiding this comment.
Simplified example, but this is missing a bit of nuance re the existence of the channel level flow control constraints that may be slightly out of sync with the advertised routing constraints. As an example, let's say a channel only allows 5 HTLCs for w/e reason in this case when a prober attempts to attach a 6th HTLC, they'll get a "temp chan failure" even though the channel may have had sufficient bandwidth to carry the channel.
Another value to consider is the max_htlc setting, which may not allow a prober to deduce the full available bandwidth amount in the channel in a single go.
| There are two known DoS attacks on public Lightning channels which render a target channel, or a set of target channels, unusable. | ||
| Both attacks involve routing payments through a public channel, then holding them until their timeout, thus maximizing the attack's duration. | ||
| The requirement to fail payments to not pay fees is fairly simple to meet because malicious nodes can simply reroute payments to themselves. | ||
| In the absence of fees for failed payments, the only cost to the attacker is the on-chain cost of opening a channel to dispatch these payments through, which can be trivial in low fee environments. |
There was a problem hiding this comment.
The cost also includes worst case closing 2x the channels (if they're doing it via circular routes), and also the opportunity cost of the Bitcoin they need to put into channels to launch the attack.
| A channel jamming attack allows an attacker to render a channel unusable by routing 483 payments through the target channel and holding them until they timeout. | ||
|
|
||
| It should be noted that this limit is arbitrary and was chosen in the specification to ensure that all the HTLCs can be swept in a https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md#penalty-transaction-weight-calculation[single justice transaction]. | ||
| While this limit _may_ be increased, transactions are still limited by the block size, so the number of slots available is likely to remain limited. |
There was a problem hiding this comment.
One missing component here is that it's possible to essentially lift this limit (by using indirect commitments), instead letting nodes manage the free HTLC slots as if they were space in a queue. Modern implementations also feature something commonly referred to as an "HTLC interceptor" that allows them to make accept/deny decisions based on the current channel state. In a sense, the problem is similar to TCP congestion control/avoidance and buffer bloat itself.
| If the same IP or Tor addresses correspond to different LN nodes, these nodes are likely controlled by the same user. | ||
|
|
||
| _Countermeasures_: For more privacy, aliases should be sufficiently different from one another. | ||
| While the public announcement of IP addresses may be unavoidable for those nodes that wish to have incoming channels in the LN, linkability across nodes of the same user can be mitigated if the clients for each node are hosted with different service providers and thus IP addresses. |
There was a problem hiding this comment.
Tor also goes a long way here given that onion services addresses are effectively infinite, while IPv4 adresses are still scarce.
| On the other hand, the adversary could be more stealthy. | ||
| Several topology-based attacks target a single node or a single payment channel. | ||
| For example, an adversary might be interested in exhausting a certain payment channel's capacity on purpose. | ||
| More generally, an adversary can deplete all the outgoing capacity of a node to knock it down from the routing market. |
There was a problem hiding this comment.
How so? Outgoing capacity is only "shifted around" and never really depleted in a sense. Also users are able to disable certain chanenls to protect the outgoing capacity of those channels.
| As a result, incentives drive graph development. | ||
| Let's describe some of the relevant incentives: | ||
|
|
||
| * Rational incentives. |
There was a problem hiding this comment.
A new incentive comes in the form of Lightning Pool: aside from the potential to earn routing fees, nodes are also able to earn passive yield simply by allocating capital to the network where it's most demanded.
| While mitigations are being developed on the protocol level, there are many steps that a node can take to protect against denial of service attacks on their public channels. | ||
|
|
||
| * Minimum HTLC size: on channel open, your node can set the minimum HTLC size that it will accept. | ||
| Setting a higher value ensures that each of your available channel slots cannot be occupied by a very small payment. |
There was a problem hiding this comment.
Another related setting here is max_htlc, which can be used to help mitigate probing attacks somewhat, and also let a node control the exposure it'll have to a given payment flow.
| For example, consider the developers of a popular wallet who maintain a node that their users connect to by default. | ||
| This node would be responsible for routing a large share of payments to and from the users of that wallet. | ||
| An even stronger security model implies that multiple nodes are under adversarial control. | ||
| If it so happens that two colluding nodes are on the same payment path, they would understand that they are forwarding HTLCs belonging to the same payment, as such HTLCs have the same payment hash. |
There was a problem hiding this comment.
"if it so" is strange
| If it so happens that two colluding nodes are on the same payment path, they would understand that they are forwarding HTLCs belonging to the same payment, as such HTLCs have the same payment hash. | |
| If two colluding nodes are on the same payment path, they would understand that they are forwarding HTLCs belonging to the same payment, as such HTLCs have the same payment hash. |
| This allows nodes to costlessly route failed payments through any channels. | ||
| This is great for legitimate users, who wouldn't like to pay for failed attempts, but also allows attackers to costlessly consume nodes' resources - much like the low-fee transactions on Bitcoin that never end up paying miner fees. | ||
|
|
||
| At the time of writing, a discussion is https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002734.html[ongoing] on the lightning-dev mailing list as to how best address this issue. |
There was a problem hiding this comment.
Specifying timing twice is redundant. Also added a to.
| At the time of writing, a discussion is https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002734.html[ongoing] on the lightning-dev mailing list as to how best address this issue. | |
| A discussion is https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002734.html[ongoing] on the lightning-dev mailing list as to how best to address this issue. |
| Integrity implies that the information does not get altered in transit. | ||
| Availability ensures that users may expect the system to be functioning most of the time. | ||
|
|
||
| The important properties of the Lightning Network are mostly centered around confidentiality and availability. |
There was a problem hiding this comment.
Why? Is is because integrity comes out of the box? If so, it's worth mentioning.
|
|
||
| * nobody except the sender and the receiver knows the payment amount | ||
| * nobody can link senders and receivers | ||
| * nobody can block an honest user from sending and receiving payments |
There was a problem hiding this comment.
This third one belongs to availability, while the first two to confidentiality, so I think these should not be in the same list.
| While this improves the privacy baseline, other properties of the Lightning protocol may make anonymous payments more challenging. | ||
| For instance, larger payments have fewer routing options. | ||
| This may allow an adversary who controls well-capitalized nodes to route most large payments and discover payment amounts and probably other details. | ||
| Another relevant difference between Lightning and Bitcoin is that Lightning nodes maintain a permanent identity, whereas Bitcoin nodes do not. |
There was a problem hiding this comment.
Although Bitcoin nodes do not assume a permanent identity, wallet clustering achieves similar outcomes for wallets without/under utilized/or ineffective privacy techniques.
| A Lightning user, when sending a payment, has its neighbors in its anonymity set. | ||
| Specifically, a routing node only knows the immediately preceding and following nodes. | ||
| The routing node does not know whether its immediate neighbors in the payment route are the ultimate sender or receiver. | ||
| Therefore, the anonymity set of a node in Lightning roughly equals its neighbors. |
There was a problem hiding this comment.
Not sure about this statement. Researchers are trying to fit the onion routing into their anonymity set (entropist) models with little success: https://www.freehaven.net/anonbib/cache/entropist.pdf
Starting from an entropist conception of anonymity has led to a focus on system properties that are not the most important to system security, has led to system assumptions that are not reasonable in practice, has led to adversary models that are not reasonable in practice, and has led to both theory and system design for anonymous communication that fail in significant ways.
| It then runs the attack sometime later at time _t'_ and uses the differences between the two snapshots to infer information about payments that took place by looking at paths that have changed. | ||
| In the simplest case, if only a single payment occurred between time _t'_ and _t_, the adversary observes a single path where the balances have changed by the same amounts. | ||
| Thus, the adversary learns everything about this payment: the sender, the recipient, and the amount. | ||
| If multiple payment paths overlap, the adversary needs to apply heuristics to identify such overlap and separate the payments. |
There was a problem hiding this comment.
Since my LN knowledge is quite lacking, I can't claim to fully understand what's going on here, but I created some illustration to make it easier for the reader to grasp the basic concept at least. If you want to add it or create something similar incorporating the amount attack itself that could be helpful to improve my understanding without reading the rest of the book.
| An on-path adversary can log for every routed payment along with the amount of time it takes for a node to respond to an HTLC request. | ||
| Before starting the attack, the attacker learns every node's latency characteristics in the Lightning Network by sending them requests. | ||
| Naturally, this can aid in establishing the adversary's precise position in the payment path. | ||
| Even more, as it was recently shown, an attacker can successfully determine the sender and the receiver of a payment from a set of possible senders and receivers using time-based estimators. |
There was a problem hiding this comment.
Maybe make this statement timeless? You don't know when the reader will read this and unlike a research paper, this work evolves, so unless the reader has a git blame at hand he won't be able to tell what "recently" means.
| Even more, as it was recently shown, an attacker can successfully determine the sender and the receiver of a payment from a set of possible senders and receivers using time-based estimators. | |
| Even more, an attacker can successfully determine the sender and the receiver of a payment from a set of possible senders and receivers using time-based estimators. |
nopara73
left a comment
There was a problem hiding this comment.
Great chapter, I've learnt a lot from it! General suggestions:
- It would greatly help my understanding if it'd have a lot more illustration.
- It reads more like a research paper, rather than a book. I'm not sure if it's consistent with the rest of the book.
Co-authored-by: nopara73 <adam.ficsor73@gmail.com>
Absolutely agree. Would be nice if @Roasbeef @renepickhardt and @aantonop could tell us where it would be necessary to amend the text with more illustrations. Then, we could iterate on those figures right away before it gets too late. |
|
This is a great thread ! I wanna to do a review but I'm not sure about the breath/depth you're aiming for ? The privacy section is pretty awesome. It's really thoughtful to talk about cross-layer linking (sadly you have far more heuristics than the ones already detailed...). Maybe a privacy framework should include LN nodes taxonomy (leafs, routing, merchants), it's likely you can observe a lot from their behavior patterns. Also risks of privacy leaks backfire on L1 coins, if utxos context-switches aren't well handled by your wallet. On the security, it sounds limited to channel-jamming at the network level and doesn't mention other integrity concerns like channel/HTLC steals vectors, timevalue DoS, fees DoS, balance blackmailing, ... which affect link layer. But ultimately, it's function of the public you're targeting ?
And I guess that's only a small subset of the potential readers and their alleged motivations. |
Thanks for the feedback @nopara73! definitely something we want to address. Going to read through some of the other chapters to get an idea of tone/levelling.
@Ariad I'll defer to the main authors for authority, but from your list I would definitely rule out lightning+ base layer devs and researchers. Afaik, this book is not really intended for that level of specialization.
In terms of other security concerns, it's difficult to outline them all in an approachable way, but I agree that this section could be fleshed out with flood&loot and a few other attacks. One concern I have is that some topics will be unfamiliar to a regular bitcoiner, for example transaction pinning, so we're going to have to go on a long tangent just to describe some of these attacks. This is already quite an content-dense chapter, so I think we're going to have to be satisfied with a disclaimer that the things we mention here are not exhaustive (privacy and security never can be, really). |
The target audience for this book is a developer or computer science student. More specifically, technically-minded people with some background in Bitcoin who want to understand LN or develop applications that use LN. The first 4-5 chapters should also be accessible to non-developers but technical people with an interest in understanding the technology. Our target audience is not LN protocol developers or LN client developers. |
|
What is the status of this PR? @s-tikhomirov ? Have you addressed the comments from @Roasbeef ? Are we ready to merge this initial draft and subject it to further PRs for other editorial suggestions and changes? |
|
I only want to include a few cross-references across the chapter to increase readability. @Roasbeef requested a few clarifications on how certain inefficiencies and privacy leaks are mitigated by MPP payments. So, I think we are 98% ready for the merge. I'll add these latest this weekend hopefully. Upon request, we would be happy to amend the accessibility of the chapter with graphs, figures, illustrations. However, we have not received yet any indications where such supplemental material would be useful, wanted. Let us know and then we can also add those figures and illustrations, if needed. |
|
From my side, I have a deadline upcoming and can't allocate much time for this project for the next two weeks, unfortunately. I'll look at the state of this PR then and contribute if necessary. |
|
A new paper is out on LN privacy: https://mobile.twitter.com/GeorgeKappos/status/1352969635679920131 |
Co-authored-by: nopara73 <adam.ficsor73@gmail.com>
Co-authored-by: nopara73 <adam.ficsor73@gmail.com>
|
I think this PR is now ready to be merged. We addressed most of the comments and suggestions. Readability might be improved in the future by adding illustrations, figures and references to other chapters in the book. |
This is a work in progress PR. We (@s-tikhomirov, @carlaKC and me) plan to complete this chapter by mid/late November. Any suggestions, comments or feedback are welcome!