Thursday, 14 May 2020
A discussion of privacy and security issues around the COVIDSafe contact tracing app.
Infectious diseases can spread in an exponential fashion and containment is a key strategy in halting the spread of disease during an epidemic. Containment requires rapid identification and quarantine of infected individuals and identification of those with whom they have had close contact in the days and weeks when they may have been infected. Accurate and timely collection of the infected individual’s contact history and location help to achieve containment. In the context of the containment of new COVID-19 cases, the use of a tracing app installed on mobile devices can provide more accurate tracing of the contacts a person has made. Singapore has been using an app called TraceTogether and the Australian Government has just released an app called COVIDSafe, somewhat similar to the Singapore model. Such apps use Bluetooth technology, which connects two nearby devices together using short-range wireless communication technology. Google and Apple have announced a joint effort to develop APIs at the operating system level for a privacy-preserving contact tracing system (“Exposure Notification System").
Basic Bluetooth-based Contact Tracing Operation
As part of the user registration process, the users will typically be asked to submit their mobile phone number and some other information such as their name. Every Bluetooth mobile phone device has a unique 48-bit address. If two Bluetooth devices do not know each other, then one device sends out a request, and any device listening for such a request will respond with its address (and possibly other information such as its name). What is shared when two mobile phones pair up can vary but typically a range of information can be shared including the Bluetooth address of each device.
Two mobile phones pair with each other when they come into proximity (e.g. 1.5m, based on signal strength) and share their identifiers. The app in both the phones encrypts this shared information and stores it in an encrypted form. So, when a person comes into contact with other people, the encrypted information of each of those contacts will be stored in the person’s mobile phone. Users are not allowed to modify these records. If a person tests positive for an infection and becomes the subject of contact tracing, that person will be asked by the relevant health authority to provide access to his/her mobile phone’s encrypted data store.
The encrypted identifiers will be uploaded to a backend (cloud) server. The health authority, using its correct key, will be able to decrypt the data on the server to obtain the list of plain identifiers. As the health authority knows the mapping between the plain identifiers and mobile phone numbers, it can identify all the people this person has had contact within the previous 21 days and hence can get in touch with potentially infected people.
In order to understand better whether the tracing app can be trusted, it is important to look at the privacy and security issues involved.
There are several potential privacy considerations such as protecting the identity of users, obtaining user consent before using the data, users having control over their data, how long is the data stored and using the data only for the purpose for which it is collected.
User Identity: First, to protect users’ privacy, the shared information between the mobile phones should not reveal users’ identity. That is, the shared information should not include personally identifiable identifiers. Furthermore, to prevent users being tracked over time by third parties, these identifiers should not be static. They need to be continuously changing. To mitigate the impact of replay attack, the lifetime of these temporary identifiers must be short. Furthermore, to reduce false positives, the lifetime of temporary identifiers should be less than (or similar to) the assumed threshold duration of close contact (e.g. 15 mins).
From the information provided by the Australian Government on their website, the COVIDSafe app records the following shared information or ‘contact data’: (1) the encrypted user ID, (2) date and time of contact, and (3) Bluetooth signal strength of other COVIDSafe users with whom the person has come into contact. The user ID is in encrypted form so as to not to reveal any personally identifiable information. The encrypted user ID is updated every 2 hours. In my view, it would have been preferable to have this update every 15 mins or so to reduce to mitigate better the impact of replay attacks. These IDs will be logged in the National COVIDSafe data store operated by the Digital Transformation Agency for contact tracing.
User Consent: When a person becomes the subject of contact tracing, the health authority needs to obtain the consent of that person before obtaining encrypted data from their mobile phone. With COVIDSafe, the health authority sends the person a one-time code and the person grants consent by entering the code into their mobile phone. Encrypted data from the user’s phone can now be uploaded to the Commonwealth Government data store. Protection of Data: The next privacy issue is concerned with the protection and control over the shared information stored. As the shared information stored in the mobile device is in an encrypted form (encrypted User IDs in COVIDSafe), the threat to this data is minimised. The encrypted user IDs are uploaded to the backend (cloud) server, which is assumed to be secure having strong protections.
Control over Data: As the data stored in the backend (cloud) server is encrypted, it is can be decrypted by only those people who have access to the correct key (assuming a strong encryption mechanism has been used). If the correct key is only known to the health authority, then only the health authority will be able to decrypt the data on the server to obtain the list of identifiers. Hence, the security of identifying data is dependent upon the secrecy of this decryption key. It is critically important that the decryption key is protected and stored in a secure place that is separate from the place where the encrypted data is stored. A common mechanism is to encrypt the decryption key itself with a master key. This will be especially useful if there are many decryption keys, which may be the case in a large-scale system, with many users. However, the problem now becomes the protection of the master key. Several key management approaches are possible, but we will not delve into these technical details here. There is a further privacy issue when it comes to the data stored in the cloud server. The data is subject to the laws of the country where the cloud server resides. If the server resides in Australia, then it will be subject to Australian law. However, if the server is owned by a foreign subsidiary, in some cases, the data can be subject to the laws of the country in which the parent company is registered.
Deletion of Data: Further privacy issues may arise when it comes to the deletion of stored encrypted data in the backend (cloud) server. With COVIDSafe, the Australian Government website has outlined a mechanism by which users can request the deletion of their data. Uninstalling the app will not delete information which has already been uploaded to the server; also, a person’s data may even have been stored in another user’s mobile device within the last 21 days and this could still be uploaded to the server and used for contact tracing purposes.
Fundamental Privacy Question: This brings us, I suppose, to the fundamental question when it comes to privacy: will the collected data be used only for the purpose for which it has been collected? Will the data be solely used for the purpose of contact tracing in the context of COVID-19, and nothing else? This also means that this data should not be accessible by any other application or service, now and in the future. Though the Biosecurity Act makes the secondary use of data illegal, it would be helpful to provide the privacy guarantees by passing specific privacy legislation related to data collected by this app and approved by Parliament. This would remove any ambiguity.
There are also several security issues concerning the app such as whether the app can counteract Bluetooth security attacks, battery exhaustion attacks, patching mobile operating systems and security accreditation.
Security Attacks: There can be several attacks that are specific to the Bluetooth protocols used by mobile devices. They can range from attackers gaining access to a device by exploiting firmware and protocol flaws (especially in older versions of mobile phones) to attacks leading to injection and stealing of data. For instance, in some versions of Android, an app on the mobile phone can maliciously access a Bluetooth channel of another app or different Bluetooth permission profiles potentially leading to malicious data injection or data stealing attacks.
Another common attack is the replay attack in which an attacker captures messages being transferred between the mobile devices. For instance, attackers can replicate the message and even though they are not able to modify the encrypted IDs, they can replay it across multiple locations to make it appear as if the compromised user had close contact with other devices. Reducing the validity period of temporary encrypted IDs can help to minimise such attacks. This will enable the backend (cloud) server to reject the records associated with the expired IDs after checking their timestamp and validity (depending on the ID structure).
Draining Power: The contact tracing app needs to be running in the background all the time. If there are several mobile phones nearby at any given time, then the pairing will happen with each one. If this were to occur often, then this can lead to a greater amount of battery power being used. Consider, for instance, the case of university lecturers. Potentially a lecturer can come in contact with hundreds of students (especially in first year lectures), leading to drain of phone battery power as well as increase in data stored in the phone. Further, this could potentially result in numerous staff and students being asked to quarantine should just one of them test positive. The more tightly meshed the staff and student population are, the more likely it is for a single event to have widespread ramifications across a campus environment. Attackers can also attempt to drain the battery of other mobile phones by transmitting fake Bluetooth IDs.
Patching Mobile OS: It is important that vulnerabilities are regularly patched at the operating system level in mobile phones. The app itself can notify users if it detects an outdated operating system, prompting users to update. However, updating has its own challenges. In the current environment, with different devices having different versions of operating systems (especially in the case of Android), vendors may release their updates under a cadence of their own choosing. Some may even cease support for specific hardware models of mobile phones, after short periods of time, potentially leading to vulnerabilities including those affecting the Bluetooth protocol remaining on devices. For users with sensitive applications and/or data requiring higher assurance requirements, one solution is always to continue with security hardening mechanisms for these devices and have Bluetooth disabled. In such cases, these users may carry separately an additional mobile device with the COVIDSafe app.
Security Accreditation: To counteract these various security attacks and vulnerabilities, it is important that the COVIDSafe app has the necessary security mechanisms and it has been developed in a secure manner. It is vital that a thorough code analysis of the app needs to be done to ensure that the code does not contain any security vulnerabilities. It is unlikely that the app by itself should introduce additional vulnerabilities. However, it is critical that this security analysis is done by an agency such as the Australian Signals Directorate (ASD) prior to the public release of the source code of the app; the public release of the code can itself help attackers to discover and exploit vulnerabilities, if there are any.
Having said all this, one should not lose sight of the bigger picture here. The whole premise of contact tracing is rapid and effective identification and quarantine of infected individuals, with the goal of containing the COVID-19 pandemic. This will help to save lives and livelihoods.
Hence the effectiveness of the contact tracing app is significant. For instance, some sections of the population may not have a smart mobile device such as the elderly, who it is believed are more susceptible to the coronavirus than others. There are also other high-risk individuals who may choose not to use the app given the volume and type of people they interact with. Anecdotally, it appears some GPs may not be willing to use the app as they are more likely to cross paths with infected individuals and may as a result be more likely to be asked to quarantine if a contact tests positive.
False Positives & False Negatives
With any technique, there is also the potential for false positives and false negatives, which impact its efficiency. There can also be slight differences in the implementation of Bluetooth technologies in different phones from different manufacturers that could contribute to false negatives and positives. There are a couple of ways in which false negatives can occur. For instance, an interaction with someone that lasts for less than the contact threshold time (e.g. 15 mins) but may still transfer the infection. The way the app is designed, such interactions may not be captured. If they cause infection, then these would be missed. Similarly, an interaction with someone outside the contact range (e.g. 1.5m) may transfer infection but will be missed by the app. There can also be false positives caused by interactions that last over 15 mins but do not cause infection, and interactions with people who are nearer than 1.5m but do not result in infection. These interactions will be captured by the app and the contacts traced, though these may not be necessary. False negatives are more relevant as some contacts leading to infection have been missed; false positives may lead to authorities tracing contacts who may not have been infected (and hence reduce overall efficiency), but ultimately can help to achieve containment.
28 April 2020
Professor Vijay Varadharajan
Global Innovation Chair in Cyber Security, The University of Newcastle
The University of Newcastle acknowledges the traditional custodians of the lands within our footprint areas: Awabakal, Darkinjung, Biripai, Worimi, Wonnarua, and Eora Nations. We also pay respect to the wisdom of our Elders past and present.