Finding Potential Contact Persons

Secrets

The following secrets are involved in this process:

Secret

Use / Purpose

Location

data secret

The data secrets of all Traced Guests are made accessible to the Health Department in the process in order to decrypt the encrypted guest data.

venue keypair

The keypair’s private key is used in the Venue Owner Frontend to decrypt the outer layer of encryption on the contact data reference and the Additional Data in each Traced Guest’s Check-In.

daily keypair

The keypair’s private key is used in the Health Department Frontend to decrypt the inner layer of encryption on the contact data reference in each Traced Guest’s Check-In.

Process

../_images/tracing_find_contacts_2_0.svg

Given the Infected Guest’s Check-In History (obtained in part 1 above the Luca Server determines all Venue Owners whose venues have been visited by this Guest. Each of them is contacted using the Venue Information provided during Venue Registration and asked to reveal the encrypted contact data references of potential contact persons (Traced Guests).

When a Venue Owner has been contacted to assist in contact tracing they use the respective functionality in the Venue Owner Frontend. The Venue Owner Frontend proceeds to download all Check-Ins registered for this venue that coincide with the visit of the Infected Guest from the Luca Server. For each of these Check-Ins both the outer encryption layer on the contact data reference and the Additional Data are decrypted using the private key of this venue’s venue keypair. Note that, after the decryption, the contact data reference is still encrypted with they daily keypair and thus only accessible to the Health Department (see Check-In via Mobile Phone App).

The data is uploaded back to the Luca Server in order to be shared with the Health Department that initiated the tracing.

After decrypting the contact data references the Health Department possesses each Traced Guest’s user ID and data secret. It fetches the Guests’ encrypted guest data from the Luca Server using the user ID and decrypts it using the data encryption key (derived from the data secret) to obtain the Contact Data and the data authentication key. The latter is used to verify the authenticity of both the Check-In and the contact data reference. The Contact Data can now be used to contact the Traced Guest and inform them that they are at risk of being infected.

Notifying Guests about Data Access

Both for transparency reasons and as an early warning of a potential SARS-CoV2 exposure, luca automatically informs the Traced Guest about the data access by a Health Department.

To implement this notification in a privacy-preserving manner, the Luca Server publishes lists of hashed trace IDs affected by contact tracing activities of a Health Department. Specifically, it maintains one list per Health Department.

Guest Apps download these lists on a regular basis and check their recently used trace IDs (which the app keeps track of locally) against them. If a match is found, the Guest App (and of course the Traced Guest) learns (a) that a data access by the Health Department took place and (b) which Health Department(s) gained access to their personal data.

The trace IDs are hashed and truncated to 16 bytes by the Luca Server before being published:

hashed_trace_id = HMAC-SHA256(data=trace_id, key=health_department_id).truncate(16)

to conceal that trace IDs might appear in more than one Health Department list. Naturally, the Guest App must hash its locally stored trace IDs the same way before matching them with the notification lists.

Published trace IDs are removed from these lists after four weeks.

Security Considerations

Authentication of Contact Data and Check-Ins

The data authentication key is used to authenticate both the contact data reference in the Check-In (using the verification tag) and the Contact Data. However, the data authentication key has to be retrieved by deriving the data secret contained in the contact data reference.

This is unusual (cf. Encrypt-then-MAC), but we consider it sound. Please refer to the Security Considerations regarding Guest Check-In for further details.

Possible Abuse of Traced Guests’ Data Secrets

In the process described above the Health Department obtains each Traced Guest’s data secret and derives the symmetric data authentication key from it. It uses this key to validate the authenticity of the Check-Ins, verifying that the Check-Ins it received from the Luca Server have in fact been created by the owner of the data secret (the Traced Guest).

However, having learned the data secret, the Health Department can now itself create apparently valid Check-Ins for that Traced Guest. Neither the Luca Server nor another Health Department can distinguish these forged Check-Ins from authentic ones.

Note that the Health Department does not know Traced Guests’ tracing secrets here. Hence, the forged Check-Ins would not appear in the Guest’s Check-In History. They would, however, appear whenever the forged Check-In coincides in time and place with another Traced Guest’s Check-In.

Access Notification Lists reveal the Number of Traced IDs

The number of hashed trace IDs in the above-described access notification lists reveals the number of Check-Ins recently accessed by any Health Department.