Since release the COVIDSafe application has been downloaded over 5 million times, seen software updates for both Android and iOS and now, two weeks after release, has the source code available for public review. In addition, Google and Apple have released draft documentation for system level contract tracing and the open source community has begun to develop additional contract tracing techniques. With all the above progress in mind we thought it would be timely to follow up our initial review with future analysis, some updates to the initial issues we highlighted and discuss progress of open source efforts.

Overview of COVIDSafe

COVIDSafe, the Australian Government contact tracing application is designed to automate and enhance the contact tracing work that is already being done by teams in the state health departments. This works by using Bluetooth as a beacon to keep a record of interaction of all of the other devices that have COVIDSafe installed. Understandably there was a level of public concern around such an extraordinary measure and had opened a lively public debate. This prompted us and a number of other groups to review both the security and function of the application. Details of the application specifics can be found in our initial review.

A timeline of events and releases over a busy two weeks are shown below:

• (26/4/2020) App listed on the Android and Apple App stores (V1.0.15 Android, V1 iOS)

• (27/4/2020) Q Team initial COVIDSafe Analysis

• Community review found no tracking, some bugs highlighted, high battery use etc.

• (4/5/2020) Updated app fixing user-interface issues (V1.0.16 Android, V1.1 iOS)

• (8/5/2020) Source code released for iOS and Android applications

• (13/5/2020) Update app with functional application issues, including some Bluetooth errors, fixed (V1.0.17 Android, V1.2 iOS)

• (15/5/2020) Updated application source code released for V1.0.17 Android, and V1.2 iOS

• (8/5/2020 – 15/5/2020) This report

‍

The technical aspects of the application continue to work as described, and in testing it manages to pick up most of the enrolled devices that come within range of the device. There were noted issues with iOS devices not being able to scan for devices when the application is not in the foreground, and occasionally stopping advertising.

Since our initial review we have also been in communication with the digital transform agency (DTA, the Federal government agency responsible for deployment of the application) following up on several of the outcomes of the initial review and have subsequently made connections between the DTA and other open source researchers to help share their findings. We see the ability to work with, and report bugs within, such widely deployed software as key and highlights the importance of open source review.

Most of the UI bugs that were found were subsequently patched in the first update that the DTA released. Some of the underlying functional bugs have been fixed in a later release this week (commit 696e4ed498623a763b3fefc6982d2567691ea48d), this represents a rapid remediation of any of the bugs that are being found in the application and highlights the focus the government is placing on this.

What could be considered a high standard of technical work and has gone on amongst a backdrop of Senate questioning, public concern, and criticism. This suggests competent internal project management and technical leadership keeping the project on track.

This has been slightly tempered by the mixed communications that have been coming from the DTA. Claims about what the application is capable of doing, delays in release of the source code, and very one-sided communications with people that have been trying to help report vulnerabilities. While we have had no problems directly, we have organized communications channels with several researchers who have mirrored our experiences.

Notes from the Source Code Release

Regardless of these teething problems the source code for the iOS and Android applications was eventually released via GitHub for the general public to be able to review. The repository the source code is in was immediately archived. Archived repositories are placed in a read-only state that prevents anybody from being able to collaborate but does still allow  reading and downloading of the source code.

There was some confusion and speculation over the weeks leading up to the release as to whether the code would be released open-source or not. Given the method of the release it can be inferred that transparency is a goal of the COVIDSafe team but that there is no intention to create a collaborative open-source community around the application.

The source code was again updated 48 hours after the latest version release. Continuing updates of the source code, albeit still being read only, is a strong indicator of a genuine intent to provide transparency.

‍

After examination of this source code we did not find any malicious functions or anything signaling a departure from the intent of the application. It is worth noting up front however that the entirety of the source code was not released.

The following was missing for this source release:

• The source for the backend application, including the algorithm for determining which detections to provide to the contact tracers.

• The lack of backend source code provides a significant impediment to security researchers who are trying to provide independent analysis and assurances as to the safety of the application.

• Comments that would otherwise have been in the source code had been stripped out

• There were no unit tests in the repository(It is possible that the unit tests were removed along with the source code)

These missing comments and unit tests make analysis slower but could be attributed to the DTA’s internal code release procedures.

‍

