Early in the COVID-19 pandemic, I was tapped by the European Commission to develop a privacy-protecting contact tracing token, which you can read more about at the Simmel project home page. And very recently, Singapore has announced the deployment of a TraceTogether token. As part of their launch, I was invited to participate in a review of their solution. The urgency of COVID-19 and the essential challenges of building supply chains means we are now in the position of bolting wheels on a plane as it rolls down the runway. As with many issues involving privacy and technology, this is a complicated and nuanced situation that cannot be easily digested into a series of tweets. Thus, over the coming weeks I hope to offer you my insights in the form of short essays, which I will post here.
Since I was only able to spend an hour with the TraceTogether token so far, I’ll spend most of this essay setting up the background I’ll be using to evaluate the token.
Contact Tracing
The basic idea behind contact tracing is simple: if you get sick, identify your close contacts, and test them to see if they are also sick. If you do this fast enough, you can contain COVID-19, and most of society continues to function as normal.
However, from an implementation standpoint, there are some subtleties that I struggled to wrap my head around. Dr. Vivian Balakrishnan, the Minister-in-charge of the Smart Nation Initiative, briefly stated at our meeting on Friday that the Apple/Google Exposure Notification system did not reveal the “graph”. In order to help myself understand the epidemiological significance of extracting the contact graph, I drew some diagrams to illustrate contact tracing scenarios.
Let’s start by looking at a very simple contact tracing scenario.
In the diagram above, two individuals are shown, Person 1 and Person 2. We start Day 1 with Person 1 already infectious yet only mildly symptomatic. Person 1 comes in contact with Person 2 around mid-day. Person 2 then incubates the virus for a day, and becomes infectious late on Day 2. Person 2 may not have any symptoms at this time. At some future date, Person 2 infects two more people. In this simple example, it is easy to see that if we can isolate Person 2 early enough, we could prevent at least two future exposures to the virus.
Now let’s take a look at a more complicated COVID-19 spread scenario with no contact tracing. Let’s continue to assume Person 1 is a carrier with mild to no symptoms but is infectious: a so-called “super spreader”.
The above graphic depicts the timelines of 8 people over a span of five days with no contact tracing. Person 1 is ultimately responsible for the infection of several people over a period of a few days. Observe that the incubation periods are not identical for every individual; it will take a different amount of time for every person to incubate the virus and become infectious. Furthermore, the onset of symptoms is not strongly correlated with infectiousness.
Now let’s add contact tracing to this graph.
The graphic above illustrates the same scenario as before, but with the “platonic ideal” of contact tracing and isolation. In this case, Person 4 shows symptoms, seeks testing, and is confirmed positive early on Day 4; their contacts are isolated, and dozens of colleagues and friends are spared from future infection. Significantly, digging through the graph of contacts also allows one to discover a shared contact of Person 4 and Person 2, thus revealing that Person 1 is the originating asymptomatic carrier.
There is a subtle distinction between “contact tracing” and “contact notification”. Apple/Google’s “Exposure Notification” system only perform notifications to the immediate contacts of an infected person. The significance of this subtlety is hinted by the fact that the protocol was originally named a “Privacy Preserving Contact Tracing Protocol”, but renamed to the more accurate description of “Exposure Notification” in late April.
To better understand the limitations of exposure notification, let’s consider the same scenario as above, but instead of tracing out the entire graph, we only notify the immediate contacts of the first person to show definite symptoms – that is, Person 4.
With exposure notification, carriers with mild to no symptoms such as Person 1 would get misleading notifications that they were in contact with a person who tested positive for COVID-19, when in fact, it was actually the case that Person 1 gave COVID-19 to Person 4. In this case, Person 1 – who feels fine but is actually infectious – will continue about their daily life, except for the curiosity that everyone around them seems to be testing positive for COVID-19. As a result, some continued infections are unavoidable. Furthermore, Person 2 is a hidden node from Person 4, as Person 2 is not within Person 4’s set of immediate notification contacts.
In a nutshell, Exposure Notification alone cannot determine causality of an infection. A full contact “graph”, on the other hand, can discover carriers with mild to no symptoms. Furthermore, it has been well-established that a significant fraction of COVID-19 infections show mild or no symptoms for extended periods of time – these are not “rare” events. These individuals are infectious but are well enough to walk briskly through crowded metro stations and eat at hawker stalls. Thus, in the “local context” of Singapore, asymptomatic carriers can seed dozens of clusters in a matter of days if not hours, unlike less dense countries like the US, where infectious individuals may come in contact with only a handful of people on any given day.
The inability to quickly identify and isolate mildly symptomatic super-spreaders motivates the development of the local TraceTogether solution, which unlocks the potential for “full graph” contact tracing.
On Privacy and Contact Tracing
Of course, the privacy implications of full-graph contact tracing are profound. Also profound are the potential health risks and loss of life absent full-graph contact tracing. There’s also a proven solution for containing COVID-19 that involves no sacrifice of privacy: an extended Circuit-Breaker style lockdown. Of course, this comes at the price of the economy.
Of the three elements of privacy, health, or economy, it seems we can only pick two. There is a separate and important debate about which two we should prioritize, but that is beyond the context of this essay. For the purpose of this discussion, let’s assume contact tracing will be implemented. In this case, it is incumbent upon technologists like us to try and come up with a compromise that can mitigate the privacy impact while facilitating public policy.
Back in early April, Sean ‘xobs’ Cross and I were contacted by the European Commission’s NGI program via NLnet to propose a privacy-protecting contact tracing hardware token. The resulting proposal is called “Simmel”. While not perfect, the salient privacy features of Simmel include:
- Strong isolation of user data. By disallowing sensor fusion with the smartphone, there is zero risk of GPS or other geolocation data being leaked. It is also much harder to do metadata-based attacks against user privacy.
- Citizens are firmly in control. Users are the physical keeper of their contact data; no third-party servers are involved, until they volunteer their data to an authority by surrendering the physical token. This means in an extreme case, a user has the option of physically destroying their token to erase their history.
- Citizens can temporarily opt-out. By simply twisting the cap of the token, users can power the token down at any time, thus creating a gap in their trace data (note: this feature is not present on the first prototypes).
- Randomized broadcast data. This is a protocol-level feature which we recommend to defeat the ability for third parties (perhaps an advertising agency or a hostile government) from piggy backing on the protocol to aggregate user locations for commercial or strategic benefit.
Why a Hardware Token?
But why a hardware token? Isn’t an app just better in so many ways?
At our session on Friday, the TraceTogether token team stated that Singapore needs hardware tokens to better serve two groups: the underprivileged, and iPhone users. The underprivileged can’t afford to buy a smartphone; and iPhone users can only run Apple-approved protocols, such as their Exposure Notification service (which does not enable full contact tracing). In other words, iPhone users, like the underprivileged, also don’t own a smartphone; rather, they’ve bought a phone that can only be used for Apple-sanctioned activities.
Our Simmel proposal makes it clear that I’m a fan of a hardware token, but for reasons of privacy. It turns out that apps, and smartphones in general, are bad for user privacy. If you genuinely care about privacy, you would leave your smartphone at home. The table below helps to illustrate the point. A red X indicates a known plausible infraction of privacy for a given device scenario.
The tracing token (as proposed by Singapore) can reveal your location and identity to the government. Nominally, this happens at the point where you surrender your token to the health authorities. However, in theory, the government could deploy tens of thousands of TraceTogether receivers around the island to record the movement of your token in real-time. While this is problematic, it’s relevant to compare this against your smartphone, which typically broadcasts a range of unique, unencrypted IDs, ranging from the IMEI to the wifi MAC address. Because the smartphone’s identifiers are not anonymized by default, they are potentially usable by anyone – not just the government – to identify you and your approximate location. Thus, for better or for worse, the design of the TraceTogether token does not meaningfully change the status quo as far as “big infrastructure” attacks on individual privacy.
Significantly, the tracing token employs an anonymization scheme for the broadcast IDs, so it should not be able to reveal anything about your location or identity to third parties – only to the government. Contrast this to the SafeEntry ID card scanner, where you hand over your ID card to staff at SafeEntry kiosks. This is an arguably less secure solution, as the staff member has an opportunity to read your private details (which includes your home address) while scanning your ID card, hence the boxes are red under “location” and “identity”.
Going back to the smartphone, “typical apps” – say, Facebook, Pokemon Go, Grab, TikTok, Maps – are often installed with most permissions enabled. Such a phone actively and routinely discloses your location, media, phone calls, microphones, contacts, and NFC (used for contactless payment and content beaming) data to a wide variety of providers. Although each provider claims to “anonymize” your data, it has been well-established that so much data is being published that it is virtually a push of a button to de-anonymize that data. Furthermore, your data is subject to surveillance by several other governments, thanks to the broad power of governments around the world to lawfully extract data from local service providers. This is not to mention the ever-present risk of malicious actors, exploits, or deceptive UI techniques to convince, dupe, or coerce you to disclose your data.
Let’s say you’re quite paranoid, and you cleverly put your iPhone into airplane mode most of the time. Nothing to worry about, right? Wrong. For example, in airplane mode, the iPhone still runs its GPS receiver and NFC. An independent analysis I’ve made of the iPhone also reveals occasional, unexplained blips on the wifi interface.
To summarize, here are the core arguments for why a hardware token offers stronger privacy protections than an app:
No Sensor Fusion
The data revealed by a hardware token is strongly limited by its inability to perform “sensor fusion” with a smartphone-like sensor suite. And even though I was only able to spend an hour with the device, I can say with a high degree of confidence that the TraceTogether token has little to no capability beyond the requisite BLE radio. Why do I say this? Because physics and economics:
• Physics: more radios and sensors would draw more power. Ever notice how your phone’s battery life is shorter if location services are on? If the token is to last several months on such a tiny battery, there simply is not enough power available to operate much more than the advertised BLE functions.
• Economics: more electronics means more cost. The publicly disclosed tender offering places a cap on the value of parts at S$20, and it essentially has to be less than that because the producer must also bear their development cost out of the tender. There is little room for extraneous sensors or radios within that economic envelope.
Above: the battery used in the TraceTogether token. It has a capacity of 1000mAh. The battery in your smartphone has a capacity of around 3x of this, and requires daily charging.
The economics argument is weaker than the physics argument, because the government could always prepare a limited number of “special” tokens to track select individuals at an arbitrary cost. However, the physics argument still stands – no amount of money invested by the government can break the laws of physics. If Singapore could develop a mass-manufacturable battery that can power a smartphone sensor suite for months in that form factor – well, let’s just say the world would be a very different place.
Citizen Hegemony over Contact History
Assuming that the final TraceTogether token doesn’t provide a method to repurpose the Bluetooth Low-Energy (BLE) radio for data readout (and this is something we hope to confirm in a future hackathon), citizens have absolute hegemony over their contact history data, at least until they surrender it in a contact tracing event.
As a result the government is, perhaps inadvertently, empowering citizens to rebel against the TraceTogether system: one can always crush their token and “opt-out” of the system (but please remove the battery first, otherwise you may burn down your flat). Or perhaps more subtly, you can “forget your token at home”, or carry it in a metallized pouch to block its signal. The physical embodiment of the token also means that once the COVID-19 pandemic is under control, destroying the token definitively destroys the data within it – unlike an app, where too often uninstalling the app simply means an icon is removed from your screen, but some data is still retained as a file somewhere on the device.
In other words, a physical token means that an earnest conversation about privacy can continue in parallel with the collection of contact tracing data. So even if you are not sure about the benefit of TraceTogether today, carrying the token allows you to defer the final decision of whether to trust the government until the point where you are requested to surrender your token for contact trace extraction.
If the government gets caught scattering BLE receivers around the island, or an errant token is found containing suspicious circuitry, the government stands to lose not just the trust of the people, but also access to full-graph contact tracing as citizens and residents dispose of tokens en masse. This restores a certain balance of power, where the government can and will be held accountable to its social contract, even as we amass contact tracing data together as a whole.
Next Steps
When I was tapped to independently review the TraceTogether token, I told the government that I would hold no punches – and surprisingly, they still invited me to the introductory session last Friday.
This essay framed the context I will use to evaluate the token. “Exposure notification” is not sufficient to isolate mildly symptomatic carriers of COVID-19, whereas “full graph” contact tracing may be able to make some headway against this problem. The good news is that the introduction of a physically embodied hardware token presents a safer opportunity to continue the debate on privacy while simultaneously improving the collection of contact tracing data. Ultimately, deployment of a hardware token system relies upon the compliance of citizens, and thus it is up to our government to maintain or earn our trust to manage our nation’s best interests throughout this pandemic.
I look forward to future hackathons where we can really dig into what’s running inside the TraceTogether token. Until then, stay safe, stay home when you can, and when you must go outside, wear your mask!
PS: You should also check out Sean ‘xobs’ Cross’ teardown of the TraceTogether token!
I’ve looked into the key fob form factor for an open hardware / open source project. These viruses are here to stay and with worldwide travel there might be an outbreak every couple of years. Compare SARS-CoV1, MERS, now SARS-CoV2 all within last 20 years. But not everyone has a smartphone, can get one, even wants one, or knows how to use it together with a tracing app. Such a fob is an investment into protection against the next virus. Easy to carry, little room for user error.
nRF52833 was one of my candidates as well. Memory depth of TraceTogether appears wildly inadequate though. Imagine as a worst case an infected and asymptomatic football stadium seller that is walking around in a stadium of 100.000 people, selling stuff while the game is on. Also imagine it is the time of “English weeks” where every day a match happens. Theoretically this seller could infect 100.000 people times say 14 play days, or 1.4m people in this time frame. Ignore for the moment that windy outdoors significantly lowers infection risk with SARS-CoV2. How to store 1.4 million entries in such a device? When walking around in the stadium during a match, this seller’s fob could easily see all other fobs. So I think 512Mb to 1 Gb serial flash like a W25Q01JV are in order. Maybe smaller, if compression is good.
A second worst case is the asymptomatic sneezing pedestrian without mask with a bicyclist driving through the “sneeze cloud”. At a relative speed of around 30 km/h the devices should allow for at least 2-3 successful pairing while in range. This is pretty hard on the battery.
As for what is collected I do not like random tokens. I think an easy way would be to broadcast a fob id and telephone number. Might be your phone number, might be your doctor’s office that has a list of 1000 fobs on file. When someone tests positive, the fob contains everything necessary to contact potentially affected persons. Dump through USB or wirelessly. One might also choose to broadcast his own email address (spammers may like that though), or even a fax number.
I asked around in my bubble of hacker friends if people would be interested to develop this further, as open hardware. But sadly no. Maybe I need new friends… /i
The stadium example of 1.4 million contacts appears unlikely.
Sellers would not typically come within infection range of everyone in a 100,000-person stadium – I’m not sure that’s even possible unless the game is cricket and the seller has really good stamina. We can easily halve that number.
First people showing symptoms would likely happen within a couple of days – this won’t be invisible for 14 days. Halve the number again in worst case.
Finally, if this was really the case, and occurring in a jurisdiction capable enough to deploy and use such tokens, a serious outbreak would be evident within a week, the stadium shut down, and everyone who was in the stadium urgently requested to isolate and/or test. At that point you don’t need the tokens to track a million contacts and I would guess that’s not the case they’re designed for.
[…] 23 June 2020: Added Bunnie’s post. […]
[…] Əlaqə iz və aparat токены — Sinqapur, bu yaxınlarda verdi, bir dəstə təhlükəsizlik insanların onlara daxil TraceTogether işarədir. Yazmaq-up уитл çox yaxşı, ona görə ki, o, dərini müzakirə ssenari izleme əlaqələr fonunda olan hər hansı bir qərar qiymətləndirilməlidir. Bax. həmçinin Roland Turner və Sean Crossməruzələrlə çıxış etmişdir. […]
Very interesting analysis indeed!
But I have a doubt about the Perfect Contact Tracing and Isolation Scenario, where it is told that:
“…digging through the graph of contacts also allows one to discover a shared contact of Person 4 and Person 2, thus revealing that Person 1 is the originating asymptomatic carrier.”
I think a detail is missing here to understand this sentence: the fact that after a certain time also person 2 has been tested positive.
Is it right?
THank you and best regards.
Alberto
The idea is that Person 1 would show up in Person 4’s contacts, at which point Person 1 would be tested and interviewed, whereupon Person 2 is discovered as well.
You’re right, the sentence as phrased is a bit confusing. The main point of the diagram is that Person 2 is a hidden node from Person 4, because Person 2 is not in the immediate contact set of Person 4; and that the chain goes cold once Exposure Notification hits an asymptomatic carrier or a carrier that is simply unwilling to go for testing and isolation.
To clarify:
– In the case of “Exposure Notification”, identities are masked. One can only be notified they have been exposed. Neither health authority nor individuals can discover anything about who has been close to whom. Furthermore, whether to go in for testing is up to the discretion of the notified person.
– The idea of contact tracing is to trade off the privacy of your recent contacts in exchange for being able to find asymptomatic carriers, and other individuals who may not currently be symptomatic, but will eventually develop symptoms and become infectious.
So in the “perfect contact tracing” scenario, you can rapidly interview and test all the first-degree close contacts of a person; and if any test positive, you would then proceed to interview and test all of their close contacts, until you reach “patient zero”. I call this scenario “perfect” because in practice, it takes time to trace contacts; the longer it takes, the more the virus can spread. There is a certain point at which the virus just spreads faster than you can trace, and there is no longer any point in contact tracing. Therefore the argument made by the pro-tracing advocates is that the potential social benefits of containing the virus are worth deploying privacy-invasive technologies to reduce the time required to do the tracing.
The pro-privacy crowd would argue that contact tracing is an extremely powerful technique that can too easily be abused by authorities to infringe upon the rights of citizens. There is also a fear that contact tracing normalizes a lack of privacy, so that even if today the technology is used for good, later on, civil liberty as a whole could pay a deep price later on. A hardware token makes strides in addressing both of those concerns, because of the unambiguous ability for individuals to “opt out” through the demise of the token itself; and because the token has a finite battery life, the ability for the government to continue tracing inevitably expires with the depletion of the battery.
[…] On Contact Tracing and Hardware Tokens — Singapore recently gave a bunch of security people access to their TraceTogether token. Bunnie’s write-up is very good because it contains a discussion of the scenarios of contact tracing, against which any solution must be evaluated. See also Roland Turner and Sean Cross‘s reports. […]
This token should be placed under a bug bounty program too.
Such devices are symptomatic of the emphasis on investing in the latest and most capable fire-fighting equipment, instead of in fire prevention methods.
What we need is an app that will make your phone ring and vibrate if you are within x meters of another person for more than m seconds. Pass a law to make it mandatory. It is easy to enforce, as an enforcement person walking up to you will immediately prove whether you have the app running or not. Zero privacy issues. Best of all – reduce infection chances and remove the need to trace.
[…] On Contact Tracing and Hardware Tokens — Singapore recently gave a bunch of security people access to their TraceTogether token. Bunnie’s write-up is very good because it contains a discussion of the scenarios of contact tracing, against which any solution must be evaluated. See also Roland Turner and Sean Cross‘s reports. […]
There’s a missing piece here. How are these tokens supposed to get the data back to the authorities in time to for it to be at all useful for preventing infections? (Or if the idea is for the tokens themselves to alert people, how is data on who has been recently infected supposed to get to the tokens?)
On another issue, I’ve been deeply unimpressed by the Apple/Google initiative, which this Singapore app and token somewhat resemble. Apple and Google are already sitting on mountains of tracking data which could be eminently useful for contact tracing, and which already is shared with law enforcement (with a warrant). They could be advertising this capability and mobilizing it for instant use for contact tracing of a high percentage of the population. Instead they’re taking much time to develop a new capability which will be opt-in and thus sparsely adopted. I think their fear is that if people learned how much their phones are already tracking them they’d rebel, and that’d ruin things for the really important use of the data: selling advertising.
I think the idea is that if you are tested positive and you come in for treatment at the medical facility you also recover the token at that time to extract the trace data. From that point the authorities can download the data and recover a list of recent close contacts. These close contacts would then be summoned for testing and further data recovery of their recent close contacts.
Basically, because there is always going to be a “touch point” which is testing and/or treatment, physical recovery of the token is a viable method for data retrieval. Also, notification of contact doesn’t come from an app — It’s my understanding that it comes via a phone call from the health authority. The process is similar to “classic” contact tracing that’s done through in-person interviews of the infected as they convalesce in the hospital, except you get to skip the interview process and just hand over a token.
@Norman I would assume that there is an earlier step during the distribution of the tokens that connects a token with a specific person, and a phone number.
For example, when a person gets a token, she will have to give her name, identification number, and contact number to the volunteers registering her.
The system keeps track of which token belongs to who – so when someone has covid and their token is found to contain a list of 10 other tokens they’ve come into contact with over the last 25 days, MOH can find out which tokens belong to who, and quickly call these people up to request for their tokens, and ask them to stay home.
[…] the excellent analysis on Bunnie’s blog, and also check out Sean ‘xobs’ Cross’ teardown of the TraceTogether […]
[…] [Sean] along with [Andrew “bunnie” Huang] and a few others were asked by GovTech Singapore to review their TraceTogether hardware token […]
[…] [Sean] along with [Andrew “bunnie” Huang] and a few others were asked by GovTech Singapore to review their TraceTogether hardware token […]
[…] [Sean] along with [Andrew “bunnie” Huang] and a few others were asked by GovTech Singapore to review their TraceTogether hardware token […]
it’s a side-point to the post, but i think a token like this really goes for everyone (rather than fancy-phone-less and ios-users) because of how android does permissions for bluetooth. since you get location data (coarse or fine-grain) w/ bluetooth permissions an app ggets more than a user might be aware.
the notification thing from google/apple stops that information leak, but has the drawbacks in the post ofr contact-tracing.
Would like to highlight that:
“While use of the app and token is currently voluntary, refusing to cooperate with the health authorities, like sharing data logs, is an offence under the Infectious Diseases Act.”
https://www.straitstimes.com/singapore/askst-how-new-token-and-app-will-address-privacy-concerns
It might not be as possible to crush the token and opt out of the system if it is against the law to do so, after you’ve been issued one.
Hi Bunnie, we are making a hardware Bluetooth encryption key with the Blue trace function, what do you think? Good idea?
I see you’re famous! I saw an electronics pic credited “Andrew Huang” on the BBC
https://www.bbc.co.uk/news/technology-53146360
:)
Am I the only one curious how did the team managed to get 9 months battery life? Beaconing(advertising) is one thing, but i supposed the device has to scan as well right. I wonder what is their scanning period and interval..
They had to modify the original Bluetrace protocol so it spends more time in Tx and much less time in Rx. I’m not sure what’s public yet, so I don’t think I can share the specifics but basically the strategy was to greatly increase the frequency of Tx events, so you can do low-duty cycle Rx scans, thus extending battery life…
sounds a lot like the changes we had to make for the KIWI tokens; also NRF based; also 1khz transmit and 1hz rx for battery life; we got 3 years of battery life that way…
What software/ tools did you use to draw the graphs?
Adobe Illustrator :P