On Thu, Sep 5, 2013 at 8:20 PM, Matthew Toseland <matt...@toselandcs.co.uk>wrote:
> On Thu, Sep 05, 2013 at 06:34:44PM +0530, Nitesh Bharadwaj wrote: > > Key feature updates: > > > > 1) Bundled Zxing QR scanner app with the our app: > > The original code hosted by zxing had to be modified slightly in order to > > bundle it. Some changes to not to allow our app from being the default > > barcode scanner and some changes to the deprecated methods used there. > End > > result - a repository resembling the original repository has to be > > maintained in order to allow building from source code. Don't know > anything > > about copyrights etc. > > Fork first, ask questions later? Please check the license. If it's GPL or > ASL (or something more liberal e.g. 3 clause BSD), we're fine. > > > > 2) QR to bootstrap Wi-Fi direct and bluetooth: > > I've followed similar methods in both Wi-Fi direct and bluetooth with the > > ascending hierarchical order > > - A button (to start exchange process) > > - Start a server on each of the individual mobiles > > - Generate QRcode of MAC+IP+port+WPA password in case of wifi-direct and > > only MAC in case of bluetooth > > - One of the device-user clicks on 'scan QR' button and scans QR from > other > > mobile > > - Close server on one mobile (on which user has clicked 'scan-QR') > > - Initiate connection to the other mobile > > - Once connected, exchange noderefs > > > > In case of Wi-Fi direct, the user interaction is complete as soon as > he/she > > scans the QR > > Cool. > > > In case of 'previously unpaired' bluetooth devices, qr scan results in > > popping of pairing notifications on both mobiles. Each of the user have > to > > accept the pair requests from their notification bars. Only then a > > connection is established > > Ugh. > > > > I can try to avoid the above process by using reflections and messing > with > > android but can't guarantee if it is possible. If this is done we can > also > > generate a random key when starting bluetooth server and include it in > QR. > > > > - After noderef exchange is complete, a text box containing complete > > noderef pops up. User needs to manually accept the received reference > here > > The user is not going to check a full noderef. You need to think about > what actually needs checking. IMHO the main thing is the node name. > Possibly in the long run we could include a photo and check that too. > > > > 3) Nfc to bootstrap: > > Same as above except that the message containing MAC etc. is also encoded > > as an NDEF message if the mobile has nfc adapter. > > Instead of scanning, the two mobiles need to be brought back to back. The > > default android nfc animation starts asking user to click to beam > content. > > Nice. > > > > The wikipedia page suggests that nfc exchange can be eavesdropped. > > So, theoretically, someone can listen to the broadcast and connect to our > > mobile before our peer mobile connects to us and pulls our noderef. > Though > > the two mobiles need to be close to each other for nfc message exchange, > it > > can be eavesdropped from a distance of 5-10m with dedicated hardware as > > mentioned in the following link: > > http://en.wikipedia.org/wiki/Near_field_communication > > > > In this respect, bluetooth is more secure as it requires us to click on > > pair button after nfc beaming > > Why is that more secure? Can we detect when there are two responses? > Okay, I have wrongly assumed that two responses would be generated and we could detect before button click. I'd like to illustrate this: Two points: 1) Here, only one of the device's MAC_ID is thrown out as an NDEF message to the other. 2) IMO, when two devices are trying to pair, a third device wouldn't be able to send a pairing request to either of these Tested this using three mobiles Ideal Case: First Mobile : Send MAC_ID Second Mobile: Receive MAC_ID, Generate pairing request (using a known pin) with First Mobile First Mobile: Verify Pin, Click on button to connect Attack : First Mobile: Send MAC_ID Attacker: Receive MAC_ID Second Mobile: Receive MAC_ID Attacker: Spoof as if it were the first mobile (using the received MAC_ID) in real time Second Mobile: Generate pairing request to this MAC_ID with a known key Attacker: Receive this request and respond to it before the first mobile does i.e. in real time First Mobile: Received a pairing request but could not honor. If we receive such message at higher levels, attack suspected! Supposing not, Attacker: Extract key from pairing request Attacker: Generate a pairing request with first mobile using the same pairing key First Mobile: Verify pin,Connect Attacker: Accept the pairing request from second mobile Attack Successful! In case of WifiDirect: An exactly similar kind of attack is possible > > > Boils down to #easytouseislesssecure > > Why does the user clicking a button make any difference? Even a QR can be > spied upon. I agree that it doesn't make difference and also that QR can be spied. We relied on the fact regarding the difficulty of an attacker to be present with the right hardware at the right time Thanks > > > > > Work to be done: > > - Testing and fixing bugs especially related to closing the connections > > properly > > - Displaying messages to the user on a message text box regarding the > > status of our app (connecting, connected, transferring, success, failure > > ...) > > - Adding android application record to the ndef message. This allows the > > other mobile to redirect to our playstore page (when we have one) if app > > isn't previously installed > > - Exchange over internet(?) > > > > App: > > https://github.com/NiteshBharadwaj/Freenet/tree/master/src > > Sounds good. Don't have time to review. > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
