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.

Overview

Participants

Assets

Preconditions

Postconditions

Secrets

The following secrets are involved in this process:

Secret

Use / Purpose

Location

data secret

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).

tracing secret

Used to generate an anonymous trace ID to facilitate contact tracing by the Health Department (after the Guest granted access to the tracing secret – rendering them an Infected Guest).

Securely stored locally on the mobile device.

daily keypair

Used to encrypt the above-mentioned data secret on the Guest’s mobile device before transferring it to the Scanner Frontend via a QR code.

The public key is obtained from the Luca Server 1. The private key is known to all Health Departments. (see Daily Public Key Rotation for further details).

venue keypair

Establishes a second encryption layer for the contact data reference that is already encrypted with the daily keypair.

Public key is known to the Luca Server and downloaded by the Guest App while checking in. Private key is stored by the Venue Owner.

Process

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

To check-in, Guests scan the printed QR code using their Guest App. The Guest App can now use the scanner ID encoded in the QR code to retrieve the venue keypair’s public key from the Luca Server.

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.

The resulting Check-In is equivalent to a Check-In performed by the Scanner Frontend.

Security Considerations

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.


1(1,2)

The provided public key of the daily keypair is signed by a Health Department using their HDSKP (see also Verification of Health Department Keypair Certificates). This signature is provided by the Luca Server along with said public key.