I wrote a critical piece about the Google Apple Contact Tracing (GACT) platform a few days ago. This resulted in quite some discussion, which brought some more arguments to the fore, that I would like to address and clarify here. Here I focus on my area of expertise: privacy. My colleague Tamar Sharon wrote an eloquent article about the (much) broader picture, that we should definitely not lose sight of.

Quite a few people actually like the GACT platform. According to them, the platform protects privacy, because it uses a decentralised form of contact tracing (where no central server learns who were in close contact). Moreover, if Apple and Google only offer access to the Bluetooth hardware (necessary to do contact tracing in the first place) through this interface, this would prevent apps form doing contact tracing in a centralised way (where the central server does learn which people were in close contact). In this view, the move by Google and Apple saves the whole world from a centralised contact tracing disaster.

I beg to differ, however, for the following reasons (expanding on my previous blog post and clarifying some of my arguments).

How GACT works

First, let’s describe in a little more detail how GACT is supposed to work. Notice that some of this is a good faith effort: the published specifications (Google, Apple) are sparse and still in flux. For example, the version I saw earlier mentioned that apps could see the location where a contact took place. This is no longer the case in the current versions of the standard.

Detecting nearby phones

Phones detect proximity of other phones by broadcasting random looking proximity identifiers over Bluetooth while listening for such random looking identifiers of phones nearby. A phone stores all proximity identifiers it receives in a local database, together with an estimate of the distance between the two phones (based on the signal strength). Identifiers received more than 14 days ago are deleted.

These random looking proximity identifiers are generated as follows. Each phone (or other device) generates a random tracing key once. From this tracing key a daily tracing key is derived each day. And from this daily tracing key the proximity identifiers are generated, generating a new identifier whenever the MAC address of the Bluetooth interface changes, which is every 10 to 20 minutes. A hash function is used to derive the daily tracing key and the proximity. This ensures that given two different proximity identifiers you cannot determine whether they belong to the same device. In particular, you cannot recreate the daily key used to generate them. (This preserves privacy against eavesdroppers.) However, if you know the daily tracing key of a device, you can generate all proximity identifiers the device broadcast that day. This allows the contact tracing to work, even though the proximity identifiers look random and cannot normally be linked to each other.

This generating, broadcasting and collecting proximity identifiers happens as soon as users install an Android or iOS update containing the new standard, presumable after giving explicit consent to this (and assuming users have enabled Bluetooth to begin with). It is important to note here that this is not limited to users that actually have a Covid-19 tracing app installed.

Notifying contacts

Users can only notify or be notified if a Covid-19 tracing app is installed on the device. This app uses the API provided by the GACT platform that offers (controlled) access to the set of daily keys used by a phone, and the database of proximity identifiers it collected from other nearby phones over the last 14 days.

Google and Apple themselves only standardise the API and the scanning phase described above. They (apparently) do not provide a service that coordinates the notification of contacts. This has consequence for how the API works, and hence what the contact tracing app sees and what the servers used by the contact tracing app see.

Whenever a user tests positive, the daily keys his or her devices used the last 14 days can be retrieved by the app through the GACT API, presumably only after an authorised request from the health authorities. How this exactly works, and in particular how a health authority gets authorised to sign such request or generate a valid confirmation code is not clear (yet).

The assumption is that these keys are submitted to a central server set up by the contact tracing app. Other instances of the same app on other people’s phones are supposed to regularly poll this central server to see if new daily keys of phones of recently infected people have been uploaded. Another function in the GACT API allows the app to submit these daily keys to the operating system for analysis. The OS then uses these keys to derive all possible proximity identifiers from them, and compares each of these with the proximity identifiers it has stored in the database of identifiers recently received over Bluetooth. Whenever a match is found, the app is informed, and given the duration and time of contact (where the time may be rounded to daily intervals).

The problem with GACT

Contact tracing moves from the app layer down to the OS layer

Google and Apple announced they intend to release the API’s in May and build this functionality into the underlying platforms in the months to follow. This means that at some point in time operating system updates (through Google Play Services updates in the case of Android) will contain the new contact tracing code, ensuring that all users of a modern iPhone or Android smartphone will be tracked as soon as they accept the OS update. (Again, to be clear: this happens already even if you decide not to install a contact tracing app!) It is unclear yet how consent is handled, whether there will be OS settings allowing one to switch on or off contact tracing, what the default will be.

