Generation

To generate a TCN, first a report authorization key (RAK) and report verification key (RVK) are created as the signing and verification keys of a signature scheme (RAK-RVK pair). In the reference implementation this pair is created using the Ed25519 signature scheme.^{[40]: line. 13} Then, using the RAK an initial temporary contact key (TCK) is generated using the algorithm ${\displaystyle tck_{0}=H\_tck(rak)}$, where ${\displaystyle H\_tck()}$ is the SHA-256 hash function as ${\displaystyle H\_tck(s)=SHA256({\text{b'H}}\_{\text{TCK'}}||s)}$. This TCK is not used to generate any TCNs, but is used in the next TCK; where all future TCKs are calculated using the algorithm ${\displaystyle tck_{i}=H\_tck(rvk||tck_{i-1})}$. A 128 bit TCN is then generated from a given TCK using the algorithm ${\displaystyle tcn_{i>0}=H\_tcn(le\_u16(i)||tck_{i})}$, where ${\displaystyle le\_u16()}$ formats a supplied number as a little endian unsigned 2 byte integer,^[41] and ${\displaystyle H\_tcn()}$ is the SHA-256 hash function as ${\displaystyle H\_tcn(s)=SHA256({\text{b'H}}\_{\text{TCN'}}||s)[0:128]}$. The following diagram demonstrates the key derivation process:

TCNs are unique to each device encounter, and RAK-RVK pairs are cycled at regular intervals to allow a client to report only specific periods of contact.

Reporting

When a client wishes to submit a report for the TCN indices ${\displaystyle s>0}$ to ${\displaystyle e}$, it structures the report as ${\displaystyle report=rvk||tck_{s-1}||le\_u16(s)||le\_u16(e)||memo}$. A signature is then calculated using the RAK, and it is transmitted to the server as ${\displaystyle s\_report=report||sig}$.

Because any given TCK can only be used to derive an equal or higher indexed TCNs, by submitting ${\displaystyle tck_{s-1}}$ no encounters prior to ${\displaystyle tcn_{s-1}}$ can be calculated. However, there is no upper limit to encounters calculated using the same RAK-RVK pair, which is why they are cycled often. To prevent clients calculating unused TCNs, ${\displaystyle e}$ indicates the last TCN index generated with the given RVK.^{[42]: lines. 49–61} Additionally, since the RVK is used to calculate a TCK, and ${\displaystyle tck_{s-1}}$ is provided, no valid TCNs in the reporting period can be derived from an illegitimate report. The only correct TCN calculable from a mismatched RVK and ${\displaystyle tck_{s-1}}$ is ${\displaystyle tcn_{s-1}}$, the TCN before the start of the reporting period.

Once a report is received, clients individually recalculate TCKs and TCNs for a given period using the original algorithms:

$${\displaystyle {\begin{array}{lcr}tck_{s}=H\_tck(rvk||tck_{s-1})\\tcn_{s}=H\_tcn(le\_u16(s)||tck_{s})\\tck_{s+1}=H\_tck(rvk||tck_{s})\\tcn_{s+1}=H\_tcn(le\_u16(s+1)||tck_{s+1})\\...\\tck_{e}=H\_tck(rvk||tck_{e-1})\\tcn_{e}=H\_tcn(le\_u16(e)||tck_{e})\end{array}}}$$

This is used by client devices to check their local contact logs for potential encounters with the infected patient, but has the dual benefit of verifying reports since false reports will never produce matching TCNs.

Memo

In the report structure, the memo is a space for freeform messages that differ between TCN implementations. The section is between 2 and 257 bytes, and made up of a tag identifying the specific implementation, as well as a data and data length pair. It is formatted as ${\displaystyle memo=tag||len(data)||data}$. The data is standardized for different tags, and can be as follows:

Encounter handshake

When two devices come within range of each other, they exchange a handshake containing TCNs. In order to achieve this the encounter handshake operates in two modes (both with two sub-modes), broadcast oriented and connection oriented. Broadcast oriented operates using the modes broadcaster and observer, while connection oriented operates using peripheral and central. The two modes are used to circumvent certain device limitations, particularly in regard to iOS restrictions in place before version 13.4.^[43] In both modes the protocol is identified with the 16 bit UUID 0xC019.

In broadcast mode, a broadcaster advertises a 16-byte TCN using the service data field of the advertisement data. The observer reads the TCN from this field. In connection-oriented mode, the peripheral advertises using the UUID. The service exposes a read and writeable packet for sharing TCNs. After sharing a TCN, the central disconnects from the peripheral.

Infection reporting

When a user tests positive for infection, they upload a signed report, allowing the past 14 days of encounters to be calculated, to a central server. On a regular basis, client devices download reports from the server and check their local contact logs using the verification algorithm. If there is a matching record, the app notifies the user to potential infection.