Pan-European Privacy-Preserving Proximity Tracing

Authentication

Authentication during registration is required to prevent malicious actors from creating a multiple false user accounts, using them to interfere with the system. In order to preserve the anonymity of the users, traditional authentication models using static identifiers such as email addresses or phone numbers could not be employed. Rather, the protocol uses a combination of a proof-of-work challenge and CAPTCHA.^{[8]: p. 11} The suggested proof-of-work algorithm is scrypt as defined in RFC7914, popularized in various blockchain systems such as Dogecoin^[12] and Litecoin.^[13] Scrypt was chosen because it is memory bound rather than CPU bound.^[14] Once a user registers with the app, they are issued a unique 128 bit pseudo-random identifier (PUID) by the server. It will be marked inactive until the app solves the PoW challenge with the input parameters of ${\displaystyle input=nonce||challenge}$, a cost factor of 2, and a block size of 8. Once completed, OAuth2 credentials are issued to the client to authenticate all future requests.^[15]

Encounter handshake

When two clients encounter each other, they must exchange and log identifying details. In order to prevent the tracking of clients over time through the use of static identifiers, clients exchange time sensitive temporary IDs issued by the central server. In order to generate these temporary IDs, the central server generates a global secret key ${\displaystyle BK_{t}}$, which is used to calculate all temporary IDs for a short timeframe ${\displaystyle t}$. From this an Ephemeral Bluetooth ID (EBID) is calculated for each user with the algorithm ${\displaystyle EBID_{t}(PUID)=AES(BK_{t},PUID)}$ where ${\displaystyle AES}$ is the AES encryption algorithm. These EBIDs are used by the clients as the temporary IDs in the exchange. EBIDs are fetched in forward dated batches to account for poor internet access.^[15]

Clients then constantly broadcast their EBID under the PEPP-PT Bluetooth service identifier, while also scanning for other clients. If another client is found, the two exchange and log EBIDs, along with metadata about the encounter such as the signal strength and a timestamp.^[15]

Infection reporting

When a user, out of band, has been confirmed positive for infection the patient is asked to upload their contact logs to the central reporting server. If the user consents, the health authority issues a key authorizing the upload. The user then transmits the contact log over HTTPS to the reporting server to be processed.^[15]

Once the reporting server has received a contact log, each entry is run through a proximity check algorithm to reduce the likelihood of false positives. The resulting list of contact is manually confirmed and they, along with a random sample of other users, are sent a message containing a random number and message hash. This message serves to wake up the client and have them check the server for new reports. If the client is on the list of confirmed users, the server will confirm potential infection to the client which will in turn warn the user. If a client is in the random sample, it will receive a response with no meaning. The reason a random sample of users is sent a message for every report is so that eavesdroppers are not able to determine who is at risk for infection by listening to communication between the client and server.^[15]