Despite some small discrepancies the COVIDSafe application is as described and seems safe to use. Over the last 20 hours the team at AIM has been reverse engineering the COVIDSafe application for Android and iOS. The work is still ongoing, especially for iOS and has been hindered by the lack of open source code. However no obvious code obfuscation was used and we have been able to use the decompiled code to determine, how the application works, where its technical strengths are, and what we would suggest should be changed.

Much of this analysis has been based on the Android deployment, but several security best-practices such as certificate pinning and missing open source acknowledgements have also been detected in the iOS decompiled code.

With the caveat of working only with a decompiled code base rather than full source code, we could find no significant security flaws, no GPS and location tracking or unexpected server communication within the application and no behaviors significantly outside the stated purpose of this contact tracing application and no obvious security flaws.

‍

‍

How does this application work?

‍

When registering for COVIDSafe the user must provide a phone number, name (or a pseudonym), age-range, and postcode. This data is then sent to AWS servers in Australia and a One Time PIN is sent to the user via SMS to confirm details. Once the user has entered the PIN, the application requests an anonymous ID from the central server which serves as a broadcast ID, an expiry time for this ID is also generated (after which time the application requests a new ID from the server).

Having received the first anonymous ID, the application asks for the permission to use Bluetooth and on android fine-location (A quirk of Android privacy policy required in order to use the Bluetooth scanning and advertising capabilities on Android). In both iOS and Android these permissions can be revoked at any time, though the application does do a health check every 15 minutes to ensure permissions are still present. If permissions are revoked the user receives a notification when opening the application that functionality has been disabled and that these will need to be reinstated for it to run again.

The Anonymous ID is then used to advertise the presence of the device on Bluetooth so that it can be scanned by any nearby devices. This advertising seems to run almost permanently with what appears to be approximately 5 second breaks every 5 minutes.

Simultaneously, the device runs a scanning service every 36 to 43 seconds that looks for other nearby signals that are being advertised by other devices using the COVIDSafe app. This is checked by making sure that the signal includes the app's unique ID, meaning that it doesn't record interactions with devices that haven't opted in.

When a device is scanned it is saved to the local database for that application on the phone. For every interaction the application stores; the model number of the users phone, the model of the phone that was detected, the anonymous ID of the detected phone, the Bluetooth signal strength that was being transmitted, and the Bluetooth signal strength that was received.

‍

‍

Periodically a secondary service is run on the data store to remove any entries that are older than 21 days.

The local database for this application is kept in a sandboxed area of phone storage so that it is inaccessible to either the user or other applications on the users phone under normal operating conditions. Although sandboxed, this database is itself not encrypted, and while the database is

sandboxed from other applications it is possible to extract that data if using an unlocked or jailbroken operating system. This is also possible using the standard android debugging libraries if the user has access to a computer and physical device in an unlocked state.

‍

Procedure in the case of a positive test

‍

If the user is tested positive for COVID-19, current government advice is that the tracing team will then ask the user to upload the contact data that is stored on their phone. This is done by pressing the upload data button in the application, and then proceeding through a second confirmation screen. Once confirmed, a One Time PIN is sent to the user via SMS and the user is prompted to enter this PIN into the app. At this point the locally stored and sandboxed information is then packaged into an encrypted zip file and sent to the AWS servers (in Australia). to be processed and added to the data store for tracing analysis.

Based on analysis of the decompiled code, when the user uploads their data, it appears all recorded Bluetooth contact events are uploaded up to the AWS data store, not just those that are within a 1.5 metres for 15 minutes threshold. From this we can assume distance filtering is likely to occur server side, this is in line with the previously noted collection of phone models as part of the recorded data. A possible reason for this is the use of phone make and model number to better understand relative signal strengths and allow more accurate distance estimation based on the device specific Bluetooth signal strengths

‍

‍

What's good about the app?

‍

• It appears to follow best practices when it comes to network communications, including pinned certificates, mandatory HTTPS etc.
• No GPS or location tracking was detected in the application and the periodic communications with the server do not appear to contain any undisclosed device or location information.
• The data stored is stored in such a way that it is not readily available to other applications on the phone.
• The Bluetooth implementation on Android appears sound.
• Most of the code that relates to the operation of the application (Bluetooth Services, Wakeups, etc.) has been all but copied from the Singapore Government's OpenTrace implementation which is available on GitHub. This is excellent as it uses code that has been tested thoroughly and used in a production environment, instead of reinventing the application from scratch.
• It is a mostly simple and seamless user experience.

‍

What should be changed about the app?

‍

• The storage of all interactions seems excessive, there should be a minimum filtering done inside the application so that people who are 10m away aren't recorded as contacts. This can't be achieved with extreme accuracy as different environments provide different Bluetooth signals and calculating the probable distance can be out by up to 100%, but if the application filtered out all interactions that were estimated as more than 5m away that would provide a good compromise.
• If the goal is to only record interactions that are ongoing for 15 minutes or longer then the scanning doesn't need to occur as often as it does, this should be relaxed to a matter of minutes. Doing so may help alleviate any increased battery usage from the application
• The interactions that are stored on the device should be encrypted; it is best practice to assume that an Android SQLite database is not secure. Due to the use of anonymous Ids and no PII in the Bluetooth handshake, this is not clearly an immediate security risk, but would be better practice.
• The application codebase appears to lean heavily on a number of Open Source libraries, many of which are licensed under the Apache 2 license. A requirement of this license is that there is explicit acknowledgement in the application that this code is being used. Traditionally this is solved by a menu item labelled "Open Source" which leads to a listing of all of the appropriate license acknowledgements. This should be added to the next update to comply with Open Source licensing requirement. Our analysis has identified codebase from the following :

1. Lottie (AirBnB)
2. ReactiveX
3. EasyPermissions
4. ProgressButton (Razir)
5. And Retrofit

• The application is also a derivative work of the OpenTrace implementation, which is publicly released under the GNU General Public License v3 (GPLv3). This license requires derivative works that are distributed to also be released under the same license conditions. It is possible that the government has an alternative and direct arrangement with the Singapore Government (who control the copyright for OpenTrace), however if not then the code should be released immediately under the GPLv3 license.

‍

Conclusion

‍

With the absence of the promised source code it is hard to give a full analysis of the applications, especially for the iOS version. However, with the information that has been gleaned by reverse engineering the apps it seems that this is a relatively good implementation that mostly follows best practices. Given the timeframe that this was released in, this is a relatively well-made application that doesn't come with any significant security concerns and mostly meets what the Government announced. No undocumented location tracking or server communications were noticed, and storage of contact tracing appears to be entirely local to the device. We have highlighted several areas for improvement, particularly around Open Source licensing compliance .It is highly likely that the application will get better with further updates and we look forward to the promised release of the source code.

‍

Acknowledgements

‍

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

• Ms. Jessica Glenn
• Dr. Jae Daniel
• Mr. Linton Hart
• Mr. Paul Smith
• Mr. Jay Fenton
• The contributors to GHIDRA
• The contributors to Jadx