Check-In via a Printed QR Code¶
This variation allows the Guest App to create Check-Ins by scanning a printed QR code. For instance, a restaurant might place such a QR code on each available table. In contrast to the conventional check-in the Scanner Frontend is not involved. Instead, the Guest App assumes the role of the scanner and generates a Check-In single-handedly.
The following secrets are involved in this process:
Use / Purpose
The Guest’s secret seed to derive both the data encryption key and the data authentication key. This seed will be encrypted for the Health Department in this process and protects the Guest’s Contact Data stored on the Luca Server (cf. contact data reference).
Securely stored locally on the mobile device (see Guest Registration for further details).
Securely stored locally on the mobile device.
In this variation the Guest App conceptually assumes the role of the Scanner Frontend as described in the convential Check-In process. The Guest App gains all required information from printed QR codes provided by the Venue Owner.
Printed QR Code Generation¶
To facilitate this feature, the Venue Owner generates and provides QR codes that encode the following information:
Those QR codes are then printed and visibly placed at the venue for Guests to scan using the Guest App. For instance, in a restaurant the Venue Owner might place a unique QR code on each table and note the table number in the QR code’s additional data.
Check-In via the Guest App¶
The Guest App now proceeds just like for the conventional Check-In process. Most notably, it fetches and validates the daily keypair 1 from the Luca Server, generates a valid trace ID using its tracing secret and a contact data reference (encrypted for the daily keypair).
In the conventional Check-In process this data would now be encoded into a QR code and presented to a Scanner Frontend to finish up the Check-In and upload it to the Luca Server. Instead, the Guest App re-encrypts the generated data for the venue keypair, associates it with the scanner ID and uploads the finalized Check-In to the Luca Server itself.
Authenticity of the venue keypair¶
The printed QR code merely contains a scanner ID which is used to fetch the public key of the venue keypair from the Luca Server. At the moment, there is no way for the Guest App to validate the authenticity of this public key. A later version of the printed QR codes will contain the venue keypair’s public key directly.
Note, however, that the impact of a malicious public key is limited in this scenario as it only affects the outer layer of the contact data reference’s encryption. The contact data reference is still encrypted for the daily keypair and thus only accessible for the Health Department. Nevertheless, a theoretical collusion between the Luca Server and the Health Department could still harm security objective O6.
Until the mentioned improvement is implemented, this risk is accepted.
Authenticity of Printed QR Codes¶
By nature, QR codes are easily forgable by simply copying them. Hence, an attacker might maliciously replace QR codes of one venue with another one. This would lead to misguided Check-Ins by Guests and eventually generate false information for Health Departments during contact tracing.
As the Luca system cannot appropriately protect itself from such attacks, it relies on the Venue Owner to make sure that printed QR codes in their venue are not physically replaced by an attacker.
Direct Communication of Guest App and Luca Server¶
In contrast to the conventional Check-In process, the Guest App actively uploads its Check-In data to the Luca Server. This might allow the association of user-specific meta-data (e.g. their IP address) and the Check-In’s trace ID by the Luca Server (directly contradicting security objective O2). As mobile phone networks typically use NAT, the fact that the Luca Server does not log any IP addresses and the request being unauthenticated, we do accept this risk.