Also it is unclear whether switching off Bluetooth will actually affect the contact tracing capability (i.e whether switching off Bluetooth will switch of all Bluetooth services except the Bluetooth hardware and the contact tracing functionality. (This is one of the reasons why a physical on-off switch for both WiFi and Bluetooth, that is known to switch off these networks at the hardware level, is desirable.)

As I wrote earlier this change has serious ramifications:

Instead of an app, the technology is pushed down the stack into the operating system layer creating a Bluetooth-based contact tracing platform. This means the technology is available all the time, for all kinds of applications. Contact tracing is therefore no longer limited in time, or limited in use purely to trace and contain the spread of the COVID-19 virus. This means that two very important safeguards to protect our privacy are thrown out of the window.

Moving contact tracing down the stack fundamentally changes the amount of control users have: you can uninstall a (contact tracing) app, you cannot uninstall the entire OS (although on Android you can in theory disable and even delete Google Play Services).

This (technically) creates a dormant functionality for mass surveillance

But the bigger picture is this: it creates a platform for contact tracing that works all across the globe for most modern smart phones (Android Marshmallow and up, and iOS 13 capable devices) across both OS platforms. Unless appropriate safeguards are in place (including, but not limited to, the design of the system as described above – we will discuss this more below) this would create a global mass-surveillance system that would reliably track who has been in contact with whom, at what time and for how long. (And where, if GPS is used to record the location.) GACT works much more reliably and extensively than any other system based on either GPS or mobile phone location data (based on cell towers) would be able to (under normal conditions). I want to stress this point because some people have responded to this threat saying that this is something companies like Google (using their GPS and WiFi names based location history tool) can already do for years. This is not the case. This type of contact tracing really brings it to another level.

Even though the data collection related to contact tracing starts as soon as you accept the operating system update, real contact tracing only starts to happen when people install a contact tracing app that uses the API to find contacts based on the data phones have already collected. But this assumes that both Apple and Google indeed refrain from offering other apps access to the contact tracing platform (through the API) through force or economic incentives, or suddenly decide to use the platform themselves. GACT creates a dormant functionality for mass surveillance, that can be turned on with the flip of a virtual switch at Apple or Google HQ.

GACT is leveraged because contact tracing apps are required to use it

Apple and Google’s move is significant for another reason: especially on Apple iOS devices, access to the hardware is severely restricted. This is also the case for access to Bluetooth. In fact, without approval from Apple, you cannot use Bluetooth ‘in the background’ for your app (functionality you need to collect information about nearby phones even if the user phone is locked). Some people have interpreted GACT as a way for Apple to say: if you want to build a contact tracing app, you need us to give you special access to Bluetooth. We are not going to give you that. Instead, we allow you to use the GACT API. If this is the case, it would prevent downright centralised implementations of contact tracing (like the ones favoured by the European Commission apparently). Seen from this light, the GACT platform strengthens privacy. (If we trust Apple and Google).

This means the contact tracing microdata is under Apple/Google control

Seen from another angle however, it creates an enormous leverage for the GACT platform, as it essentially becomes the only way to do contact tracing using smartphones in the first place. With this move, Apple and Google make themselves indispensable, ensuring that this potentially global surveillance technology is forced upon us. And as a consequence all microdata underlying any contact tracing system is stored on the phones they control.

(Note: some people have claimed that Apple would offer other distributed contact tracing solutions (and in particular DP-3T) access to Bluetooth. This has not been confirmed however.)

All in all this means we all have to put a massive trust in Apple and Google to properly monitor the use of the GACT API by others, as well as trusting that they will not abuse GACT themselves. They do not necessarily have an impeccable track record that warrants such trust…

Distributed can be made centralised

The discussion in the preceding paragraphs implicitly assumes that the GACT platform truly enforces a decentralised form of contact tracing, and that it prevents contact tracing apps from automatically collecting information on a central server about who was in contact with who. This assumption is not necessarily valid however (although it can be enforced provided Apple and Google are very strict in the vetting process used to grant apps access to the GACT platform).

In fact, GACT can easily be used to create a centralised from of contact tracing, at least when we limit our discussion to centrally storing information about who has been in contact with an infected person.

The idea is as follows. GACT allows a contact tracing app on a phone to test daily tracing keys of infected users (which the app has to download from a central server) against the proximity identifiers collected by the phone over the last few days. This test is local; this is why GACT is considered decentralised. However, the app could immediately report back the result of this test to the central server, without user intervention (or without the user even noticing). It could even send a user specific identifier along with the result, this allowing the authorities to immediately contact anybody who has recently been in the proximity of an infected person. This is the hallmark of a centralised solution.

In other words: the GACT technology itself does not prevent a centralised solution. The only thing preventing it would be Apple and Google being strict in vetting contact tracing apps. They could already do so now, without rolling out their GACT platform. Which begs the question what the real purpose of this platform is….

Malicious apps can learn which people an infected person has been in contact with

The centralisation mechanism outlines above does not reveal which infected person this particular user has been in contact with. So far however, the GACT API does not seem to put a minimum on the number of keys that the app can test. This means that if the app tests all daily tracing keys one by one, it could keep track of each daily tracing key for which the test was positive, and report these back to the server. As the server knows which daily tracing key belongs to which infected person, this allows the server to know exactly with which infected persons the user of this phone has been in contact with. What’s worse, the current version of the API allows the app to retrieve the duration of the contact in 5 minute increments, and even when the contact occurred (although that timestamp may have reduced precision such as within one day of the actual time).

Even if the GACT API would put additional restrictions in place (test at a least a minimum number of keys at the same time, and restrict the number of times keys can be tested), the API could still be abused to obtain some additional information that allows the server to link people, for example by performing timing correlation attacks, or testing sets of keys that are constructed in such a way that they belong to people known to be from different geographical regions.

Malicious app can also track non-infected persons

The GACT API is supposed to release the daily tracing keys of an infected user only after receiving a one-time confirmation code from the health authorities)[https://www.getrevue.co/profile/caseynewton/issues/apple-and-google-answer-our-questions-239830]. How this should work is not described yet, however. Regardless, abuse is certainly conceivable.

For example, if the (health) authorities themselves are malicious (which is not an entirely unreasonable assumption in certain countries), then such a confirmation code is useless. In other words, a malicious app could act as if the user is infected (in a way that is unnoticeable to the user) and extract the daily tracing keys and upload them to the server surreptitiously. Together with the trick outlined above, this essentially allows the providers of such a malicious app to map the full social graph (i.e. who has been in contact with who, when, where and for how long).

Google and Apple can decide to do the same at any time. Again we have to trust them not to do so, or not to be forced to do so.

Function creep

The use of contact tracing functionality as offered through GACT is not limited to controlling just the spread of the COVID-19 virus. As this is not the first corona type virus, it is only a matter of time until a new dangerous virus will roar its ugly head. In other words, contact tracing is here to stay.

And with that, the risk of function creep appears: with the technology rolled out and ready to be (re)activated, other uses of contact tracing will at some point in time be considered, and deemed proportionate.

The tracking technology could be embedded within software libraries used in innocent looking apps (or apps that you are more or less required to have installed). Ordinary smartphones containing the GACT technology could be bought by governments and other organisations to be installed at fixed locations of interest for monitoring purposes. China could consider it to further monitor Uyghurs. Israel could use it to further monitor Palestinians. You could monitor the visitors of abortion clinics, coffee shops, gay bars, ….

Contact tracing also has tremendous commercial value. Facebook used a crude version of contact tracing (using the access it had to WhatsApp address books) to recommend friends on Facebook. The kind of contact tracing offered by GACT (and other Bluetooth based systems) gives a much more detailed, real time, insight in people’s social graph and its dynamics. How much more precise could targeted adverting become?

Other concerns

Many of the attacks on DP-3T described by Serge Vaudenay also apply to GACT, like generating false possible infection alerts, and privacy risks related to the fact that the derivation of proximity identifiers from daily tracing keys is public. This allows an adversary to collect proximity identifiers and later correlate them to daily tracing keys of infected people released by the server. In other words, even decentralised contact tracing has privacy risks.

Concluding remarks

Form a purely technological perspective, decentralised contact tracing is preferred over centralised solutions because it better protects our privacy. Unfortunately embedding it in the operating system, as proposed by Google and Apple, does not make centralised solutions impossible.

This requires strong oversight by Apple and Google over the apps that want to use the GACT platform for contact tracing. Which makes the whole GACT platform a smokescreen really, as exactly the strong oversight would be required if the GACT platform was not there, and apps requested special access to Bluetooth to implement their own contact tracing technology. It is one thing to agree on a few best practices for contact tracing and force app providers to adhere to those standards. It is quite another to bake that standard into the operating system layer, active in the background, ready to be deployed.

We have to trust Apple and Google to diligently perform this strict vetting of apps, to resist any coercion by governments, and to withstand the temptation of commercial exploitation of the data under their control. Remember: the data is collected by the operating system, whether we have an app installed or not. This is an awful amount of trust….