Tracing the Check-In History of an Infected Guest

The goal of this process is to identify Guests that are at a risk of being infected, as a result of having been in contact with an Infected Guest. The process consists of two major parts: Tracing the Check-In History of an Infected Guest and Finding Potential Contact Persons. This chapter describes the first part.

Overview

Preconditions

Postconditions

Secrets

The following secrets are involved in this process:

Secret

Use / Purpose

Location

tracing secrets

Given the consent of the Infected Guest the relevant tracing secrets are made available to the Health Department and the Luca Server to reconstruct the Check-In History.

data secret

During the process, the Health Department Frontend fetches the Infected Guest’s encrypted guest data, decrypts it using the data secret, and displays it.

daily keypair

The Guest App encrypts the guest data transfer object with the public key. The Health Department uses the private key for decryption of the same.

tracing TAN

The TAN is created on the Luca Server as an identifier for the encrypted guest data transfer object by request of the Guest App, which displays it to the Guest. The Guest then communicates it to the Health Department.

Process

../_images/tracing_access_to_history_2_0.svg

The first part of the contact tracing is for the Health Department to reconstruct the Check-In History of the Infected Guest. Each Check-In stored in luca is associated with an unique trace ID. These IDs are derived from the tracing secret stored in the Guest App (as well as from the Guest’s user ID and a timestamp). Hence, given the Infected Guest’s tracing secrets the Health Department can reconstruct the Infected Guest’s trace IDs and find all relevant Check-Ins.

Accessing the Infected Guest’s Tracing Secrets

In the first step the Health Department needs to acquire the Infected Guest’s tracing secrets for the epidemiologically relevant timespan. Each tracing secret will allow the Health Department to find all Check-Ins whose trace ID is based on this secret.

In the beginning of the process, an Infected Guest is directly contacted by a local Health Department. In order to retrieve the Guest’s tracing secrets the Health Department asks the Guest to reveal their Contact Data and Check-In History via a functionality in the Guest App.

When this functionality is activated, the App creates a guest data transfer object that holds all information required for the Health Department’s tracing process:

Asset

Use

tracing secrets

Needed to reconstruct the Guest’s trace IDs

user ID

Needed to reconstruct the Guest’s trace IDs

data secret

Used to validate and display the Infected Guest’s identity in the Health Department Frontend

The data is encrypted using the current daily keypair’s public key 2 and uploaded to the Luca Server. The Luca Server returns a tracing TAN, which is a short alpha-numeric identifier for the guest data transfer object on the Luca Server and does not carry any further security relevance.

The Infected Guest can now pick up their communication with the Health Department and spell out the tracing TAN. This allows the Health Department to retrieve the encrypted guest data transfer object from the Luca Server. The transfer object is decrypted using the daily keypair’s private key. Usage of the daily keypair within the Health Department is detailed in Chapter Daily Keypair Rotation.

After a short timespan of a few hours unused or no longer needed encrypted guest data transfer objects are deleted from the Luca Server.

Reconstructing the Infected Guest’s Check-In History

The second step is for the Health Department to find all venues where the Infected Guest has created Check-Ins within the recent, epidemiologically relevant timespan (e.g. 14 days).

To start the tracing process, the Health Department sends the Infected Guest’s tracing secrets to the Luca Server. Based on the secrets and the affected user ID, the Luca Server generates all possible trace IDs for the relevant time frame. Given these trace IDs luca can find all Check-Ins created by that Guest during that time frame—the Infected Guest’s Check-In History.

The Luca Server can use the recovered Check-In History to contact all venues the Infected Guest has visited. The process of contacting Venue Owners for lifting the outer layer of encryption in each affected Check-In is described in the next part.

Security Considerations

Correlation of Guest Data Transfer Objects and Encrypted Guest Data

After receiving a Infected Guest’s guest data transfer object the Health Department Frontend uses the contained user ID to obtain that Guest’s encrypted guest data from the Luca Server. This is done in order to display the Infected Guest’s Contact Data to the Health Department.

The Luca Server can (indirectly) use this circumstance in order to associate a guest data transfer object with the encrypted guest data of the same Guest by observing the Health Department Frontend’s requests.

Accidental Upload of Guest Data Transfer Object

Guests could trigger the Guest App’s functionality to upload the guest data transfer object and request a TAN accidentally or out of curiosity. This would needlessly upload their encrypted secrets, but they still would not be accessible to the Luca Server (as they are encrypted for the daily keypair) nor the Health Department (as they do not know the TAN).

We believe this risk is acceptable and can further be mitigated by an informative warning message in the Guest App when activating the functionality.


1

The process can also be trivially performed if the Guest has not created any Check-Ins but the Check-In History will be empty.

2

Whenever making use of the daily keypair the Guest App verifies the key’s validity and authenticity as described in Daily Keypair Rotation.