Summary

Singapore’s Minister for Foreign Affairs and Minister-in-Charge of the Smart Nation Initiative — Vivian Balakrishnan — invited several makers and open-source advocates to a session with GovTech on Friday, during which a teardown of the first version of the TraceTogether token was performed. The purpose of the session included allowing us an opportunity to examine and learn about the token, and to propose improvements.

The need to protect the integrity of an in-progress limited tender process for the second batch of tokens meant that there were tight limits on what could be disclosed to us, so this post is very much an initial view. Even allowing for that, the opportunities to learn some things about the token, to advocate improvements, and to publish some details of what we learned were worthwhile. A hackathon to permit developing open firmware for the tokens is proposed after the tender closes on June 30; if that goes ahead then full technical details will need to be made public in which case I’ll be able to expand on this post.

Some highlights:

I can state with reasonable confidence that the token contains only the components reasonably necessary to provide contact tracing assistance similar to that provided by the TraceTogether app. In particular, there is no GPS receiver or anything of that type.
The token will not need recharging! Instead it is expected to operate for ~9 months on its internal battery. This is really impressive; I had taken regular charging for granted.
There is reason to believe that appropriate information security measures are in place.
Unfortunately the convenience of not having to recharge comes with an extraordinarily tight power budget, which in turn makes several of the things on my wishlist rather challenging. In particular, publication of the complete firmware source code seems unlikely. However, a challenge has been laid before the open community: Can we come up with token firmware that will do the job, safely, even if its source code is public?

Background

(This section is quite long. Feel free to jump to The teardown session if you’re in a great hurry, but I have been finding it necessary to explain the background to people in detail in order for them to make sense of my view of the token. I encourage you to read the whole thing.)

Contact tracing

A pillar of communicable disease control is the tracing of a patient’s contacts, so that both:

those contacts themselves can be offered counselling, testing, protection from infection, and/or treatment; and
the public at large can be protected from those contacts if they’re likely to be infectious, by placing them into a quarantine facility, requiring them to remain at home, or just excluding them from particularly high transmission-risk situations (e.g. large crowds).

The contacts are usually identified by interviewing the patient about their movements during the period that they were likely to be infectious. This process is time-consuming, potentially stressful and — depending upon the nature of the disease and the patient’s state of mind — likely to miss many relevant contacts.

Bluetooth proximity detection as a contact tracing aid

Where there are records available to help jog the patient’s memory, their use is often helpful:

Interviewer: “OK, June 11. Did you leave your home at any time on that day?”

Patient: “I really can’t recall.”

Interviewer: “It looks as though you were near a large number of people between 20:10 and 22:45, does this ring any bells?”

Patient: “Oh, yes, I went to the cinema at {location} to see {film} with {list of friends}.”

A team within GovTech realised that Bluetooth proximity detection implemented as a smartphone app could provide a useful tool to support this process, while maintaining strong privacy protections, so worked with Ministry of Health contact tracers to develop TraceTogether. In the example above, not only would it provide a prompt to jog the patient’s memory, if epidemiological data indicated that sitting in a cinema containing an infectious person was a transmission risk then it would also provide the means to reach a large number of potentially exposed people whom the patient did not know. With or without TraceTogether, the contact tracer might also contact the cinema and seek contact information for other identifiable patrons who were seated nearby, or at list in the same room (those who paid by credit card, are part of a loyalty program, etc.), but those who paid cash for their tickets could not be identified this way.

There are two key points here:

TraceTogether helps the contact tracer job the patient’s memory in order to develop a more complete list of contacts.
TraceTogether helps the contact tracer make contact with potentially exposed people whom the patient does not know.

In the meantime Singapore has developed the process still further, including getting the process from days down to hours, which materially reduces how much transmission an asymptomatic carrier can give rise to, backward-looking tracing (using antibody testing as the biological test, rather than PCR) to track all of a cluster, and proactive testing of contacts of contacts to further cut the time that asymptomatic carriers are infecting people.

Centralised vs. decentralised

One rather simplistic way to use smartphones to help contact tracers is to record location histories detected by the phone, and continually upload them to a health authority database. This is so obviously a bad idea that TraceTogether doesn’t do it, but astonishingly, Norway’s health authority did, and didn’t shut it down until their privacy regulator told them to!

