Cryptography specifications for Apple/Google's Bluetooth contact tracing system: https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ContactTracing-CryptographySpecification.pdf

The key schedule is very simple: users have a root Tracing Key, deriving Daily Tracing Keys, which are used to generate Rolling Proximity Identifiers (aka TCNs). Users report infection by revealing their daily tracing keys to a server (run by whom?) who sends them to other users

Revealing a daily tracing key reveals all of the RPIs derived from that daily tracing key, meaning that a passive adversary can correlate past RPI broadcasts from a user who reports infection. This is a tradeoff between reporter privacy and bandwidth, also made by TCN and DP-3T.

But in the Apple/Google protocol, the tradeoff isn't an adjustable knob, it's hardcoded into the protocol, so there's only one choice. And this choice might not be the optimal one.

For instance, if an entire day's RPIs are revealed in one block, they may end up being linkable *across* days, because people have regular patterns of life, and a passive adversary can e.g., notice that two reports appeared at the same place each day.

Figuring out the optimal tradeoff here is challenging, but if it's hardcoded into the protocol, it's not possible to change it at all.

(deleted tweets about the interaction with the Bluetooth layer that may not have been correct)

In any contact tracing protocol, it's critical that the rotation of the ephemeral broadcast data is synchronized with the rotation of the Bluetooth MAC address. Otherwise, someone can see that the same MAC broadcast two RPIs, or that the same RPI was broadcast from two MACs.

To achieve this, the protocol derives an RPI every time the Bluetooth MAC changes, as follows:

However, it's not totally clear to me that this actually ensures unlinkability of RPIs and MAC addresses, because the RPIs are dependent only on the time interval (also hardcoded into the protocol), rather than having a "next RPI" ratchet (as in the TCN design).

Why is this important? Because passive adversaries are real: https://twitter.com/errorinn/status/1248670530149875712

This randomization can only help for users who do not report. Users who do report reveal their daily location history to the random ad company with the garbage can surveillance network, who can correlate with ad targeting data and resell lists of COVID19-positive people.

The other big problem with the protocol is that because there's no information attached to reports, just an implicit "tested positive" bit, the protocol assumes the existence of a single, centralized entity who can determine whether a COVID19 test happened.

But this isn't the way that testing actually works! It's a huge patchwork of different agencies doing different tests, and it's already even a challenge just to collect statistics, let alone authenticate tests.

Most of these problems are fixable, though, and it's exciting to see different teams converging on similar contact tracing designs: https://twitter.com/TCNCoalition/status/1248619337683857408?s=20