Skip to content

Changes

Page history
Restructure BLE section a bit authored by akwizgran's avatar akwizgran
Show whitespace changes
Inline Side-by-side
Public-Mesh-Research-Report.md
View page @ b514085f
......@@ -72,21 +72,13 @@ The accessibility of Bluetooth API's on most modern day smartphones makes Blueto
Background information about Bluetooth:
- Bluetooth Low Energy
- <https://punchthrough.com/how-gap-and-gatt-work/>
- <https://www.oreilly.com/library/view/getting-started-with/9781491900550/ch04.html>
- <https://github.com/weliem/blessed-android>
- <https://software-dl.ti.com/lprf/simplelink_cc2640r2_sdk/1.35.00.33/exports/docs/ble5stack/ble_user_guide/html/ble-stack/l2cap.html#l2cap-connection-oriented-channel-coc-example>
- <https://code.briarproject.org/briar/public-mesh-testbed/-/tree/blessed-gatt>
- Bluetooth "classic", specifically RFCOMM
- <https://developer.android.com/guide/topics/connectivity/bluetooth>
- <https://code.briarproject.org/briar/public-mesh-testbed/-/tree/bt-classic>
### Bluetooth "classic" (BR/EDR)
......@@ -127,12 +119,18 @@ This does not allow a group of devices to bootstrap connectivity entirely withou
Bluetooth Low Energy is a separate protocol from Bluetooth classic that is designed to reduce the energy consumption during use, without greatly impacting functional range.
#### BLESSED Library
We have found that the open source Bluetooth library [BLESSED](https://github.com/weliem/blessed-android) is useful for working with BLE on Android. The project's README.md offers an introduction to the library for new users, and they also offer a number of [example projects](https://github.com/weliem/blessed-android/tree/master/app/src/main/java/com/welie/blessedexample) to help developers get started with BLESSED.
#### Security
BLE is designed to allow devices to advertise and discover services continuously with low energy consumption. This creates a privacy risk: a device that is continuously sending packets from the same address can easily be tracked.
To mitigate this risk, BLE uses a cryptographic key called the Identity Resolving Key to transform the device's permanent address into a series of temporary addresses. From the perspective of anyone who does not know the Identity Resolving Key, these temporary addresses appear random and cannot be linked to one another. Devices that have been paired know each other's Identity Resolving Keys and can therefore recognise each other's temporary addresses and communicate with each other.
##### CVE 2020-12856
During our research we encountered an open vulnerability which is extremely relevant to the public mesh application development space. [CVE-2020-12856: A Silent Pairing Issue in Bluetooth-based Contact Tracing Apps](https://raw.githubusercontent.com/alwentiu/COVIDSafe-CVE-2020-12856/master/CVE-2020-12856-19-June-2020.pdf) by authors Alwen Tiu and Jim Mussared, released in May 2020, describes an attack which silently creates a pairing between the attacker's device and a victim device. This results in the attacker learning the victim's Identity Resolving Key. The attacker can use this key to translate the victim's temporary addresses back to the permanent address, thus enabling the attacker to track the victim's movements.
In most public mesh protocols, each device uses some sort of publicly-identifiable address at the mesh layer so that other devices in the network can route messages to it, so at first the attacker's ability to track the victim via a permanent address does not seem like a major security issue. However, this attack is particularly relevant even in the public mesh context, because it allows for the identification of users even after a user stops using the public mesh application.
......@@ -147,16 +145,11 @@ Our fix is heavily based on work by the COVIDSafe Android application team. The
The COVIDSafe files that implement this fix are:
<https://github.com/AU-COVIDSafe/mobile-android/blob/master/app/src/main/java/au/gov/health/covidsafe/streetpass/StreetPassPairingFix.kt>
<https://github.com/AU-COVIDSafe/mobile-android/blob/master/app/src/main/java/au/gov/health/covidsafe/streetpass/IBluetoothGattInvocationHandler.java>
* <https://github.com/AU-COVIDSafe/mobile-android/blob/master/app/src/main/java/au/gov/health/covidsafe/streetpass/StreetPassPairingFix.kt>
* <https://github.com/AU-COVIDSafe/mobile-android/blob/master/app/src/main/java/au/gov/health/covidsafe/streetpass/IBluetoothGattInvocationHandler.java>
Because we want to utilize the BLESSED library, we apply a similar patch to the underlying `BluetoothGatt` object that is wrapped in the `BluetoothPeripheral` class.
#### Existing Library
We have found that the open source Bluetooth library, [BLESSED](https://github.com/weliem/blessed-android) is useful for working with BLE on android. Their project README.md offers an introduction to the library for new users, and they also offer a number of [example projects](https://github.com/weliem/blessed-android/tree/master/app/src/main/java/com/welie/blessedexample) to help developers get started with BLESSED.
#### 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:
......@@ -186,12 +179,13 @@ On a mobile device, a public mesh Bluetooth service needs to be able to run unin
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
On the user side, they end up getting the following permission pop-ups on API 31+ devices:
- Nearby Devices
- "Let app always run in the background"
- Notifications
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 older devices, (SDK 30 and earlier) the mesh testbed app requires location-based permissions which creates a UX hurdle for future public mesh applications because it could cause users to believe their locations are being tracked.
On API level 30 and earlier, access to some Bluetooth APIs requires location-related permissions, and access to these APIs while the app is in the background 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.
### BLESSED
......