At the other extreme is a situation in which the series of random phone-generated temporary identifiers transmitted during a patient’s infectious period are uploaded and published after testing positive, and then checked by each user’s phone to see whether it received any of those and to alert its user to get tested if it did. This has the great benefit that a malicious actor in government simply can’t use the system to learn anything about a patient’s contacts, but it also means that the system can’t be used to support contact tracers in performing their work, meaning that many more cases go undetected so infection spreads further and faster. This is approximately how Apple/Google’s Exposure Notification (EN) works.

TraceTogether is something of a hybrid:

Detections are only uploaded after a person has tested positive in order to support the contact tracing interview. >99.9% of detections never leave the phone.
The ability for contact tracers to reach out to contacts does require some means of initiating contact. The approach chosen was to register phone numbers. Push notifications are known to be problematic (the Australian government’s COVIDSafe is derived from TraceTogether; their published Privacy Impact Assessment addresses this in detail). Consequently a centralised contact database is difficult to avoid.

This has led to some commentators referring to TraceTogether as a centralised system. I’d suggest that a more precise description is that it’s a mostly-decentralised hybrid which includes centralised report processing.

Technical problems

Neither Android nor iOS was designed with support for this sort of use in mind. By sheer happenstance, the app could be implemented efficiently on Android but not on iOS, because of the limits on Bluetooth access for apps running in a low power background mode on iOS. (I am not a mobile app developer, no doubt I don’t have the specifics quite right, but that’s the thrust of it.) The initial rollout of the app in Singapore therefore presented power and usability problems to iOS users, but still materially supported the contact tracing process.

Apple was approached and — skipping a few steps — jointly developed with Google an Exposure Notification capability that can be used solely by qualifying health authorities to develop efficient apps to help potentially exposed people discover the need to get tested. As I understand it, at the outset Apple was aiming to standardise contact tracing support, but somewhere along the way the approach shifted to one which simply enabled encouraging potentially exposed people to get tested without requiring that any information about people’s contacts ever be exposed to government. If advising a potentially exposed person that they should get tested was the only important outcome of contact tracing then this might have been enough but, as above, this simply isn’t true.

Given Apple’s ongoing difficulties with governments demanding that it betray its customers by weakening its products (e.g. to make a compromised iOS to allow evidence to be extracted from phones without the owner’s involvement), and the overlap of this idea with the usual technolibertarian fantasy of replacing all government with cryptographically-enabled technical systems, it is perhaps not a surprise that the idea took hold, but I suspect that the ultimate price for this will be a substantial loss of human life.

71% coverage

One of the problems with using Bluetooth proximity detection as a tool for inferring potential exposure is that its usefulness depends upon its level of adoption. A detection can only occur if both carrier and infected contact are both running the app, meaning that detection rate varies quadratically, i.e. with the square of coverage:

If there are just two users then the fraction of infections detected will be essentially zero.
If the entire population has adopted, then almost all infections will have corresponding Bluetooth detections.
However, if, say, 50% of the population has adopted, and assuming that adoption is uncorrelated with infection, then only 25% of infections will have a corresponding detection (i.e. 50% of 50%).

This means that 71% coverage represents an interesting milestone (assuming uncorrelated adoption), as it’s the point at which more exposures will be detected than will not be detected, because 71% of 71% is about 50%, or √0.5 ~= 0.71. Consequently, adoption rates of about this figure (70%, 75%, 80%) are frequently adopted as nominal objectives. Sadly, when this gets said out loud to the public at large, it is frequently heard as “If we get to x% adoption then it will be useful, but less than that will not!”, which is clearly incorrect. Instead it’s just a curve which keeps getting better, faster as more and more people adopt.

Note also that the Pareto principle applies to almost all human endeavours: ~80% of the outcome tends to come from ~20% of the effort. This is only a rule of thumb, but often helps to think rationally about how to scope a project. As 71% is not far below 80%, this perhaps strengthens the tendency towards adopting numbers in this range as nominal objectives.

There are two other problems with treating this number as anything more than a nominal objective:

