Payment Privacy

Protocol Design
1

The core ILP was designed primarily for efficiency and applicability across different use cases. Features focused on privacy were intentionally left for the layers above and below ILP. This post outlines what is and isn’t visible from ILP packets today and three options for hiding more of the details of a transaction using higher- and lower-level technologies.

What doesn’t an ILP packet show?

  • Interledger is not a blockchain, so transactions are not globally visible. ILP packets are only visible to the participants in the specific path the packet takes.
  • Source address (ILP address of the sender). Unlike internet routers, ILP connectors remember which peer each packet came from so they can send it back along the same path without knowing the address of the sender
  • Connectors do not know the full path a payment will take or has taken
  • End-to-end data is encrypted by most, if not all, transport protocols
  • If many applications use the same transport protocol, it would not be obvious which higher-level application packets correspond to
  • Identity information such as names

What is visible from ILP packets?

  • Each connector knows the party that directly sent it the packet and the destination ILP address. This means that the first connector knows the sender and receiver, but other connectors do not know who the original sender is
  • Destination ILP address, which may reveal information about the receiver including what transport protocol or implementation is being used depending on what they put in the address (ILP addresses can contain arbitrary strings of characters)
  • Packet amount, which could reveal some information about the hops a packet has gone through if sender implementations send predictable amounts (like starting with 100 units) and exchange rates between different assets are known
  • Expiry, which reveals the number of hops the packet has traversed so far if senders always use a 30 second timeout and each connector reduces it by a predictable amount like 1 second
  • Size of data being sent, which may be reveal some of what the packet is for even if the data is encrypted by the transport protocol
  • Frequency of packets sent to the same ILP address, which may reveal which software implementation is sending the packets
  • Error messages the receiver responds with when pinged
  • Timing information of traffic sent over the Internet could enable an entity with network-level observation capabilities (e.g. NSA) to see who is paying who, even without viewing any of the ILP-specific data (which is sent in encrypted internet packets)

Privacy-Enhancing Technologies

Onion routing

While this was intentionally not built into the core protocol, it would be possible to build a TOR-like system on top of ILP. Onion routing protocols obscure details such as the end recipient’s address by bouncing traffic around among circuits of participating nodes.

VPN

Arguably, an Interledger “VPN” (virtual private network) would provide significantly more privacy than a traditional internet one.

On the internet, VPNs are single hops that a user will send all of their traffic to in order to secure or hide the traffic from untrusted intermediaries like wifi hotspots or snooping Internet Service Providers (ISPs). However, traditional VPNs can correlate all incoming traffic with the specific user that sent it, both because IP packets contain the source address and because traffic must be linked to the user’s payment information.

An Interledger VPN might provide a comparable level of privacy as a multi-hop onion routed network on the internet. First, ILP packets do not contain the source address, so the ILP VPN provider would know which connector they got the packet from but not the address of the actual sender. Second, ILP packets contain value, so there is no need for the VPN provider to link all traffic to a subscription account. Arguably, multi-hop onion routing networks are mainly needed to break the link between the source and destination addresses, but a single hop may provide as good privacy if there is already no link between the source and destination address. (I would love for someone to dig into this hypothesis and see if there’s anything to it)

Private Layer 2

A private layer 2 payment protocol coupled with a private communications layer like TOR might also provide sufficient privacy for ILP payments. The private layer 2 protocol could be a multi-hop network like Bitcoin’s Lightning Network or it might be even simpler with a single-hop solution like what BoltLabs is developing for Zcash.

This approach should allow the sender to send ILP packets and settle balances with the first connector, without that connector knowing who the packets are from. I think it would also be possible to receive ILP packets and settlements through such an arrangement as well.

Getting Involved

It would be great to have researchers look into some of these topics to figure out benefits and trade-offs of each approach. If you’re interested, feel free to post ideas here or message me directly.

6 Likes
2

Interesting and comprehensive overview!

Re: the VPN idea, I could see a dual-hop VPN implemented on layer 4 providing sufficient levels of security. The actual protocol could simply be implemented in a similar way to onion routing technology. The sender [S] chooses a first-hop connector [C1] and an intermediate receiver that is also acting as a connector [C2]. [S] can include a piece of data in their packet, encrypted [C2]'s public key, that specifies the final receiver [R], which C2 will then forward funds to.

This is what important information each intermediate party sees (not comprehensive):

C1

  • Sender address [S]
  • Second-hop connector address [C2]
  • Amount
  • Encrypted data meant for [C2] (this is not known)

C2

  • First-hop connector address [C1]
  • Receiver [R]
  • Amount

I believe that a single-hop is not quite good enough, but a dual-hop onion routing structure can be good enough, especially if [C1] and [C2] in the above example are known as major VPN routers. This brings up an interesting idea – using a VPN structure in conjunction with a reputation system would allow for “payment highways” to organically form between parties by having high-reputation and high-throughput connectors being the de-facto parties to go to when transactions are desired.

Additionally, the above high-level VPN construction allow [S] to cryptographically prove a failed transaction to the reputation system by revealing unencrypted pieces of the original message sent to [C1]. There are some more complex cryptoeconomic details to look into with respect to the VPN, but this would definitely be interesting to look into.

Let me know if there’s anything I’m overlooking or if I have any misconceptions.

2 Likes
3

Sorry, by single hop I actually meant a single hop that’s participating as a VPN node. You’re right that you would need that node not to be the same as the connector you’re using directly.

Agreed! I think if we defined a VPN/minimal onion protocol that just describes how to unwrap an encrypted payload and forward it on, nodes that support it could be used in either way (and wouldn’t even know the difference).

I’m imagining the VPN protocol would be something like you send ILP packets addressed to the destination [R] as the data sent over a STREAM connection to the VPN node [C2]. One thing that would be very cool about using STREAM for this is the symmetry between the underlying ILP link and the STREAM connection. Both allow two things to be transferred: money and data. The VPN or tunneling protocol would basically be a STREAM connection in another STREAM connection. ILP packets addressed to R are sent as encrypted data over STREAM and you would “settle” with the VPN node [C2] by sending them money over that STREAM connection (via C1). Does that make sense?

To make a full onion routing network you would need to add a peer discovery protocol and a way to go from the node’s public key to a shared secret for STREAM (because you wouldn’t want to use SPSP with them, as it would communicate your IP address to them).

I’m not sure I understand what you mean by this

Possibly. My instinct would be to use the interledger-y packetization method of reducing trust or dealing with failures, rather than relying on publishing proofs of bad behavior. But it could be worth exploring further.