There were no major issues in compiling the application from source. There were some missing dependencies in the Android version, and a mock backend needed to be stood up in order to use the application. This allowed for full testing of the capabilities and was able to be stood up within an hour.

Standing the application up allowed us to validate our initial findings from the reverse engineering report.

The project team was able to confirm that:

• When a user uploads their data to the datastore it sends a list of all contacts with enrolled devices in the payload, not just the contacts that have been greater than 15min and within 1.5 metres.

• The model name of all the phones that the app detects are sent as part of the package to the datastore. It is probable that this is to determine the distance between the contacts, however it is impossible to validate this without the release of the backend code.

• No GPS location is used in the application or reported back to the server.

• The payload is encrypted in transit between the client device and the backend servers.

• The functionality of the application while in the background on iOS deteriorates partly because of protocol design, and partly because of a bug that has already been reported to the DTA.

• The rotation of the AnonymousID is controlled by the backend code and could theoretically be changed to a shorter timeframe (approx. 15 minutes) to reflect suggested best practices.

• The Bluetooth protocol that has been used in order to make this work was never designed for this use-case. This causes functional issues and it is likely that without a move to a new protocol with the support of Apple and Google it will be impossible to continue improving the contact tracing capability of the application while still maintaining the highest standards of user privacy and security.

Having analysed the source code and the behaviour of the application the research team was satisfied that, while the application still had some functional bugs, for most people it did not represent an increase to their standard attack surface.

What Could be Improved

There are two main areas of focus that the COVIDSafe project team and DTA need to focus on in order to improve the application:

Communications

The largest impediment to the COVIDSafe app is the communications between the DTA, the community at large, and the tech community. This communication is critical to trust, which in turn is critical to accelerating the community uptake and helping slow the spread of any future COVID clusters in the community. There would be a couple of initiatives that the DTA could implement in order to improve these communication channels:

1. Implement a bug bounty program, this will formalize the communication channels for many of the researchers who report that they have been reaching out to no response. Bug bounty programs allow for researchers to be acknowledged, and often compensated, for finding vulnerabilities in software.This is a well-worn communication channel and will provide the DTA with a set of well tested processes that could be swiftly and comfortably integrated into their project.
2. Provide clear and accurate explanations of the shortcomings of COVIDSafe to the general public. There are always bugs and performance issues with applications, especially those that have a rushed development and deployment timeline. However, the discrepancies between the performance of the application during testing and the information that has been disseminated to the general public appears to be causing an avoidable erosion of trust in COVIDSafe.

Bluetooth Protocol

The Bluetooth protocol that is being used in the COVIDSafe application was never intended to be used in this manner, while this is a very smart workaround for the problem and has meant that the government has been able to implement this without having to use GPS data. However, the tradeoff is unexpected behaviours, some of which have already been found and reported to the DTA by ourselves and others.

While this rapid deployment is commendable, there are now a number of options that we believe provide a better tradeoff between privacy and functionality

These are:

1. TheGoogle/Apple decentralized framework (Apple, 2020) is currently in beta. This framework applies decentralization to the contact tracing problem. It works in a similar way to the COVIDSafe application, enrolled phones record their contact with other enrolled phones through Bluetooth contact. There is no need for GPS location, and there is no PII transferred between the devices. The two largest differences are that the Bluetooth protocol that is being used is being built around this use case, and personally identifiable data never needs to be sent to the central data-store. Instead, the Google/Apple protocol solves this issue by uploading only the ID of the user that has tested positive. This allows all other devices to check whether or not they have been in contact with the user who has tested positive. When a device finds out that it has been exposed it notifies the user that they need to get tested.
2. Negotiating with Google/Apple to use their new protocol while still using the new Bluetooth framework. Google and Apple originally announced that they would not allow any country to use their protocol without guaranteeing that they would run an entirely decentralized model. However, many countries are now using a similar version of the BlueTrace model. If it is possible to come to an agreement between all these countries and Apple/Google it would significantly improve the performance of the application and offer extra security and privacy protections for users.
3. The above options require use of Apple & Google supported deployments. If this is not feasible a third option has been proposed by Jim Mussared. The Fountain Codes technique is outlined in the section below.

