Security considerations

This document highlight security considerations in the current implementation.

A device is allowed to serve one ID while writing another

It's unclear what sort of issues this can cause.

We trust the rssi sent by another device.

We use that rssi when considering proximity. This allows devices quite far away to fake proximity.

Possible solution: Sending device sends it's MAC address. The receiving device then turns on it's Bluetooth scanner to search for the MAC address, and records the scanned RSSI value.

Seeds and contacts local storage

They currently don't use any on disk encryption so it's trivial to extract those files is the phone is unlocked and plugged to a computer.

SQLCipher is an option for easily encrypting data to disk using a user-generated password. But from a UX perspective this introduces a new challenge. Specifically, users now have to remember a password. And may forget the password when submitting their infected seed.

Homomorphic encryption using Microsoft SEAL might be an option.

Seeds computation

We currently run seed computation without any mitigation from Meltdown/Spectre or any other cpu side channels. Should we use a secure enclave or other mitigation techniques?

We rely on the OS for safe communication with backend including certificate validation and trust

This leaves us open to MitM attacks from employers (though injection of corp certificates), phone vendors and nation states able to produce valid certificates.

ID sequencing

The current ID generation schema makes it quite easy for a hostile device to learn a sequence of seeds through Bluetooth UUID and other device metadata in the announcement.

Seed rotation

Should we rotate the seed regularly independently of whether the user self-report? This would reduce the maximum window the device can be historically tracked back.

Many devices attack

Given an attacker with significant number of devices in a given area, how practical is to deanonymize the location history of a self reporting user?