Published on: 2015-12-16T06:30:23+00:00
In an email thread from October 2015, Anthony Towns discussed the use of public key cryptography in lightning and identified three potential uses: routing keys for constructing the onion, anchor keys for spending the anchor transaction and signing commitment transactions, and p2p keys for establishing a shared secret when talking to a node. Separate keys for spending the anchor and spending the commitments are necessary, with secure random signing parameters chosen for the anchor keys being particularly important. The commitment keys may not actually be used if the channel is closed cooperatively, so having a collection of these could potentially improve privacy. However, having too many commitment keys could make enforcement of revoked commitments difficult. Both parties must know the commitment (public) keys to construct and validate the p2sh addresses. Lastly, p2p keys are used to avoid p2p communications being available to someone else and can either be different for every connection or just one for the lightning instance.In another email thread from October 21, 2015, Rusty Russell proposed using a session nonce to improve security after the first handshake in a system. Although the nonce can help with correlation, it needs to change to maintain security. He suggested using sha256() of some shared secret along with an incremented number for each successful handshake. ECDH of node ids would be the obvious shared secret to use as a base. However, determining what constitutes a successful handshake is vague and may require allowing +/- 1 nonce. Russell also acknowledged that using a nonce may overcomplicate things since nodes are already publishing their ids and IPs in a public IRC channel. Therefore, he suggests tabling the proposal for now.In a discussion on the Bitcoin Lightning Network mailing list, Rusty Russell and Mats Jerratsch discuss ways to mitigate the risks associated with lightning nodes. They suggest having dedicated machines running firewalls against any incoming connections, but Russell believes this is unrealistic for consumers' wallets compared to nodes for routing/merchants. They then discuss mitigating the risk of MITM and eavesdropping by changing the protocol so that the one initiating the connection always sends his signed pubkey object first, but Russell argues that this won't work as it's possible to MITM Alice and Bob in the middle of a connection. Instead, they agree that sending a shared secret nonce avoids revealing anything if there's a MITM, while still allowing either one to re-establish the connection if they can actually talk. The session nonce would change each time to avoid correlation. Finally, Russell suggests that "successful handshake" is a bit vague, so it may require allowing +/- 1 nonce.In another email exchange from October 2015, Mats Jerratsch and aj discussed the risks associated with IP-PubKey-Relationship in lightning nodes. Jerratsch suggested adding it to the gossip protocol. Aj agreed but mentioned the need to mitigate associated risks. The suggestion was then made to have lightning nodes run on dedicated machines and firewalled against any incoming connections. However, aj pointed out that this distinction between wallets for consumers and nodes for routing/merchants would pose a problem since lightning wallets cannot realistically run on dedicated machines/IPs. To mitigate the risks of MITM and eavesdropping, Jerratsch proposed changing the protocol such that the one initiating the connection always sends his signed pubkey object first. However, aj disagreed, stating that if Alice and Bob were being MITM'd, sending a shared secret nonce instead and then just sending signatures avoids revealing who they are while still allowing them to re-establish connection if they can actually talk.In this communication, Anthony Towns discusses the daemon/p2p protocol in detail. Currently, lightning relies on protobufs with union support, which requires a newer version of protobuf-c than is available in Debian or Ubuntu. Capnp's canonical implementation is in C++ rather than C; the C version is serialisation-only. Bitcoin already uses protobufs for the payment protocol, and it is more widely supported. The author also discusses public key cryptography, including routing keys, anchor keys, and p2p keys. The current p2p protocol involves a few risks, including revealing node identity, MITM attacks, and potential DoS attacks. Treating the relationship between a network address and the lightning network address as sensitive is valuable.In a forum discussion on the Lightning Network, Mats Jerratsch proposes that the IP-PubKey-relationship should be public and added to the gossip protocol. This proposal aims to mitigate risks associated with revealing network addresses such as DDoS attacks, establishing connections between real identities and PubKeys, and MITM and eavesdropping attacks. To make it difficult to relate merchant IP and Pubkey, he suggests lightning nodes can always have a dedicated IP address. Additionally, a map of IP/PubKey can be created by those who want to provide it, and the object which relates a pubkey and IP will be signed with the private key.
Updated on: 2023-07-31T18:24:57.154186+00:00