On Wednesday 03 Jul 2013 11:20:24 Nitesh Bharadwaj wrote: > On Mon, Jul 1, 2013 at 10:53 PM, Matthew Toseland <t...@amphibian.dyndns.org > > wrote: > > > On Monday 01 Jul 2013 16:30:11 Nitesh Bharadwaj wrote: > > > My apologies for the late update. I had to change the track of the > > project > > > after discussing with my mentor and toad_ > > > > > > Presently, as a starting step, we plan to send signed beacons over the > > > local area network and when the mobile picks it and verifies signature, > > it > > > raises an intent asking the user to confirm whether it is talking to > > > correct node. If user confirms, the phone pulls the nodereference through > > > fproxy. > > > > This is for the initial setup: The user has installed the app, started it, > > and pushed a setup button to connect to his node. Note that the user may > > well install the app before they have installed a home node; in this case, > > we want to be able to accept invites, but we don't want to associate with > > *ANY* node; we want to wait for the user to push the button to connect to > > *their home node*. (Don't worry about this yet though, invites aren't ready > > yet; the point is we don't want to automatically connect to whatever node > > is nearby). > > > > Later on, we will recognise the beacon of our home node, check the > > signature, and automatically upload new noderefs and download the updated > > noderef for the home node - provided that the freenet app is running. > > > > Hmmm, broader question: If we're on somebody's LAN, or even plugged into > > their PC via USB, do we want to exchange noderefs directly with *their* > > home node? Even if this is true, it is different to talking to *our* home > > node? Nextgens? > > According to our setup (that we discussed on irc), anyone can pull our node > reference from our homenode- if they are on our LAN && homenode is > broadcasting - (as we are not authenticating). Similarly, anyone can push > node reference into our homenode's fproxy (for the time being). It is the > job of the user on the homenode to decide whether to accept a nodereference > or not. Same is for the former case, where the user clicks a button on > mobile to confirm he is pulling node reference from his home node.
Okay. Whereas on the mobile, we DO need to confirm. That is, we only push noderefs to nodes the user has explicitly authorised. We do not want our noderef and our friends noderefs to be downloaded automatically; that would be an attack, a kind of physical harvesting. > > If talking to the other nodes is to be implemented, IMHO, it only needs > trivial modifications to android code and no modifications to the homenode > code and I don't see any further security implications than what we already > have (DoS). This is because *we* become the *anyone* here. Again.. > nextgens? toad_? Ok. > > > > I have implemented the same by modifying the official MDNSDiscovery > > plugin > > > to broadcast fproxy through DSA signed packets. One major modification > > is, > > > instead of just broadcasting on one network interface, I loop through all > > > network interfaces and broadcast on each one of their netwiorks. This is > > > for people connected to multiple networks (the user maybe connected by > > > bluetooth or wifi to the mobile while connected to internet via Ethernet > > > Adapter). > > > > Usually bluetooth or wifi should be on a LAN-style IP address, correct? A > > phone connected via USB would probably give us a link-local address? So do > > we need to broadcast to interfaces with real internet addresses? Of course > > 99% of the time none of our interfaces will have a real internet address, > > because we're behind a router etc? > > True. What to do with real internet addresses - no clue So we should broadcast only to interfaces with a LAN/link-local IP address. There is a method for checking this in src/freenet/support/transport/ip/ IIRC, or just ask InetAddress. For now we'll just say if the router is evil we're stuffed; we need to broadcast to the router for e.g. UPnP port forwarding anyway, for example, and an evil router could probably detect Freenet (which is a bit more expensive on the ISP backbone level). The priority security-wise is to make building the darknet easy; that's what this smartphone project is about. > > > > Though this doesn't solve the problem completely (i.e. the user may > > connect > > > via a different interface lateron while during our initial scan we found > > > that the particular interface is down), it solves partially atleast for > > > testing purposes.We might have to poll frequently to check if any network > > > interface came alive and start broadcasting on its network > > > > You can't just check the set of interfaces each time you broadcast? > > Wouldn't this be easier? > > I am using jmdns (java library for MDNS ) service and once we start the > service, bound to an interface, it continues to broadcast until we stop the > service or the interface is down. This library is already being used in all > other broadcasts in the official MDNS plugin. So, I was thinking to > continue using this standard service and we periodically scan to check > whether any other new interface is up (on which we are not already > broadcasting) and start the service on it. I dunno. If the phone is plugged in via USB, the interface definitely did not exist before connecting it. I dunno if this is true for Bluetooth. So we need to poll for new interfaces almost as frequently as we broadcast. Ideally as frequently as we broadcast.... Does the library allow us to call something to broadcast *once*? We can change stuff if we need to, we'd like to be able to update the code from upstream though... > > > > This holds the corresponding code: > > > > > https://github.com/NiteshBharadwaj/plugin-MDNSDiscovery-official/blob/master/src/plugins/MDNSDiscovery/MDNSDiscovery.java > > > > > > Also, I've used a java properties file to store the private key and > > public > > > key in Base64 for future signatures. Not sure whether it is the right way > > > (no crypt?) > > > > This is fine for now. We could put it in node-<port> maybe, that would > > mean adding to to NodeCrypto. > > > > Generally a SimpleFieldSet is preferred to Properties because of encoding > > issues, but it doesn't matter here. > > > > > > I made the basic application on mobile phone which looks for multicast > > > beacons and verifies the signature. Though it is in a very nascent stage > > > with a crappy UI, it works. If the signature is verified, it pops an > > intent > > > with a message asking the user to confirm. Once, the user confirms, it > > > notes the name,ip and port from the broadcast and pulls the node > > reference > > > through the fproxy link. "http://"; +ip+port + "/addfriend/myref.txt". > > > Also, it stores the name of the node separately. Now the mobile and node > > > can be said to be configured. > > > > So the beacon includes both the pubkey and the signature, using ECC? (If > > using DSA or RSA the packets would be far too big). Thus we can verify the > > signature based on the key provided, and then ask the user? Once the user > > confirms, we should store the pubkey on the phone, so that we can > > automatically send the data in future. > > > > I was using DSA (bouncy castle implementation) and I send both pubkey and > signature as a byte array. Its length is usually around 500 bytes. I can > change that if need be. Better to use ECC. ECDH.java is in fred now, ECDSA.java will land very soon. This will allow for much smaller packets (pubkeys are much shorter). But it's good to get it working. > > Pulling the data via fproxy may be problematic: Fproxy may not be > > configured to be available from any LAN address, especially if we're on > > Bluetooth or USB, which may not be on the addresses our LAN uses. IMHO it > > would be better to set up an encrypted connection (probably TCP, e.g. using > > TLS, authenticated with the pubkey) between the node and the phone, and > > send the data that way. > > Ok. A dedicated TCP server (for handling nodereference requests) on another > port is a good option instead of fproxy. I thought authentication was > postponed for time being? The node needs to be authenticated to the phone. That's why e.g. the broadcast is signed. > > > > The corresponding code can be found here: > > > > > https://github.com/NiteshBharadwaj/Freenet/tree/master/src/freenet/darknetconnector/FProxyConnector > > > > > > Work to be done on step1: USB support, Improving UI, Extensive Testing > > > > What do you need to do for USB support? USB support is just a point to > > point network connection isn't it? The other 2 points are essential of > > course. > > Ok Obviously you will need to test all these cases eventually! > > > > How good is an option of synchronizing with the home node only when the > > > user opens our application? The other options include > > > 1) Running a service which runs in the background. Drawback: Severe > > battery > > > drain since we are dealing with multicast WiFi packets continually. > > > > While the phone is on the local network, it can receive the packets (with > > very little battery drain). What drains the battery is checking the > > signature, and possibly setting up a connection? > > I was talking about background service in a situation where we don't know > whether we are on local network or not. The background service continually > processes MDNS broadcasts. > > > We can avoid this mostly: > > - Unless we are doing the initial setup, we can safely ignore any beacon > > we don't recognise. Or can we? See above. > > - If we have data to send (noderefs we've exchanged etc), we need to > > process the beacon from our home node. > > - If we don't have data to send, we don't need to process the beacon > > unless we last saw it more than say 1 hour ago. (Future optimisation: a > > flag or version counter in the broadcast indicating that the noderef has > > been updated) > > Ok, these heuristics are necessary. > > > > 2) Periodically displaying messages on the notification bar reminding to > > > sync up with homenode > > > > Shouldn't be necessary IMHO. AFAICS we can just sync up when we receive a > > packet and have data to send? > > I am referring to the situation where we don't know whether we are on home > LAN and we don't have a background service that continually receives > packets. If we have exchanged node references, we remind the user to > connect to home LAN and turn on the app a.k.a start listening for MDNS > packets If the app isn't enabled we can't remind the user anyway. :) AFAICS with the above optimisations a background service shouldn't use much resources? > > > > > 3) A widget which responds to changes in wifi state. If it gets a call > > from > > > the OS that Wi-Fi state is changed, it checks if the MAC id of access > > point > > > to be the same as that of home. If it detects home network, then it > > starts > > > background service Drawback: A little more effort+time, many acces points > > > may be on same network (campus/office WiFi) > > > 4) Same as #3 minus widget plus another background service which does > > > nothing but waits for a callback from OS regarding Wi-Fi. If it finds > > home > > > MAC id, it starts up the other background service to synchronize. The > > > former could also post notifications if home* is not detected for long > > time > > > > MAC is easily spoofed, but this might make sense as an optimisation. > > I was trying to find a way (heuristic) where we can avoid continuously > listening when we are not on LAN. Surely the phone will receive the packets anyway, if wifi is enabled, so checking the identity isn't a big deal?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
