Public-Mesh-Research-Report.md

@@ -129,12 +129,22 @@ Bluetooth Low Energy is a separate protocol from Bluetooth classic that is desig
 
 #### Security
 
-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 sends a device's Bluetooth MAC address, along with the Bluetooth Identity Resolving Key to an adversary running a spoofed BLE central. In most public mesh protocols, users publish some sort of publicly-identifiable address to the network so that other users in the network can properly route intended messages to their address, so at first this 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 utilizing the public mesh application.
+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.
+
+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.
+
+The attack also allows the attacker to exploit the silently created pairing to act as a trusted peripheral such as a Bluetooth keyboard, giving the attacker control over the victim's device.
 
 ##### Pairing Fix
 
-With our BLE work on this project, we have put together a patch for the BLESSED library that we are using, which fixes this vulnerability by proxying GATT read and write values to remove the authentication flag which triggers automatic pairing. [TODO link the patch when we are eventually able to]
+As part of our BLE work on this project, we have put together a patch for the BLESSED library that we are using, which fixes this vulnerability by proxying GATT read and write values to remove the authentication flag which triggers automatic pairing. [TODO link the patch when we are eventually able to]
+
 Our fix is heavily based on work by the COVIDSafe Android application team. The current version of the fix uses Java's reflection API to extract a specific field in the active `BluetoothGatt` object, and replace it with a proxy object that runs an `InvocationHandler` checking for characteristic read and write invocations.
+
 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>