Initial investigations: Google Nearby
Investigate the performance of the (closed source) Google Nearby libraries to see whether they perform better on problematic devices than the other options we've identified.
Activity
Potentially Relevant:
Edited by paul
Lots of interesting stuff here:
- One device takes the advertiser role, the other takes the discoverer role (how is this decided?)
- Connections are always made via Bluetooth RFCOMM initially
- The advertiser encodes some information in its Bluetooth device name and presumably makes the device discoverable (does this use privileged access or does it show a dialog like other apps?)
- The discoverer performs classic BT discovery, uses the special device name to spot the relevant device, and makes an RFCOMM connection
- The
devices may then agreeadvertiser may then tell the discoverer to switch from Bluetooth to wifi - Wifi connections may use an existing AP if both devices are connected to the same AP (how is this discovered?)
- If the devices aren't connected to the same AP, wifi connections may use Wi-Fi Direct (legacy mode hotspot) or hostapd (does this use privileged access, or perhaps the local-only hotspot API?)
- The advertiser creates a hotspot via Wi-Fi Direct or hostapd and sends the ESSID and password to the discoverer via the Bluetooth connection
- The discoverer disconnects from its existing AP, if any, and connects to the AP specified by the advertiser
- Soft AP attack: a malicious advertiser can specify an AP with internet access, in which case the discoverer's device will route all its traffic through that AP. This is relevant to #15 and possibly #5 too
- There are also some other attacks, such as a wormhole (range extension) attack and specifying a nonexistent AP to cause the discoverer to disconnect from its existing AP and lose internet access
Edited by akwizgran
mentioned in issue #5
changed milestone to %Public mesh research
removed Sponsor 6 label
Please register or sign in to reply