This is the latest in a series of blog posts on automated contact tracing, especially (but not only) Australia's COVIDSafe app.
The complete list is:
- Tweaking Tracetogether (30 Mar)
- Contact Tracing without Surveillance (7 Apr)
- Contact Tracing and Consent (23 Apr)
- Tracing the Challenges of COVIDSafe (27 Apr) by Chris Culnane, Eleanor McMurtry, Robert Merkel and me.
- The Missing Server Code and why it Matters (14 May) by Robert Merkel, Eleanor McMurtry and me.
- Security Analysis of the UK's NHS Contact Tracing App by Chris Culnane and me.
- COVIDSafe's new payload encryption scheme (15 June)
- Issues with COVIDSafe's new encryption scheme (19 June)
- The current state of COVIDSafe (mid-June 2020) (22 June)
- COVIDSafe issues found by the tech community (7 July, updated 24 July) - this post
Jim Mussared: jim.mussared [at] gmail.com / @jim_mussared
Vanessa Teague: ThinkingCybersecurity Pty Ltd / @VTeagueAus
Last updated: July 24th 2020, for Android v1.0.39 / iPhone v1.8. New fixes are noted below.
COVIDSafe was launched on April 26th, 2020. Several volunteers from the Australian tech community have spent considerable amounts of time analysing the code of the Android and iOS apps in order to help improve their contact tracing functionality and privacy.
Many issues have been found as well as recommendations for how to fix them, and some of these fixes have dramatically improved the effectiveness of the COVIDSafe app. In addition, several of these issues have been found and reported in contact tracing apps used in other countries.
Most, but not all, of these issues have been fixed. However, due to a quirk in the way that COVIDSafe works, it is not clear that users are actually receiving automatic updates to the app. If you haven't checked you are running the most recent version, you should check manually and update now.
COVIDSafe has had a variety of different issues affecting both its privacy and its function.
Privacy issues result in the user's privacy being compromised, especially in a way that is not mentioned in the privacy policy. This may include being able to track a user's movements.
Many of the privacy issues involve the phone exposing any type of long-term identifier. This allows the user's movement to be detected if this same identifier can be recorded at different times and places. It also allows an attacker to detect if a target device is currently present at a given location.
Security issues compromise the security of the device running COVIDSafe in ways beyond privacy. For example, being able to remote control the device.
These are issues that prevent COVIDSafe from being able to effectively perform contact tracing, such as the app not being able to detect other devices and record the contact.
Usability issues lead to user confusion or lack of confidence in the app. For example, user interface issues or minor functionality problems.
Status: Fixed
Type: Privacy
Affects: Android
More info: Issue report
The Bluetooth Low Energy advertising payload is used to discover other devices running COVIDSafe. A three-byte identifier was incorrectly re-used in every payload, which uniquely re-identifies the same device over time.
Status: Fixed
Type: Privacy
Affects: Android
More info: Issue report
For no apparent reason, the app caches the tracing payload by the remote device's MAC address. This cache entry was never removed. A device with a fixed address could therefore always re-identify a target device by detecting the same payload.
Status: Fixed
Type: Privacy
Affects: Android & iOS
More info: Issue report, Research
The V1 protocol includes the phone model, and this is available to any device in Bluetooth range. The phone model is ostensibly used for calibration of the signal strength to distance calculation, however it has been shown that this calculation does not work, and is likely not being used for contact tracing. The V2 protocol now encrypts this field.
Status: Not fixed
Type: Privacy
Affects: Android & iOS
More info: Blog post, Issue report
Due to the way COVIDSafe uses Bluetooth, some standard Bluetooth services are enabled. One of these services makes the the device name accessible to remote devices. For example, this name would be shown when pairing with a car stereo.
At best, this name defaults to the model name, but in many cases the user will have customised it, allowing for re-identification of the device, and potentially identifying the owner's name.
An attempt at a fix was made, where the Android app will prompt the user to change their device name. However this UI is confusing, it only applies to new users, and only on Android.
Status: Fixed
Type: Privacy
Affects: Android
More info: CVE-2020-12856, Summary thread, Video
An attacker could trigger a silent pairing process with an Android phone running COVIDSafe. This is completely invisible to the user, no prompt is shown. Once pairing has been completed, the target phone can be re-identified even after COVIDSafe has been un-installed and the phone factory reset.
This was registered as CVE-2020-12858 which was assigned a "Critical" 9.8 out of 10 severity rating.
Note: It is unclear whether the fix for this will still be viable past November 2020 when the Google Play Store requires API level 29.
Status: Fixed
Type: Security, Privacy
Affects: Android
More info: CVE-2020-12856, Summary thread, Video
Related to the previous silent pairing issue, once paired, an attacker can then invisibly "profile switch" and pretend to be a different Bluetooth device, e.g. a keyboard or headphones, allowing remote control of the phone.
Status: Partial mitigation
Type: Privacy
Affects: Android & iOS
More info: CVE-2020-12856, Summary thread
A non-silent version of the above issue, where a prompt is shown that says "COVIDSafe would like to pair with your phone". If the user clicks "Pair", then the above two issues become possible.
Both the Android and iPhone apps now include a prominent message that "COVIDSafe does not send pairing requests".
Status: Partially fixed
Type: Privacy
Affects: Android
More info: Coming soon
An attacker could trick COVIDSafe into connecting with the phone's identity address, rather than the random address normally used. This identity address then permanently identifies the phone, and like #5, allows for re-identifying the device even after COVIDSafe is uninstalled and the phone is factory reset.
This is only fixed when running on Android 6.0 and higher.
Status: Fixed
Type: Security, Privacy
Affects: Android
More info: CVE-2020-0022
Once the identity address of the target phone was known (via #5 or #8), any phone running Android 9.0 or lower is now vunerable to BlueFrag (CVE-2020-0022), which allows remote code execution, remote memory access, and ability to crash the system Bluetooth service.
Status: Fixed
Type: Security, Functionality
Affects: iOS
More info: Blog post, Video
An attacker could create a beacon that would remotely crash the COVIDSafe app on any nearby iPhone. The beacon would transmit a malformed advertising payload that the app would fail to handle.
Status: Fixed
Type: Functionality
Affects: iOS
More info: Blog post (part 1), Blog post (part 2)
Despite claims to the contrary that this had been fixed relative to the Singapore app, the iPhone app could not function in the scanning role while the app was not in the foreground. It would schedule a timer to stop scanning, and then never get an opportunity to start scanning again. This was fixed by no longer stopping the scan.
Status: Fixed
Type: Functionality
Affects: iOS
More info: Issue report, Blog post
The app downloads a new tracing ID every two hours, but in order to do so it needs to access the authentication token in the device keychain which it uses to talk to the Amazon server. When the token was first created, it was not stored in a way that allowed access while the device was locked.
Status: Not fixed
Type: Functionality
Affects: iOS
More info: GitHub issue
Once a remote device is found during a scan, the app will then attempt to connect and record an encounter with it every 15 seconds. This allows the duration of the encounter to be inferred, even though the background-mode scanning will not find the same device multiple times.
These connection attempts do not time out, and so for every device that goes out of range the phone will remain in an "attempting to connect" state to that device. In addition, phones change their address every few minutes, which means that any nearby phone will appear to go out of range every few minutes.
After about 100 pending connections, the phone becomes unable to connect to new devices. This prevents further encounters from being recorded, but also prevents other apps from initiating connections to other BLE devices (e.g. smart watches, diabetes continuous glucose monitoring, etc).
Status: Fixed in v1.8.
Type: Functionality
Affects: iOS
More info: Earlier blog post, GitHub issue on errors in the attempted fix
When the V2 payload was introduced (see #3 above), the iPhone implementation incorrectly truncated the new messages, resulting in the encounters being silently ignored and not logged to the database. Fortunately due to redundancy in the design, there is a second mechanism where the payload is exchanged, but this bug overall decreases the reliability of the contact tracing functionality.
A fix was attempted, however it contains a new bug, which means that while the encounters are now logged, they are actually corrupted, which means they will not be able to be decrypted by the server.
This was fixed in v1.8 for iOS.
Status: Fixed
Type: Functionality
Affects: Android
More info: Issue report, Technical details
Whilst operating in the background, the iOS app will send a differently-formatted BLE advertising payload. The Android app only understood the foreground-mode one, and so would not detect background-mode iPhones. In conjunction with iPhones not being able to operate in the scanning role in the background (#11), this made it almost impossible for any sort of encounter to be detected with or by an iPhone in the background.
This was fixed, however the fix doesn't handle a case where multiple apps are running on the iPhone that each advertise a different BLE service. However this is likely a very rare scenario.
Status: Fixed
Type: Usability
Affects: Android
More info: GitHub PR
The logo animation did not resume after a user opens and then dismisses the "share" screen.
Status: Fixed
Type: Privacy
Affects: Android & iOS
More info: Blog post
The COVIDSafe app uses a two-hour expiry for the tracing ID. This is unnecessarily long, and goes against the recommendations from the Singapore team. This allowed the device to be re-identified for a long enough window to, for example, track a user's movement around a shopping centre.
This has been mitigated in the V2 protocol by adding an extra layer of encryption. The tracing ID still lasts for two hours, but the encryption key changes every 7.5 minutes.
Status: Fixed
Type: Functionality
Affects: Android
More info: Blog post
The implementation of the V2 protocol had a concurrency bug, where simultaneous encounters would result in corrupted entries being written to the log. It also crashed the app.
Status: Not fixed
Type: Privacy
Affects: Android and iOS
More info: Blog post
The implementation of the V2 protocol uses a counter which inadvertently leaks information about the number of encounters that the device has recorded in the last 7.5 minutes.
Status: Fixed
Type: Usability
Affects: Android
More info: COVIDSafe.watch, 9 News
This was discovered by the community by inspecting the app's resources was reported as a potential issue very soon after launch. Then within a few days, there were news reports of people being confused by this.
Status: Not fixed
Type: Privacy
Affects: Android & iOS
More info: Issue report, Blog post
Any time where more than one identifier is accessible, even if they change frequently, they must all change at the same time otherwise they can be linked together. There are several known identifiers in COVIDSafe that change at different intervals:
- BLE MAC address
- BLE advertisting payload
- Tracing ID
- Phone model
- Phone name
- Encryption counter
Avoiding this issues is explicitly called out in the design of the Apple/Google Exposure Notification API.
Type: Functionality, Privacy
Status: Fixed
Affects: Android & iOS
More info: Issue report (iOS)
There were numerous issues discovered by the community in the handling of downloading and expiring tracing IDs. This resulted in scenarios where the app would regularly use the same tracing ID for longer than the two-hour expiry time.
This created a privacy issue, allowing for tracking and re-identification of devices, but also a functionality issue, as expired tracing IDs will not be counted as valid encounters.
Status: Fixed in v1.0.39 (pending UI changes)
Type: Functionality, Privacy
Affects: Android
More info: GitHub issue
Privacy-conscious users may disable the "Location" global setting on Android. As Bluetooth scanning allows an app to detect the presence of positioning beacons, having location disabled prevents an app from being able to scan for BLE devices.
COVIDSafe fails to detect this condition and will silently fail to scan for other devices. This prevents two Android phones that both have "Location" off from exchanging TempIDs with each other or with any phone affected by Issue 25. However, it should not prevent an Android phone with "Location" off from successfully exchanging TempIDs both ways in the peripheral role, with another phone that is either an iPhone or an Android phone with "Location" on (and not affected by Issue 25).
The core issue was fixed in v1.0.39 however there are some UI problems that need to be addressed when "Location" is off. The main screen tells users that it is not active, when it is active and working in most circumstances, as described above.
Status: Not fixed
Type: Functionality, Privacy, Usability, Security
Affects: Android
More info: Blog post
The Android app is unable to automatically update to new versions published in the play store.
The cause of this is not currently known, however it's likely because the app is always active while in the background, so the same logic that prevents a podcast player from updating mid-playback possibly applies.
There are also reports that a similar issue is affecting the iPhone app.
This means that many users are still running the first version of COVIDSafe they installed, and will have not received any of the fixes described above. So even the issues that are "fixed" in principle in the current version may not actually be fixed in practice on users' phones.
v1.0.39 for Android and v1.8 for iOS add support for push notifications (using Firebase Cloud Messaging and Apple Notifications respectively). However, the Android app has not yet implemented support for a "need to update" notification.
Status: Not fixed
Type: Functionality, Usability
Affects: Android
More info: GitHub Issue
The v1.0.39 release changed from using Android's "fine" location permission, to "coarse". This is a good change -- the app never needed "fine" location, so "coarse" is what it should be using. However, due to the way the change was made, after the update the app will likely have no location permission at all until the user manually opens the app to grant the new "coarse" permission.
There is a notification shown, however it's not a new notification, rather it just updates the text of the existing "COVIDSafe is running" notification, so there is no pop up. Additionally, the icon (which is the most obvious part) does not change. This means that many users will not notice that the app is now unable to scan for other devices running COVIDSafe.
Although the app doesn't actually use location, this permission (either "coarse" or "fine") is required to enable BLE scanning.
Fortunately, due to #24 above, it's likely that many users will not yet have received this update.
The Google/Apple Exposure Notification API uses Bluetooth in a very different way. If COVIDSafe had been designed to use the Exposure Notification API, it would very likely have prevented all of the functionality, privacy and security issues described above.
The Apple/Google Exposure Notification API is not perfect, and does have its own privacy implications. For example, Android requires Google location services in order to enable the API, an unnecessary invasion of users' location privacy (though one that is irrelevant to users who already turn Google location on). Compared with a centralised system like COVIDSafe, it also gives users more information about when they interacted with those who have tested positive, potentially increasing the likelihood that the source of infection could be identified and tracked during the time they were assumed infectious. However, the Google/Apple API has two overwhelming advantages: better function, and better privacy from government. It is important to understand that this is not because the database of close contacts is handed to the tech companies: the Google/Apple API is designed not to build that database.
Human contact tracers can be involved in an app based on the Google/Apple API. The Irish app allows users to opt in to giving their phone number so they can be contacted by a person if they are identified as having been exposed. The difference between this and COVIDSafe is that the authority does not receive each infected person's list of face-to-face contacts, just a notification that a particular person has been exposed.
Although there are pros and cons, there does not seem to be any reasonable analysis or understanding in government of why a centralised model has been chosen. Consider for example Minister Robert's recent attempt to explain:
there's an opportunity I think here for the big tech companies to lock step in with sovereign governments and assist them with their sovereign approach to doing tracing. Remember, digital tracing simply enhances a manual tracing process. The big tech companies with their exposure notification framework are saying that digital tracing unto itself is enough. The global experience shows quite clearly it is not enough.
The world is headed for a large and not very well-controlled empirical test, so we will soon see evidence that allows us to compare the countries with decentralised apps based on the Apple/Google API (such as Italy, Germany, Switzerland, Ireland and the UK) against those that stick with a centralised model. The Australian authorities are choosing to emphasise centralised data gathering, knowing that this carries a cost for basic successful functioning (for all the reasons described above). The global experience will soon show whether this was wise.
The source code for the the COVIDSafe server code has not been released for public inspection. For more information, please see The missing server code, and why it matters
The update of COVIDSafe has been communicated entirely in terms of "number of downloads". This is a very misleading figure, as it coveys no information about how many people are actually using the app.
The industry standard is to report "active users" over some time period. i.e. "1-day active users" are the number of unique users who are actively using the app in a 24-hour period.
As the app downloads a new tracing ID from the AWS server every two hours, using the user's unique authentication token, the server is trivially able to generate this information.
At launch there was no process for the community to report serious issues, nor has there been any management of issue disclosure.
The DTA should set up a formal process for working with security researchers for this and all future projects. A bug bounty program would be an excellent way to implement this.
The legislation created to support the COVIDSafe app, known as the Privacy Amendment (Public Health Contact Information) Act, also offers no protections to security researchers. Furthermore, the source code has been released under terms that are not conducive to community engagement.
The DTA should add code to the app to report the current version to the server when downloading the two-hourly tracing ID, allowing the server to respond with a message telling the app that it needs to be updated.
In addition, this would provide better metrics to the DTA on whether users are receiving updates.
We'd like to thank the large and active community of Australian techies who have examined, discussed, and tried to correct the code. In particular the following people (in no particular order) were involved in discovering the issues described above:
- Alwen Tiu
- Chris Culnane
- Eleanor McMurtry
- Ben Frengley
- Geoffrey Huntley
- Hubert Seiwert
- Jim Mussared
- John Evershed
- Manabu Nakazawa
- Richard Nelson
- Robert Merkel
- Vanessa Teague
- Yaakov Smith
Comments, edits, suggestions and pull requests are welcome.
You are welcome to quote or reprint this article as long as you acknowledge the original source. Permanent link: https://github.com/vteague/contactTracing/blob/master/blog/2020-07-07IssueSummary.md.