Finding Potential Contact Persons¶
The following secrets are involved in this process:
Use / Purpose
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).
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¶
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.
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.
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.