Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-19 📝 Original message: Hm interesting. So far ...

📅 Original date posted:2015-10-19
📝 Original message:
Hm interesting. So far the IP-PubKey-Relationship was public for me
(furthermore, I even think about adding it to the gossip protocol, see
other post).

I think we can mitigate the risks associated fairly well. Suppose
lightning nodes run on dedicated machines, firewalled against any
incoming connections (except ones on the lightning port).

Against DDoS attacks it could be sufficient to just close this port as
soon as you are connected to all of the nodes you want to be
connected. Open connections are not affected by this.


However, I think it will be more difficult to establish a connection
between 'Real identity'-'PubKey'. And this relationship should really
be more sensitive. When you pay to someone, he will only provide you
with a rendezvous point and the onion object towards him, which is
encrypted. Lightning nodes can always have a dedicated IP address, to
make it more difficult to relate merchant IP and pubkey.

I think it is important to have a map of IP/PubKey for those who want
to provide it at least. The object which relates your pubkey and IP
will be signed with your private key. If you never sign and send such
an object, no one will be able to tell your IP other than your direct
neighbors. I think though that most nodes should be able to receive
new connections and build channels with foreign nodes. It is a direct
consequence of sufficiently hardening the network against failure. If
you observe a high fee rate for a specific route, you should be able
to establish new connections to help the network.


Against MITM and eavesdropping your pubkey to a stranger connecting to
your node, we can change the protocol such that the one initiating the
connection always sends his signed pubkey object first. It is up to
you to accept it and send yours if you know the other guy or don't
care, or to abort the connection if you don't like strangers.

Cheers
Mats Jerratsch

2015-10-19 7:30 GMT+02:00 Anthony Towns <aj at erisian.com.au>:
> On Sat, Oct 17, 2015 at 06:53:55AM +1000, Anthony Towns wrote:
>> I think treating the relationship between a network address (IPv4/IPv6
>> addr and port, tor service) and the lightning network address as sensitive
>> is valuable. Revealing a network address helps reveal physical identity,
>> makes denial-of-service attacks straightforward, and gives a point of
>> entry for targetted hacking to steal your money.
>
> I guess the attacks I'm thinking of are something like:
>
> Exploits leading to theft:
>
> - if you're a merchant, it's easy to find out your lightning id (just
> buy something from you!) and during the trading day you'll probably
> have a relatively large balance in your lightning channels (up until
> you close it out by committing your profits to the blockchain eg). If
> I can find your IP address and hack into your system, I can steal
> that money.
>
> - if you're making lots of money routing payments, I might be able to
> deduce that from public information (like how cheap your fees are,
> how rarely your fees change, how many connections you have, ...)
> and thus know that you have a lot of money in lightning channels that
> I can steal
>
> - if you're just being a consumer, however, I can't think of a reason
> your lightning id would matter -- if I can snoop on your IP connection,
> I can probably tell you're mostly a consumer by traffic analysis,
> and conclude that you've probably got $10-$100 that could be
> stolen. failure of imagination on my behalf?
>
> Denial of service:
>
> - I might know the lightning id of someone I don't like; a merchant who
> sells something unpopular, or a node that routes payment for people I
> don't like. If I can translate that into an IP address, I might be
> able to DoS them using botnets etc.
>
> Exploits that help you exploit others:
>
> - if I know X has a channel with you; figuring out X's IP might let
> me monitor X's TCP connections (by hacking into their system, or
> by subpoena'ing their ISP), which in turn would help me figure out
> your IP.
>
> I guess there's three ways you can associate the info:
>
> a) given a lightning id, cheaply work out the IP that provides it
>
> b) given an IP, cheaply work out the lightning id associated with it
>
> c) given an IP and a lightning id, confirm/deny whether that lightning
> id is provided by that IP
>
> (a) is what you want if you're planning theft or DoS
>
> (c) is enough if you've got other information about whoever you want to
> attack that can narrow down the lightning ids and IP addresses (eg, you
> want to attack a local business, so you can find out their lightning id
> directly, and narrow down their IP based on local ISPs)
>
> (c) is obviously trivial if you've already got (a) or (b).
>
> You can get to (a) from (b) if (b) is cheap enough and you can build up
> a database that you can query in reverse.
>
> If you're not an attacker, then (a) is useful if you want to have new
> channels not be totally random (eg, to have people be able to connect
> to newly announced beacons). And (c) is presumably necessary if you
> want to reconnect to someone you had a channel with, when you lose your
> internet connction.
>
> One "clever" way to handle (a) might be via a "fund a new channel by
> lightning transaction" operation. ie, if you (Alice) want to open a
> channel with Bob, route a payment to Bob with instructions to forward to
> Alice, and to do that by connecting to a given IP/port and establishing
> a new channel; ie rather than just telling Bob to route to Alice in the
> onion payoad, also included Alice's network address. That way Alice
> reveals her IP precisely to Bob; and Bob only reveals his IP if he
> decides he is interested in opening a channel.
>
> That'd also provide a way of reconnecting with a peer if you lose your
> connection and both of you change your IPs. It assumes that you both
> have an alternative channel that's still functional though.
>
>
> Okay... so how about the following. When making a new p2p connection, when
> you know who you're talking to, you rely on a shared secret X, and send:
>
> Alice: "Hi. I'm <session key A>. My nonce is X."
> Bob: "Good to meet you, I'm <session key B>."
>
> Rest is encrypted to ECDH(A,B).
>
> Alice: SIG_Alice(Alice || Bob || A || ECDH(A,B))
> Bob: SIG_Bob(Bob || Alice || B || ECDH(A,B))
>
> Alice: "Hi Bob!"
> Bob: "Hi Alice!"
>
>
> If you don't know who you're talking to, you don't send a nonce and
> you do the current protocol. Once you're connected (or once you have a
> channel setup) they'll tell you a nonce to use next time:
>
> Alice: "Hi. I'm <session key A>."
> Bob: "Good to meet you, I'm <session key B>."
>
> Rest is encrypted to ECDH(A,B).
>
> Alice: I'm Alice, SIG(Alice || A || ECDH(A,B))
> Bob: I'm Bob, SIG(Bob || B || ECDH(A,B))
> Bob: BTW, next time you connect, use nonce <Y>.
>
> If Bob wants some degree of privacy, while still accepting anonymous
> connections, then he generates a new id to hand out to anonymous
> connections every so often, linking it up to one of his other ids, or
> to one of his neighbours by reusing a pre-existing channel. If you're
> asking someone to connect to you and have a bunch of ids, you give them
> a nonce to use that will select the correct one. You use nonces as a
> hash key to lookup your id, their id, and any channels you have open.
> You don't share or reuse nonces.
>
> (If an attacker knows Alice and Bob have a connection, and can MITM
> Alice trying to connect to X, the above lets them verify which of Alice's
> connections is Bob. If that's a reasonable attack, it'd be avoidable if
> the nonce X was replaced by X and Y; X sent in cleartext as above, but
> Y simply included in the info being signed. That prevents the attacker
> from being able to verify the signature info at all)
>
> Not convinced that's quite right, but maybe something along those lines
> might work out.
>
> Until there's a substantial number of lightning nodes (1000s?), it's
> probably trivial to link network address and lightning id by traffic
> analysis, so I think it's probably sane to leave implementing any of
> the above until later.
>
> Cheers,
> aj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev