Hardware components | ||||||
 |
| × | 1 | |||
Wikipedia defines it as:
"the process of identification of persons who may have come into contact with an infected person and subsequent collection of further information about these contacts."
Contact tracing is how epidemiologists and health authorities can track the spread of a disease through a population. Amidst the current pandemic, this is crucial to stopping the spread of COVID-19, because it connects people who have potentially been infected to preventive health services, like testing. However, traditional contact tracing is extremely hard to scale up, as it is reliant on personal data collection via interviewing. With a pandemic this large, it is crucial that a solution is found that can meet the massive demand for cheap, easily-scalable contact tracing.
The SolutionMost people have phones. So, what if instead of relying on people to identify people, we can use phones? This is exactly the idea behind the contact tracing standard being developed by Apple and Google, in a partnership. Their idea is to use a phone's BLE (Bluetooth Bow Energy) radio to transmit and scan for encrypted data. In the case of a positive diagnosis, a user can see if and when they've been in contact with someone with COVID-19, but not who, which allows for completely private and secure contact tracing.
In theory, it makes sense. But, in practice, there are some issues with this approach:
- Not everyone has a phone.
- Some phones do not have a BLE radio or compatible software.
- Phones have poor battery life (1-2 days at best)
With this in mind, I came up with a solution: Project Tracer. It is a small sized, low-power device which implements the aforementioned contact tracing standard.
As opposed to other methods of contact tracing, Project Tracer has multiple benefits.
- 🔐 Ensures User Privacy
Unlike other methods of contact tracing that use machine vision or GPS, no personally-identifying data will ever be recorded or stored by the device. All of the information used to notify others of potential exposures is randomly generated and encrypted.
- 🔋 Long Battery Life
Project Tracer provides an extremely low-maintenance method of contact tracing as opposed to phones. While a user's phone may run out of battery after less than a day, Project Tracer's projected power consumption can keep the device running for almost 5 days. The average power consumption is so low that the device can be charged by a single solar cell. This allows for the device to be used by people who do not have regular access to AC power.
- 👐 Simple Setup
Just tap a button, connect to the hotspot, and configure the device!
- 💲 Low Cost
While the BOM cost for a single device in individual quantities is high (about $13), bulk pricing can bring the price down to something as low as $5 per device.
- 🤝 Cross-Compatible
The framework is designed from the ground-up to be compatible with existing contact tracing standards for cell phones, maximizing potential user coverage.How Does it Work?
Before getting into the project, it's important to understand the fundamental principles which are the backbone of the project:
- Encryption is a one-way transformation that can only be reversed by the encryption key.
- Cryptographically secure random numbers are completely random and cannot be predicted in any way.
With these concepts in mind, Here's how the system works.
Every day, a random number called the TEK (Temporary Exposure Key) is generated. From the TEK, two additional keys are generated: the RPIK (Rolling Proximity Identifier Key) and AEMK (Associated Encrypted Metadata Key).
Every 10 minutes, the RPIK is used to encrypt the string "EN-RPI", along with the UNIX epoch time at encryption into what's called an RPI (Rolling Proximity Identifier). Additionally, the system will use the AEMK and the RPI to encrypt some additional metadata into what's called the AEM (Associated Encrypted Metadata). The AEM and RPI are then combined and transmitted by the integrated Bluetooth Low Energy Radio to nearby devices.
When the device would like to check whether or not it has been exposed to an individual with COVID-19, it simply starts by downloading the TEKs which have been submitted to a keyserver. For each TEK downloaded, it derives its respective RPIK and AEMK and attempts to decrypt the data that has been scanned from nearby devices. Due to the nature of Bluetooth (radio waves only travel so far), it is possible for the device to determine whether or not the user has been exposed to someone with COVID-19.
If you want a more in-depth read, and also how exactly to implement the standard, please take a look at some of the documents here. The part of the standard outlined above is the Cryptography Specification, v1.2.
Demo VideoHere's a simple demo video of the entire system working.
Example ImplementationThat's all fine and good, but how would this look like to an end user? To explain this, here is an example flow where a user gets exposed to COVID-19.
1. The user registers and obtains the device.
2. The user sets up the device via the device's integrated web interface. The device is now able to run on its own, independent of the user's devices.
3. The device operates in the background, monitoring for peers. Unknowingly, the user comes into contact with someone with COVID-19.
4. Every 24 hours, all Tracer devices (including the user's) will download the latest exposure keys.
5. After checking the downloaded exposure keys against its own, the device is able to tell that it has been exposed to a user who has tested positive for COVID-19. The device notifies the user, and the user checks the details on a WiFi-capable device.
6. The user decides to get tested and self-quarantine until the results come in.
7. Unfortunately, the report comes back positive. The testing center generates a valid CaseID via a centralized server and advises the user to upload their positive diagnosis.
8. Finally, the user uses their unique CaseID to upload their device's exposure keys to the cloud. Within 24 hours, all of the people who have been in contact with the user in the past 14 days will be notified of a potential exposure.
Building Your Own, Step 1: Flashing the Firmware to the ESP321. Install the ESP-IDF v4.0. You can follow the guide here. Please don't use the latest version, as it has some breaking changes to the code (namely the old TCP/IP adapter being deprecated)
2. Using git, clone the Tracer Repository to a local folder. Alternatively, you can download the repository directly from GitHub (via this link) and extract it to a local folder.
4. If you plan on hosting a test server on your local machine, get the local IP address of your computer and replace the following line in main.c with your local IP:
#define TRACER_KEYSERVER "your_ip_here" // this line here!3. Build and flash the project an ESP32 development board using the following command:
idf.py -p [your ESP32's serial port] flash4. After the flashing is complete, if no WiFi credentials are saved to the device, you should see the onboard LED flashing slowly. This means that the device is ready for configuration. Continue to the next part!
Building Your Own, Step 2: Device ConfigurationThis is the setup flow of any given Tracer device. Please note that I removed the names of the WiFi networks around me from the screenshots.
If you are using a cell phone for setup, be sure to turn off mobile data during setup.
If you tap GPIO33, the device will blink its onboard LED slowly. It will have now entered "configuration mode" and will host a WiFi hotspot for 5 minutes. For reference, here is where GPIO33 is on my development board:
To access the configuration menu, firstly connect to the WiFi network of the Tracer device. A valid network tracer name will start with "tracer-" and is followed by 5 random characters.
Confirm that you would like to stay connected to the network, if prompted to do so.
Next, open a web browser and enter the following link into the address bar:
10.0.0.1Alternatively, click here.
You should be greeted with a screen like this:
Press the "Scan for WiFi networks" button and wait for the WiFi networks to show up.
If yours doesn't show up, press the button labelled "Manual Connect". You will be prompted to enter an SSID. This is just the name of the network. It is case-sensitive, so enter it correctly!
Next, enter the password to the network.
Wait for the device to connect to the network. If it works, you should see something like this:
If you WiFi status is in a color other than green, you likely entered the credentials incorrectly. Please attempt to connect again. Otherwise, congratulations on setting up your Tracer device!
Building Your Own, Step 3: Hosting the KeyserverThankfully, it's extremely simple to host your own keyserver! All you need is a computer capable of running Python 3.8+.
1. Navigate to the folder containing your project. Its directory structure is like this:
.
├── data
│ └── {...}
├── esp_partitions.csv
├── hardware
│ └── {...}
├── LICENSE
├── main
│ └── {...}
├── media
├── readme.md
├── sdkconfig
├── sdkconfig.old
└── webserver
├── caseid.csv
├── randomtek.bin
├── server.py <= the server-side script
└── tekfile.csv2. Start a terminal session with the CWD (Current Working Directory) situated in the webserver directory.
3. Start the webserver with the following command (the sudo is only needed on Linux):
[sudo] python3 server.py(For some reference on the commands, visit this page)
4. The webserver should start! To stop it, simply type:
> exitToday I finished soldering up a prototype PCB for the Tracer Device, complete with a battery charger and ESP32 module. Because this was my first SMD board, it was extremely hard to solder. Unfortunately, my inability to solder surface-mount resulted in the board's TX and RX lines to be bridged, rendering it impossible to program. However, after realizing that the board's color matched with the battery's color, the temptation to take pictures of them was too much and I caved.
Comments