It is unlikely that adoption is uncorrelated with infection risk. Different people have different risk profiles and are also aware of this fact, however imperfectly, meaning that those who have smartphones and are at greater risk (whether through greater exposure to carriers, or because of existing health issues) are more likely to adopt than those at lower risk. This in turn means that the 50% detection mark may well be reached at a somewhat lower adoption level than 71%, although I lack any empirical basis for estimating it.
The detection rate isn’t the sole benefit of TraceTogether, and at lower adoption rates isn’t even the primary benefit. The ability to jog the patient’s memory during contact tracing is an important benefit and — for patients who have adopted — this benefit rises linearly with adoption: 25% adoption will tend to mean that 25% of the patient’s contacts are detected.

Inclusivity

Another very important problem with the app is that not everyone has a smartphone, or is at least not realistically able to carry and use one. This applies in particular to small children and to the elderly. I have attempted to teach a man in his 80s how to use a smartphone (my late father). It did not go well.

This gives rise to a failure of inclusivity. If you imagine, as many people appear to, that the sole purpose of TraceTogether is to get enough at-risk people tested to contain transmission then this might not seem like a big deal, particularly if you assume that some magic x% app adoption number means “job done!”, however if you recall that the benefits of contact tracing include the opportunity to provide infection protection and/or treatment to an at-risk contact, then exclusion from this process is clearly a problem. For non-smartphone users whose Covid-19 risk is enormously raised merely by virtue of their being elderly, this exclusion — and the resulting delay in treatment — has the potential to be a matter of life and death.

The TraceTogether token and the outcry

Singapore has elected to address both the iOS problem and the inclusivity problem with the production and distribution of a token that can perform Bluetooth proximity detection to support contact tracing, and will be able to interoperate with the TraceTogether app.

On the face of it this is a fairly straightforward, uncontentious decision which addresses a real concern for a great many people. Unfortunately, the announcement of this decision gave rise to an unusually strong outcry, with tens of thousands of people signing petitions opposing it. This is not unprecedented, but it is rare. It is that outcry which gave rise to Rice Media approaching me for an interview ten days ago.

I suspect that there are multiple factors driving the outcry, but one of the most frequently cited is the concern that this is some kind of location tracking device, rather than merely the same sort of privacy-preserving contact-tracing aid as the app. I suspect that the simultaneous announcement of the requirement for the user to provide their national ID number upon registration, and mooting the possibly of mandatory use if conditions warranted it, might have compounded the problem.

The teardown session

Arrival

The session was held at a large GovTech meeting room at MapleTree (for those who know it: the room with a cafe/bar on level 10), naturally with tables very well spaced out. The invited makers and open-source advocates were Bunnie, Xobs, Harish, and myself. In addition to Minister Balakrishnan, there were perhaps 10-15 others around the room, several who presented or participated in discussion were introduced, the rest just observed.

Limits to transparency

Right from the beginning of the session it was clear that rather less was going to be disclosed than any of us had anticipated. I don’t have the sense that there was anything disingenuous going on, just that the motivations for secrecy are strong. The approach therefore was to disclose what could be disclosed, to answer questions and discuss approaches, and to ask us to exercise some discretion. No formal NDAs were signed. No request was made to have GovTech vet our public disclosures (but see below about photos).

I observed three major limiting factors:

There is a limited tender in progress for the second batch of tokens. The first batch — from which the tokens that we would take apart were drawn — was made by PCI, which is also one of the companies qualified to bid in the limited tender. It is reasonable to assume that PCI’s proposed design for the second batch will share much with their design for the first batch, and as those aren’t already in the hands of the public that design is therefore commercially sensitive information, the disclosure of which would unfairly affect the tendering process. Consequently, most of the chips had their part numbers masked and we were each asked to assert (verbally) that we weren’t affiliated with any of the qualified bidders. There remains the possibility of aspects of chip shape/size/position and board layout giving away sensitive information, so we were asked to avoid publishing photos which were likely to have that effect and GovTech offered to vet photos for this purpose if we wished. I would prefer to avoid that entirely, so am not publishing close up photos at this point. I’d suggest that they’re not that exciting anyway because of the masking and that the photos of each of us handling the boards will give a good sense of their size anyway. Similarly, we were advised that extracting the firmware was not OK.
The security arrangements for the tokens (not merely the backend) are sensitive to disclosure. This is disappointing, but not overly surprising given the power limits that arise from the use of a non-rechargeable power source. We were also asked not to photograph the slides which were mostly Bluetooth protocol information from the limited call for tender. I infer that this was for the same reason.
The entrenched cultural norms for an organisation that — like most — doesn’t have much experience with making its technology open. I did not perceive a lack of co-operation because of this, just a lack of familiarity and comfort with being open about the innards of something that has a sensitive function.

