Skip to content

Changes

Page history
More refactoring of Bluetooth section. authored by akwizgran's avatar akwizgran
Show whitespace changes
Inline Side-by-side
Public-Mesh-Research-Report.md
View page @ 3b394377
......@@ -195,43 +195,6 @@ The COVIDSafe files that implement this fix are:
Because we want to use the BLESSED library, we apply a similar patch to the underlying `BluetoothGatt` object that is wrapped in BLESSED's `BluetoothPeripheral` class.
#### Android Permissions
On a mobile device, a public mesh Bluetooth service needs to be able to run uninterrupted in the background, and also need to be able to make Bluetooth advertisements and connections in the background. To do this, all of the Bluetooth Low Energy based branches of the testbed application request the following permissions:
<uses-permission
android:name="android.permission.ACCESS_COARSE_LOCATION"
android:maxSdkVersion="30" />
<uses-permission
android:name="android.permission.ACCESS_FINE_LOCATION"
android:maxSdkVersion="30" />
<!-- The BLUETOOTH permission was supposed to be removed in API 31 but is still needed on some Xiaomi/Redmi/POCO devices running API 31 and Nubia devices running API 32 -->
<uses-permission
android:name="android.permission.BLUETOOTH"
android:maxSdkVersion="32" />
<uses-permission
android:name="android.permission.BLUETOOTH_ADMIN"
android:maxSdkVersion="30" />
<uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
<uses-permission
android:name="android.permission.BLUETOOTH_SCAN"
android:usesPermissionFlags="neverForLocation"
tools:targetApi="31" />
Depending on the API level, various permissions must be granted by the user. On API level 31, the following permissions require user confirmation:
* Discover and connect to nearby devices
* Let app always run in the background
* Show notifications
On API levels 30 and earlier, access to some Bluetooth APIs requires location-related permissions.
If the app does not use a [foreground service](https://developer.android.com/guide/components/foreground-services) then the `ACCESS_BACKGROUND_LOCATION` permission is needed on Android versions 10 and 11 (API 29 and 30) for accessing Bluetooth APIs while the app is in the background.
Using this permission may result in a warning being shown about the app accessing the user's location.
This creates a UX hurdle for future public mesh applications because it could cause users to believe their locations are being tracked.
On Android versions 6 and later (API level >= 23), the device's location services must be enabled in order for apps to receive BLE discovery results.
#### Peer Advertisement
Peer advertisement happens using BLE's advertisement protocol, which allows a peripheral device to send small advertisement packets periodically.
......@@ -320,17 +283,6 @@ Then, whenever we discover an L2CAP-compatible device, we can connect to it usin
<https://code.briarproject.org/briar/public-mesh-testbed/-/blob/blessed-gatt/app/src/main/java/org/briarproject/publicmesh/bt/BtServiceImpl.java#L416>
#### Notes
- BLESSED doesn't provide a wrapper for the new advertising set API (added in API level 26), which supports Bluetooth 5 advertising features such as periodic advertising, extended advertising and coded PHY. If we want to use those features we'll need to use the Android API directly, rather than going through BLESSED.
- If we use any Bluetooth 5 advertising features then we also need to use the Android API directly for scanning (or submit a pull request upstream for BLESSED to allow legacy mode to be turned off for scanning).
- We can, however, use BLESSED to request coded PHY for GATT connections.
- The Moto G 4G never receives the result of starting advertising (no callback to `onAdvertisingStarted()` or `onAdvertiseFailure()`).
- The Moto G 4G and Huawei P8 Lite 2015 can discover the Samsung Galaxy J5 2016, but it can't discover them and they can't discover each other.
- The P8 Lite can connect to the J5 via GATT and exchange pings and pongs.
- The Moto G can't connect to the J5 via GATT: it receives a callback to `onConnectingPeripheral()`, never receives `onConnectedPeripheral()`, and eventually receives `onDisconnectedPeripheral()` with status `LMP_OR_LL_RESPONSE_TIMEOUT`. The J5 receives `onCentralConnected()` and `onCentralDisconnected()` as expected. The J5 can subsequently connect back to the Moto G, using the address it learned from the unsuccessful connection, and exchange pings and pongs.
- When the J5 receives a connection from the Moto G or P8 Lite, the J5 sees the same address that the Moto G/P8 Lite gets from its own `BluetoothAdapter`, ie the BT classic address.
#### Socket-Like Communication via GATT
GATT makes it easy to implement services in which a central and a peripheral exchange small pieces of data in a predefined structure.
......@@ -342,7 +294,7 @@ This can be done by defining a service with two characteristics: a "read charact
This `blessed-gatt` testbed branch demonstrates this technique.
#### BLE Allocator Characteristic
#### Allocator Characteristic
One of the core features for a performative ad-hoc mesh system is the ability to make simultaneous p2p connections between multiple devices.
We found that some of the test devices could support simultaneous GATT connections to multiple peripherals when acting as a central.
......@@ -379,24 +331,12 @@ The full handshake as implemented in the `blessed-gatt-allocator-vuln` and `bles
![allocator-char-diagram](uploads/b09ac8ca880e598d01bba8bb0985afe6/allocator-char-diagram.png)
##### Notes
The allocator characteristic works as an active list of nearby peers, so higher level protocols could possibly utilize this as a way to further increase peer discovery and data propagation.
Because each peripheral has a limited number of read characteristics, protocols built on top of this strategy should prioritize quicker, more frequent connections rather than long lasting data transfers.
* The allocator characteristic works as an active list of nearby peers, so higher level protocols could possibly utilize this as a way to further increase peer discovery and data propagation.
* Because each peripheral has a limited number of read characteristics, protocols built on top of this strategy should prioritize quicker, more frequent connections rather than long lasting data transfers.
* The allocator system allows a socket-like abstraction to be made on top of regular GATT reads and writes.
This is useful because GATT has much greater support than L2CAP CoC among Android devices, especially older devices.
The allocator characteristic system can be used in parallel with L2CAP CoC, by advertising the PSM of the peripheral's L2CAP server socket along with the UUID of the mesh service.
This allows L2CAP CoC to be used between centrals and peripherals that support it, with the allocator characteristic system providing a fallback for older devices.
* The GATT protocol allows a central to read from any read characteristic, not only the one that has been allocated to it.
If the communication between a peripheral and a central needs to be confidential then higher-layer protocols must ensure that this remains the case even when the data sent from the peripheral to the central can easily be observed by other devices nearby.
In practice this is unlikely to make a big difference to the design of higher-layer protocols, which must already be designed around the assumption that any data sent over a wireless medium can easily be received by unintended recipients.
Open questions:
* What is the maximum number of GATT Characteristics allowed on each popular Android device?
* What is the MTU on each popular Android device?
During our research, the Nexus 5X, Pixel 3a, 4, and 5 all had the highest possible MTU size of 512 bytes, but this is not always a given.
* Is the Linux [Bluez](https://www.bluez.org/) library affected by the silent pairing bug (CVE-2020-12856)?
#### BluetoothCommunicator
......@@ -409,6 +349,27 @@ Because of the added flexibility working with BLESSED gives us, future developme
While the library has methods to enable auto-peering, our attempt to enable auto-peering with this framework proved unsuccessful.
#### Notes
* BLESSED doesn't provide a wrapper for the new advertising set API (added in API level 26), which supports Bluetooth 5 advertising features such as periodic advertising, extended advertising and coded PHY. If we want to use those features we'll need to use the Android API directly, rather than going through BLESSED.
* If we use any Bluetooth 5 advertising features then we also need to use the Android API directly for scanning (or submit a pull request upstream for BLESSED to allow legacy mode to be turned off for scanning).
* We can, however, use BLESSED to request coded PHY for GATT connections.
* The Moto G 4G never receives the result of starting advertising (no callback to `onAdvertisingStarted()` or `onAdvertiseFailure()`).
* The Moto G 4G and Huawei P8 Lite 2015 can discover the Samsung Galaxy J5 2016, but it can't discover them and they can't discover each other.
* The P8 Lite can connect to the J5 via GATT and exchange pings and pongs.
* The Moto G can't connect to the J5 via GATT: it receives a callback to `onConnectingPeripheral()`, never receives `onConnectedPeripheral()`, and eventually receives `onDisconnectedPeripheral()` with status `LMP_OR_LL_RESPONSE_TIMEOUT`. The J5 receives `onCentralConnected()` and `onCentralDisconnected()` as expected. The J5 can subsequently connect back to the Moto G, using the address it learned from the unsuccessful connection, and exchange pings and pongs.
* When the J5 receives a connection from the Moto G or P8 Lite, the J5 sees the same address that the Moto G/P8 Lite gets from its own `BluetoothAdapter`, ie the BT classic address.
* The GATT protocol allows a central to read from any read characteristic, not only the one that has been allocated to it.
If the communication between a peripheral and a central needs to be confidential then higher-layer protocols must ensure that this remains the case even when the data sent from the peripheral to the central can easily be observed by other devices nearby.
In practice this is unlikely to make a big difference to the design of higher-layer protocols, which must already be designed around the assumption that any data sent over a wireless medium can easily be received by unintended recipients.
Open questions:
* What is the maximum number of GATT Characteristics allowed on each popular Android device?
* What is the MTU on each popular Android device?
During our research, the Nexus 5X, Pixel 3a, 4, and 5 all had the highest possible MTU size of 512 bytes, but this is not always a given.
* Is the Linux [Bluez](https://www.bluez.org/) library affected by the silent pairing bug (CVE-2020-12856)?
### Bluetooth Mesh
Bluetooth Mesh is a relatively new Bluetooth standard that supports multi-hop communication among a set of devices, encrypted with a shared network key. Mesh devices can optionally act as relays, or as "friends" for power-constrained devices, storing messages on their behalf for later collection.
......@@ -430,6 +391,43 @@ However, given the use cases that are described in the Bluetooth Mesh docs (eg s
In short, Bluetooth Mesh doesn't appear to be usable for creating smartphone-based mesh networks at present, and seems unlikely to become usable for that purpose in future.
### Android Permissions
On a mobile device, a public mesh Bluetooth service needs to be able to run uninterrupted in the background, and also need to be able to make Bluetooth advertisements and connections in the background. To do this, all of the Bluetooth-based branches of the testbed application request the following permissions:
<uses-permission
android:name="android.permission.ACCESS_COARSE_LOCATION"
android:maxSdkVersion="30" />
<uses-permission
android:name="android.permission.ACCESS_FINE_LOCATION"
android:maxSdkVersion="30" />
<!-- The BLUETOOTH permission was supposed to be removed in API 31 but is still needed on some Xiaomi/Redmi/POCO devices running API 31 and Nubia devices running API 32 -->
<uses-permission
android:name="android.permission.BLUETOOTH"
android:maxSdkVersion="32" />
<uses-permission
android:name="android.permission.BLUETOOTH_ADMIN"
android:maxSdkVersion="30" />
<uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
<uses-permission
android:name="android.permission.BLUETOOTH_SCAN"
android:usesPermissionFlags="neverForLocation"
tools:targetApi="31" />
Depending on the API level, various permissions must be granted by the user. On API level 31, the following permissions require user confirmation:
* Discover and connect to nearby devices
* Let app always run in the background
* Show notifications
On API levels 30 and earlier, access to some Bluetooth APIs requires location-related permissions.
If the app does not use a [foreground service](https://developer.android.com/guide/components/foreground-services) then the `ACCESS_BACKGROUND_LOCATION` permission is needed on Android versions 10 and 11 (API 29 and 30) for accessing Bluetooth APIs while the app is in the background.
Using this permission may result in a warning being shown about the app accessing the user's location.
This creates a UX hurdle for future public mesh applications because it could cause users to believe their locations are being tracked.
On Android versions 6 and later (API level >= 23), the device's location services must be enabled in order for apps to receive BLE discovery results.
## LAN Multicast
Devices that are connected to the same LAN may be able to discover each other using IP multicast and then connect to each other using TCP or UDP.
......