Guest Registration

In this process a new Guest registers to the luca system. This process is required for Guests using the Guest App. During this process, local secrets are created, the Guest enters their Contact Data and identifiers and encrypted data are sent to the luca Server.





  • the Guest is not registered

  • the Guest App is installed



The following secrets are involved in this process:


Use / Purpose


data secret

A secret “seed”1 which is used to derive both the data encryption key and the data authentication key. This seed is the secret that is encrypted twice before being sent to the luca Server during Check-In and ultimately protects the Guest’s Contact Data.

Securely2 stored locally on the mobile device

data encryption key

A symmetric key derived from the data secret, used to encrypt the Contact Data.

Not stored

data authentication key

A symmetric key derived from the data secret, used to authenticate the Contact Data. It is also used to authenticate Check-Ins.

Not stored

tracing secret

Used by the Guest App to generate trace IDs during Check-In and (after the Guest granted access to it) by the Health Department for contact tracing.

Securely stored locally on the mobile device

guest key pair

A pair of public and private key that is used to authenticate both new and updated encrypted guest data.

The public key is stored on the luca Server. The private part is securely stored locally on the mobile device.


The diagram below provides an overview to the complete process.


Creating the Secrets

On initial startup the Guest App generates the following secrets:

It stores this data2. The Guest App then derives two keys from data secret as follows:

The derived keys are used in the remainder of the registration process but are not persisted on the device.

Verifying the Contact Data

Upon first launch of the Guest App the Guest provides their Contact Data to the App.

The App then verifies the Guest’s phone number. For that, the phone number the Guest entered is sent to the luca Server, which then creates a challenge. Using an external SMS Service Provider a verification TAN is sent to that phone number either as an SMS or as a voice call. After entering the TAN in the App it is verified by the luca Server. The luca Server keeps no record of the Guest’s plaintext phone number after that 3.

Encrypting the Contact Data

If the TAN verification is successful, the Guest App creates and signs encrypted guest data as follows:

# pseudocode

iv = random_bytes(16)

encrypted_guest_data = AES_128(contact_data + data_authentication_key,

guest_data_mac = HMAC(encrypted_guest_data,

guest_data_signature = guest_keypair.private.sign(encrypted_guest_data +
                                                  guest_data_mac +

The artifacts created here are uploaded to the luca Server in the next step.

Registering to the luca Server

The Guest App sends the following data to the luca Server:

The luca Server returns the Guest’s user ID. In the end of the process the two participants have stored the following data:

Guest App

luca Server

Updating the Contact Data

Guests should be able to update their Contact Data. This is needed, for example, in case their address or phone number changes. Whenever a Guest changes their Contact Data in the Guest App, the App creates a new encrypted guest data package by repeating the steps described in the Section Encrypting the Contact Data. Using the user ID retrieved during the initial registration, the App uploads the following data to the luca Server:

  • the encrypted guest data

  • the IV used in the encryption

  • the guest data mac

  • the guest data signature

The luca Server verifies that the Guest is authorized to update the data by checking the signature with the already present guest key pair’s public key.

Rotating the Tracing Secret

The tracing secret is used by the Guest App to generate the trace IDs for Check-Ins. Whoever knows a tracing secret (and the respective user ID) can calculate all trace IDs the App has derived from this secret and thus reconstruct a part of the Guest’s Check-In History.

This is desired, of course, when an Infected Guest consents to revealing their tracing secret to the Health Department during Contact Tracing. However, the Health Department should only learn the epidemiologically relevant part of the Guest’s Check-In History (cf. Security Objective O5).

To guarantee this, the Guest App rotates the tracing secret once a day. If the Guest is infected, the App transfers all recent, epidemiologically relevant, tracing secrets to the Health Department. As a result, the Health Department can only reconstruct that part of the Check-In History which has been created based on the shared tracing secrets.

Security Considerations

Verification of the Guest’s Contact Data

Guest’s Contact Data is encrypted in luca’s client application before being uploaded to the luca Server. Hence, luca cannot validate any personal data provided by the Guest. On the other hand, Health Departments are dependent on valid Contact Data to be able to contact Guests if necessary.

This poses a trade-off between data validity and personal data protection (cf. O1). Currently, luca validates the user’s phone number via an SMS TAN that is generated and checked on the luca Server before registering a Guest with their encrypted contact data. This checks that the provided phone number is valid and belongs to the registering Guest.

Nevertheless, this validation step could be omitted by manipulating the client software. The luca Server has no definitive way of making sure that the encrypted phone number provided in the registration matches the one that was validated.


The reason for deriving the two secrets from a seed rather than creating both of them at random is the limited “storage capacity” of the QR code during Check-In.


All secrets stored on the device are protected using the respective OS’ native credential storage mechanism. Specifically, the Android keystore system on Android and the iOS Keychain Services on iOS.


According to the German “Telekommunikationsgesetz” the SMS Service Provider is legally required to store the messages for 90 days.