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 Scanner or Operator 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¶
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. More specifically, notifications are issued whenever a Venue Owner decrypted the outer layer of the requested Check-In data and shared it with a specific Health Department.
For further details, please refer to Notifying/Warning Users. The notification about data access by a Health Department is considered “severity level” #1 and results in an informational notification for the Traced Guest.
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.