Power source

The detail that stunned me was the power source. It’s a large coin cell and is expected to run the token for 9 months! I neglected to make note of its part number, but it’s something like a CR2477. I had not considered something like this possible, so had taken for granted a rechargeable battery. Not requiring recharging not only means no charger, but also that many users will be able to attach it to a key ring or a child’s back pack etc. and then just forget about it. This level of ease of use is fantastic.

Note that at 3V and 1Ah, the cell’s energy capacity is just 10.8kJ. For 9 months’ operation, that’s an average power draw of ~460uW. At this level power use must be not merely efficient, but downright miserly.

Protocol

An immediate consequence is that every possible measure has to be taken to reduce power drain, most importantly by the Bluetooth receiver. The power used by the transmitter can be minimised by keeping the messages short, but the receiver has to be on for at least a single digit percentage of the token’s entire service life and will therefore dominate power consumption. Much less than this, and the risk that a relevant encounter won’t be detected at all becomes significant.

A result of this is that a new protocol “BlueTrace Light” has been developed. It is connectionless, does not include the device model information or inter-jurisdictional support that BlueTrace provides, just tiny encrypted messages, presumably little more than the temporary IDs. Detailed protocol information was not provided. In particular, the method of generating temporary IDs for each 15 minutes was not discussed. It’s conceivable that they’re generated externally and loaded at manufacture: 9 months operation would require about 26,000 IDs.

Given the sensitivity about the details, quite how interoperation with the app is going to work is not clear. It is conceivable that BlueTrace Light will be included in TraceTogether, but not in the published OpenTrace source in order to keep the details from public view.

Components

There isn’t all that much to tell. There’s a SoC, 64 Mb (i.e. 8MB) of flash, a Bluetooth radio, an RTC and additional coin cell to keep the RTC operating while the main cell is replaced, a power regulator, some option resistors, a couple of LEDs, (presumably) JTAG pads, … Take away just about anything and the token wouldn’t be able to do its job.

Certainly there weren’t any obviously inappropriate things like e.g. a GPS receiver. Indeed, the power budget means that using GPS would be impossible anyway.

I would very much like to have known the part numbers of the SoC and Bluetooth radio as any open firmware plans hinge critically on those, but until the limited tender closes we’re not to know.

Security

The perfect as the enemy of the good

I had a discussion with one of the GovTech representatives a few days prior to the session, during which I learned that disclosures about security arrangements would be very limited. I expressed concern, particularly the cryptography 101 argument about only the key being secret and that the rest of the mechanism should be robust even if disclosed, thereby enabling it to benefit from improvements gained through widespread scrutiny. He acknowledged the importance of this, but pointed out that the benefit to be obtained by spending a few more weeks exploring marginal security improvements to, maybe, get to a mechanism which could be disclosed would likely be worth far less than the cost of that delay. Given that Covid-19-related government expenditure and economic contraction are in the hundreds of millions of dollars per day at present, I can see his point. Important consequences include the likelihood of the loss of a couple of my wishlist items, including that the complete firmware source code probably can’t be published and that individual users can’t extract the firmware from their token to independently examine it.

This is one of the more uncomfortable facts arising from the session. Putting my CISO hat on: it is something that risk managers — whether in information security, insurance, industrial plant safety, or almost any other field — deal with on a daily basis, but is often not visible to the public at large. Yes, we’d like to take our time and get everything right, but in a rapidly evolving situation time may be an unaffordable luxury. This is not an excuse for abandoning discipline and accepting unbounded risk, on the contrary it argues for more diligently managing the risk within the constraints of the situation, just that it’s necessary to accept some residual discomfort.

