Exchanging peering credentials over insecure channel

[benhylau]

We have discussed two ways for Android devices to exchange credentials, i.e. QR and NFC. Both these methods are meant for devices to peer while in close proximity, and require that both have the cjdns-android app installed. Yes, the QR can be distributed across distances, but that's the same as broadcasting the credentials to the world. So I am proposing a more general way to securely exchange peering credentials over distances, and requires only the initiating party to have the app to begin with.

1. The initiating party will click some button from the app to initiate peering with a friend. Something like this URL gets copied to the clipboard. She can send it to a friend via email, text message, whatever.

   http://special.clearnet.server
     ?type=peerRequest
     &protocol=udpInterface
     &pubKey=thePublicKeyOfInitiatingDevice
   

2. The friend receives it and clicks the link. If he has cjdns-android installed¹, the system will ask if he wants to open the link with the cjdns app or browser. Upon selecting the cjdns app, the app will ask if he wants to accept this peer request. Upon accepting, the app generates a new set of credentials for the requested protocol, which gets encrypted with the public key from the query parameters, and the following URL gets copied to his device clipboard. He then emails it back.

   http://special.clearnet.server
     ?type=peerResponse
     &credentials=credentialsEncryptedWithHerPublicKey
   

3. She receives the response URL, clicks it and selects the cjdns app to open, and the app decrypts with her private key and adds it to cjdroute.conf, restarts the service.

¹In the case where the friend does not already have the app, the URL will open in browser, which we set up special.clearnet.server to respond to all requests with market://details?id=com.cjdns.app.package.name, so all potentially new Hyperboreans are directed to the app in Google Play.

What do you guys think? There are some uncertainties around what protocols can be used to peer between two Android devices, and whether in Step 2, he can accept by using a set of known credentials that the app knows about, such as his VPS.

[kpcyrd]

The special clearnet server and your "email, text message, whatever." provider can man in the middle this by replacing the keys. :) (this problem is impossible to solve with no trusted channel/shared secret/pre-shared keys)

Maybe we should hide things like manual peering from the end user since most of the people we're targeting with an android application don't have any peers anyway.

Can we use python libraries on android? If we don't I'd put a Java implementation of my inet auto-peering on my todo.

[benhylau]

The clearnet server really does nothing other than redirect yet to be users to the app in the app store. There is also nothing to be gained in intercepting the peer request, which is all public information. One way to prevent mim swapping keys would be for both parties to publicly announce their URLs, say, on their Twitter. Only the initiating device, who holds the private key, can read those credentials.

The thing is, we need a way for Android devices to peer manually. I currently have no convenient way to peer to my own VPS, or anyone else's.

I am not aware of Python on Android. @dpsm do you know?

[benhylau]

@kpcyrd I was thinking about this problem in the context of Android devices, but from our discussion in #12 (comment), I think what we need is a more general peer discovery protocol across all platforms.

[benhylau]

This turned into benhylau/wrbt#1.