Trace Together Token: Teardown and Design Overview

On 19 June, GovTech Singapore invited four members of the community to come and inspect their new TraceTogether Token. This token removes the need to carry a phone at all times, and is designed to help both those who do not have a smart device capable of running TraceTogether well, including those using older Android devices, non-smartphones, and iOS users. I was among the group, which also consisted of Roland Turner, Harish Pillay, and Andrew “bunnie” Huang, who were given the opportunity to see the first public revision of hardware. In this post I will discuss the goal of the token, give some overview of the hardware, compare it with the app version of TraceTogether, and comment on the protocol changes.

Goal of the TraceTogether Token

The Trace Together Token is a dedicated hardware device that makes it easier to inform people if they may have come in prolonged contact with a person who subsequently was diagnosed with COVID-19. This is its sole purpose.

It is a hardware implementation of the app that GovTech previously developed, and has been installed over half a million times. The TraceTogether Token builds on the app and simplifies its usage: Throw it in a handbag or attach it to a keychain and forget about it while it does its thing.

Comparison With Phone Apps

I won’t do an in-depth analysis of the Trace Together app. You can read an independent analysis that Frank Liauw put together to learn more. I worry more about the amount of spying that other popular apps on my phone do. For example, every banking, taxi booking app, and food delivery service on my phone has uploaded some amount of data to Facebook, Google, and a company called AppFlyer.

TraceTogether uses a protocol known as BlueTrace, and there are several problems with the protocol that make it challenging to work with.

First, antenna designs vary. As part of the Bluetooth spec, devices can report the amount of power they are currently using to broadcast:

BlueTrace includes this information in the advertising beacon, but what does the number mean? Intuitively it will tell you how far away a device is, because you can correlate the strength of the received signal with the broadcast power: If they said they were loudly broadcasting but you received a weak signal, they must be far away. However, antenna designs vary, and just like with humans, one phone’s “loud” is another phone’s “whisper”.

There’s also the issue of charging. Phones must be charged at least daily. With mobile payment becoming more common, people are incentivized to keep their devices charged and running, however it’s still very common to be hobbled by a phone simply running out of battery.

On Android, many device manufacturers are very aggressive when it comes to terminating background processes. TraceTogether necessarily must always run in the background, but your phone might not realize that and could terminate the process anyway. Anyone who has found themselves unable to receive WhatsApp messages without opening up the app will have experienced something similar. Additionally, many older Android devices are not compatible with the approach of TraceTogether, where a device can act as a Bluetooth Central (i.e. “host”) or a Peripheral (i.e. “device”).

As an aside, it was refreshing to hear Minister Vivian Balakrishnan using the words “Peripheral” and “Central” when discussing issues pertaining to older devices. These are the technical terms for the roles Bluetooth devices play, and he correctly pointed out that devices that do not support Bluetooth Low Energy (BLE) are incompatible with Bluetooth-based contact tracing.

Then there’s the iOS problem. Apple does not let apps use Bluetooth in the background, so users must always run TraceTogether. The easy answer here is to use the Apple-sanctioned tracing protocol, however this protocol is not compatible with BlueTrace and makes very different assumptions about how contact tracing should work. It also assumes that everyone has a modern device, which leaves out a significant portion of the population that does not have the latest hardware.

Hardware Overview

The hardware isn’t ready yet, and we aren’t yet allowed to share photos of the device because supplier contracts are still being worked out. Still, we could identify the major components well enough that I put together this block diagram:

There are several interesting parts to note about this diagram:

• There is no battery charger – it’s designed to run for several months on a single battery.
• There is a realtime clock with its own battery meaning time must be important in the new protocol
• They use a powered antenna to improve performance
• The entire system must be extremely low power

The last point means it is unlikely that they hid a GPS tracker, WiFi radio, or cellular modem in this device. The battery is a small coin cell, which would only last a few hours if it were receiving GPS or communicating via WiFi. Additionally, there are no additional sensors such as an accelerometer, pressure sensor, or microphone.

All of the major ICs had obfuscated markings so we couldn’t identify part numbers. However, the block diagram I sketched above happens to look very similar to the block diagram for Simmel, which is an open-source tracking token put together by Bunnie and myself:

There are a few notable differences:

• Simmel uses a PCB antenna because it was a proof-of-concept device, so we were willing to accept reduced range.
• There was an experiment in using Near Ultrasound as an alternative to Bluetooth for contact tracing, under the theory that it would be lower power. Ultrasound turns out to be too directional, which is why bats can use it for echolocation.
• TraceTogether uses a separate realtime clock, whereas Simmel currently relies on a stupendous hack to save time in case of a crash, meaning it is less accurate.
• Simmel runs CircutPython in an effort to make early development easier, with the intention of rewriting it in a lower level language later on. The TraceTogether Token presumably runs its own stack.

Despite these minor differences, there are many similarities:

• Both run on a non-rechargeable battery
• Both use a voltage regulator to stabilize the battery voltage
• Both have an external flash memory for storing contacts
• Both are designed to last for months without user interaction, and be forgotten about until they are needed
• Both rely on Bluetooth – specifically Bluetooth LE – for interaction
• Neither contains any additional sensors, since those would add cost and power consumption

Therefore, while the exact hardware details of the Trace Together Token are still obfuscated, I can safely say that it is conceptually extremely similar to Simmel. Any questions you have about the hardware approach GovTech is taking can be answered by looking at the Simmel hardware repository.

BlueTrace Protocol Changes

One of the challenges we ran into when developing Simmel was the power budget. The nRF52833 part we used requires a lot of power to listen to Bluetooth:

BlueTrace advises that a device listen 20% of the time, which means it’s receiving 20% of the time. In testing, we were observing about 5.9 mA current draw when receiving data, compared to 0.012 mA when idle. Furthermore, BlueTrace recommends that a device must transmit about 90% of the time, which is unfortunate because transmission has similar numbers:

For a mobile phone these numbers are tiny, but when running off of a pair of AAA batteries, a continuous drain of 2 mA means a 1200 mAh AAA battery will be drained in 1200 mAh / 24 hours / 2 mA = 25 days.

Part of the problem involves the BlueTrace approach, which follows a traditional Peripheral/Central approach: A Central advertises a GATT Service of “BlueTrace”, allowing another device to connect and read the current temporary token / deposit its own temporary token. This is required in order to make a two-way connection in BLE, so it is an extremely common approach. Additionally, ensuring the connection is two-way also ensures that the devices are close enough to matter from an epidemiological perspective.

GovTech must have also run into these issues, because the BlueTrace protocol is being modified for use with the Trace Together Token. Instead of forming a two-way connection, devices now simply broadcast their temporary tokens. The interval for broadcast is much longer, and the scanning interval is much shorter, meaning the device can spend most of its time in a low-power suspend state.

Storage

Simmel has 2 MB of flash memory. Each BlueTrace Temporary Token payload is 160 bytes. That means Simmel can store (2^21) bytes of flash / 160 bytes per payload / 21 days = 624 records per day. We weren’t sure how many daily records we could expect, and the number surely was very low during the Circuit Breaker. GovTech must have decided that this was too large to store on an embedded device, so for the Trace Together Token they reduced the size of the critical part of the payload. In the new protocol, this payload is much smaller, although we don’t yet have exact numbers.

Finally, there’s the issue of temporary tokens. In the current Trace Together app, a batch of tokens is downloaded from the Ministry of Health every few days. With Simmel, we assumed we could simply download a few months’ worth of tokens and store them on the flash memory, consuming them as time passed. GovTech took a different approach with the Trace Together Token, and instead derive the temporary token from a unique ID hashed together with the current time. This approach is similar to how the European DP3T protocol works.

As a result of all of these changes, many of the challenges we faced when designing Simmel are avoided with the Trace Together Token: They can reduce power by spending less time transmitting and receiving; they don’t have to use so much storage to keep track of interactions; and they don’t need to store several months’ worth of temporary tokens. Overall these changes are exactly what are needed for an implementation of the protocol for use in a hardware token.

Conclusions

The approach taken by GovTech when designing the Trace Together Token hardware is sound. The device accomplishes the goals it set out to, while preserving the privacy of the owner. Like the Trace Together app, the Trace Together Token cannot be used to identify the owner merely by looking at Bluetooth broadcasts – the only entity that can correlate logged data to a human is the Ministry of Health.

During this session we didn’t have access to the software, because as a tracing beacon there’s not much of a user interface beyond a blinking LED. Also, they weren’t ready to let us attach debug probes, meaning we can’t draw any conclusions about the software itself. However, given the PCB design and the system’s power requirements there isn’t much they could hide.

Overall I’m pleased with the direction they are going in with the Trace Together Token, and look forward to getting one of my very own.