This is sometimes expressed as not allowing the perfect to be the enemy of the good: accept the good and move forward rather than holding out indefinitely for the perfect.

Consequences of low-power operation

A fundamental problem is that the power budget is so tight that asymmetric cryptographic operations will likely be impossible. If that assumption is correct, then the use of a system-wide shared AES key might be unavoidable, which in turn means that a sensitive secret is literally in any adversary’s hands. Even if not, it’s difficult to imagine how various DoS scenarios might be resisted without using asymmetric cryptography to issue and validate certificates, etc. Both of these point to a need for some amount of security by obscurity. This is something that is generally worth avoiding if at all possible, but it’s also true that situations do arise where this is either the only option, or is the only option for many of the relevant controls. The infosec guy was not able to speak about any of the detail, but did point out that there was no one protective mechanism, instead there were multiple layers providing cumulative protection:

The technolibertarian in me winces at this. Devices in the hands of individuals really feel like something that should rely on robust cryptography and therefore not require any secrecy at all, apart from about the per-device key(s). Unlike servers in physically secure datacentres, the tokens will be readily accessible to adversaries. Breaching the first token would be time-consuming and difficult, but once achieved, the disclosure-sensitive protections would be apparent and as many other tokens as they chose to attack would therefore be exposed.
With my CISO hat on, I am of course aware that such approaches are widespread and difficult to avoid, particularly with a power budget in the sub-mW range, not to mention the economy-crushing time pressure, so the question becomes a consideration of risks and benefits.

DoS/DDoS

The risk from adversaries that seemed to be of most concern was DoS, so much so that one of the GovTech representatives said to me words to the effect that if I could come up with a means to protect the tokens against DoS which would remain robust if it were publicly disclosed, then he’d use it. The implication appeared to me to be that their rather large infosec team had already concluded that this is not possible.

In the DoS case, an adversary would deploy a malicious transmitter which would prevent some tokens functioning correctly (cause them to perform operations which flatten the battery prematurely, fill the flash with fake detections, …) thereby reducing the assistance provided to the contact tracers’ work. This is unlikely to lead to a material increase in disease transmission because the number of affected people will be small.
In the DDoS case, an adversary would require a very large number of malicious transmitters within Singapore to do the same — as transmitter and token must be within ~50m of each other — thereby flooding the contact tracers with fake detections that can’t be algorithmically removed at upload time and therefore waste large amounts of their time or of the country’s testing capacity. This would be essentially impossible to do undetected, so action could be taken because of the need for the transmitters to be within Singapore. A compromise of an app popular on non-Apple/Google smartphones might be an easier option than thousands of purpose-built transmitters, and it might be difficult to address quickly because the government might not have an existing relationship with the app store provider through which to bring about a prompt removal of the app in question. The list of adversaries who could perform this latter attack can probably be counted on one hand, and it’s not clear why any of them would do it.

Nonetheless, in either case it’s desirable that the system be able to continue to function largely correctly in the face of such an attack and/or to recover correct operation promptly. As the mechanisms that I’m accustomed to using to fend off DDoS on the Internet require substantial processing and storage resources, I can readily see the difficulty in doing this well on the token, and therefore the reliance on secrecy.

Tracking individuals

While the difficult problem for GovTech appears to be adversaries preventing the system from working at all, the great concern for the rest of us is the potential for the misuse of the tokens to track our daily movements, other than for contact tracing if we test positive.

I’d suggest that this is much simpler to resolve than the DoS concerns:

There would appear to be plenty of storage in the token to load at manufacture enough temporary IDs for the likely service life. These can therefore be generated securely (in particular with a reliable random number generator for AES IVs) free of the limits of the power budget, so there would be no computable relationship between a user’s temporary IDs.
Detected contacts are only retained on the token for 25 days before being erased. Even the recently detected contacts would only ever enter MoH hands in the event of a positive diagnosis, and even then only when the patient hands the token over. This means that only a minute faction of detected contacts are ever in government hands, meaning that the tracking potential is negligible.
There’s a minor concern around the means of getting data out when someone tests positive. Perhaps this requires connecting a cable, which is something that an adversary would struggle to do discretely if seeking to track an individual. It may also have been implemented via Bluetooth (because then it’s just an app, which simplifies provisioning, training, etc.), in which case conventional security measures which aren’t disclosure sensitive will apply.
Finally, a potential tracking abuse is for the token to record broadcasts from existing installed BLE beacons, primarily in retail locations, thereby providing a partial track of a patient’s movements if the patient happened to have gone near any that can be identified merely by recording them. I suspect that DoS concerns mean that this is a non-starter, as recording these would open up a means for an adversary to flood the tokens with rubbish.

Token security vs. app security

Many of the same concerns arise for the app, but there’s an important difference: security is not just about preventing breaches, it’s also about recovering from them, promptly. If an unacceptable breach is detected, a recovery option for the app is to roll out a fix immediately. The same isn’t true for the token, meaning that a lot more up front protection is required.

Is use of the token OK?

Yes.

It fills really important gaps in the ability of the MoH to keep the virus contained and therefore to facilitate a return to sustainable economic activity while the epidemic continues, if not quite to pre-epidemic levels. In particular, it allows for stronger protection to be extended to many of those who are most vulnerable to Covid-19, but for whom smartphones are a non-starter.

It’s unlikely to be a useful tracking device, even if a large number of malicious actors in government conspire.

The security disclosures are nowhere near as thorough as I would wish, and I remain hopeful that there will be some progress on this, but this does not seem to me to be a showstopper.

Next steps

Hackathon

It’s not quite clear what form this will take, particularly because the starting point looks like being a token with no firmware, but the only obvious impediment to this going ahead is the need for secrecy around the limited tender, which suggests that a July date may be possible.

Importantly, preparation for this will require public disclosure of the component part numbers, which will allow filling of some of the gaps above.

Data protection impact assessment.

A really important tool for fostering trust is the publication of detailed impact assessments. Performing such assessments will become mandatory for private sector processing on the legitimate interests basis if the proposed changes to the PDPA are adopted by Parliament. Voluntarily performing an assessment on the TraceTogether app and token and then publishing it would seem to be a particularly good opportunity for government to model the new behaviour expected of private sector organisations.

I mentioned the COVIDSafe Privacy Impact Assessment above; this is the analogous document in Australian conditions. That level of transparency on TraceTogether would have helped me give a number of people clearer, fact-based reassuring answers to questions that were concerning them, rather than my educated guesswork. My guesswork is pretty good, but factual disclosures are better.

It appears that such an assessment was performed for the app. I proposed to a number of people present at the session that updating this for the token, redacting any sensitive disclosures, and publishing it might be a worthwhile transparency measure. The reception was positive, with some luck it will actually happen.

Open firmware

On the face of it, the challenge to devise a protection mechanism that will work on this power budget even if it’s publicly disclosed seems like a fool’s errand, let alone that I can’t see GovTech disclosing their threat modelling and risk acceptance criteria against which to evaluate proposed mechanisms. The power budget alone makes this analogous to sending soldiers onto a battle field armed with nothing but fists and swearing, blindfolded, and narcoleptic. Nonetheless, it is a tantalising question…

Some quick poking around turned up related work for automotive settings (e.g.). This suggests that it’s not entirely impossible, but “experimental cryptography” vs. “security by obscurity” is unlikely to be a productive debate.

I will think about this.

Updates

2020-06-22

GovTech asked me to pull the image as the formal launch is imminent. I imagine that they’d prefer to chose which images are circulated during the launch.

2020-06-23

Added a link to Bunnie’s post.
Made a correction: In the “Tracking individuals” section, after the words “between a user’s temporary IDs.”, removed the words Each can then be used for 15 minutes before being overwritten, meaning that MoH can't look backwards at the patient's pre-infection temporary IDs and correlate them with any data retained about other patients. That is of course part of the Apple/Google Exposure Notification mechanism. Added the “Detected contacts are only retained…” bullet point.

2020-10-04

Put the image back. As the tokens are now generally available, there is no confusion risk in displaying images of the prototypes.

Roland Turner

TraceTogether Token Teardown Time!