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? > > 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? > > 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? > > 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. 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. > > 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. > > 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? 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) > 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? > 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. > > Suggestions are welcome > > -Nitesh Bharadwaj
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