The above options focus largely on functional issues in the application.Battery usage is also an additional concern for these contact tracing applications. In general battery usage is maximised when the application required focus and can largely only be changed with operating system level changes to the policies that require this. This alludes to the attractiveness of having Google and Apple involved in the implementation of the contract tracing solution.

In an ideal word we would love to see an implementation of the Fountain Codes technique at an operating system level to give the best balance of device privacy and battery optimisation.

The Fountain Codes Technique

The current implementation of COVIDSafe uses a GATT server connection (Bluetooth SIG, Inc., 2020) (Bluetooth LE protocol server) in order to transfer the AnonymousID. This method creates a connection between the two phones as if one were a peripheral (e.g. a smart watch). The system uses the connection between thetwo phones in order to pass the AnonymousID. This protocol was not designed for long term advertisement and communication between devices and has led to someof the functional bugs already mentioned in this report.

In contrast, the Fountain Codes technique, which we have been reviewing over the last week, has no reliance on GATT connections and uses only a combination of scanning and advertising to pass the AnonymousID securely.

To implement this technique the application:

1. Splits the AnonymousID up into transmittable blocks using the Fountain Codes technique (Mackay, 2005)
2. Advertises one of the blocks to other phones for a short period of time before rotating to another block
3. Simultaneously scans for other phones and records all the blocks that it finds, without having to create a connection
4. Runs a worker in the background to find any sets of blocks that could be combined in order to rebuild an AnonymousID
5. Only records the contacts of those devices where there are enough blocks to piece together an AnonymousID

‍

This technique not only avoids using a GATT server, but by using fountain codes it also ensures that a minimum number of scans would be required before it was possible to log the interaction. A minimum scan count would ensure that two devices momentarily passing each other on the other side of the street would not be at risk of registering a contact.

Implementing the Fountain Codes technique would have the tradeoff of only being functional on iOS devices when the COVIDSafe application is in the foreground, however it comes with greater privacy and security protections for the user. The use of the new Google and Apple Bluetooth protocols would be a preferable option, however if those are not feasible then the research team believes that the Fountain Codes technique provides the better functionality/privacy tradeoff.

Conclusion

‍

After two weeks of wide scale deployment of the COVIDSafe application appears to be operating largely as intended and described. After reviewing the released source code we found no areas of concern and were largely in line with our initial reverse engineering effort.

Since initial release, there have been two subsequent updates to the application. One within a week of launch solving minor UI and UX issues, and another approximately 10 days later that solved a number of functional bugs highlighted by the Q Team and the security community. Though there have been communication issues, this suggests that researcher feedback is being prioritized. The only critical suggestions that the research team has for the application are some minor communications adjustments and Bluetooth protocol changes.

From a security point of view the application does not appear to increase the attack surface for most individuals, those with unique security circumstances or who are at high risk should consider not using the application until there are further changes to the Bluetooth protocol (this includes, but is not limited to victims of domestic violence where the perpetrator has a high level of technological competence).

After reverse engineering the code from the COVIDSafe applications, analysing the source code that was released, and testing the application in a dummy environment, the research team is content that COVIDSafe is an innocuous application that should be considered safe to download for most people.

References

Andrieux, F.  (2018, June 10). INTRODUCTION TO FOUNTAIN CODES: LT CODES WITH PYTHON.  Retrieved from FRANPAPERS:  https://franpapers.com/en/algorithmic/2018-introduction-to-fountain-codes-lt-codes-with-python/

AppBrain. (2020).  AppBrain: COVIDSafe. Retrieved from AppBrain:  https://www.appbrain.com/app/covidsafe/au.gov.health.covidsafe#changelog

Apple. (2020). Privacy-Preserving  Contact Tracing. Retrieved from Apple:  https://www.apple.com/covid19/contacttracing

Bluetooth SIG,  Inc. (2020). Bluetooth Generic Attributes. Retrieved from Bluetooth:  https://www.bluetooth.com/specifications/gatt/

Mackay, D. J.  (2005). Fountain Codes. IEE Communications, 1062-1068.

Acknowledgements

This analysis would not have been possible if not for the hard work of:

·        Ms. Jessica Glenn

·        Mr. Jim Mussared

·        Dr. Jae Daniel

·        Mr. Linton Hart

·        Mr. Paul Smith

·        The contributors to GHIDRA

·        The contributors to Jadx

‍

‍