Hello,

wouldn't it make sense to be able to configure a kind of location time-based checkout?

Time-based Check-out after 24 hours
https://luca-app.de/securityconcept/processes/guest_checkout.html

From my point of view a time-based checkout per location would be helpful.
For example visiting a gas station takes less than an hour, visiting a restaurant mostly less than 4 hours.
Also something like opening hours could make sense.
E.g. if opening ours are from 9 a.m to 6 p.m. all guest could be checked out at 7 p.m. automatically.

Thanks.

Moin,

erstmal Klasse Arbeit, viele Grafiken (die das lesen einfacher machen) und viel Pseudocode...

Aus dem Aspekt der Dokumentation (a, dass diese vorliegt; b, dass diese lesbar ist!) n1.
Hier im Repo ist sie etwas verbuggt (ok es ist eines dieser PyBooks), wie es scheint, aber das macht nichts, man kann ja die schicke Doku auf der Webseite lesen (https://luca-app.de/securityconcept/intro/landing.html)

Ich sehe ein Problem mit dem Pseudocode, denn er erlaubt nur zu sehen wie es implementiert sein könnte. Er zeigt leider nicht, wie es unter der Haube, verdrahtet ist. Darum sehe ich darin eine größere Wahrscheinlichkeit, dass wir als "Leser" Implementierungsfehler übersehen könnten, die weitaus größere, gefährlichere Schwachstellen beinhalten könnten.
Deswegen denke ich, dass ein paar Snippets aus dem echten Code angebracht sein könnten.
Mal abgesehen vom Fakt, dass heute jedes Skid Reverse Engineering betreiben kann, wenn es die richtigen Tools findet.

Eine gewisse Reduzierung auf den Sec Code und den Ablauf in einer zusätzlichen Übersicht, könnte nicht nur Wartungskosten für die Doku reduzieren, sondern auch die (Ein-)Lesezeit. Gleichzeitig würde es aber das Verständnis entsprechend hochhalten, sodass Schwachstellen / Leaks gefunden werden können.

Kollegiale Grüße! 👍 :-)

Anmk.: Spät "Abends" in Fremdsprachen schreiben zählt mitunter nicht zu meinen Stärken :-)

English "Translation":
Hello,

First of all, excellent work, a lot of Graphics (they maintain a good readability) and a lot of Pseudocode...

In the aspects of a Documentation (a it does exist; b it's readable) n1. The documentation is a bit buggy in this Repo (it's a pybook), but that doesn't disturb anyone as long we can read it on the website (see link above in GER Text)

I see a few problems with the Pseudocode... The code just shows how it could be implemented. It doesn't show the wiring under the hood. Therefore I see a big possibility that we overlook dangerous implementation flaws.
So I think a few code snippets out of the implementation could be needed.
Besides the fact that every Skid can do Reverse Engineering these days with the right Tools in the hand

A Reduction of the documentation in a additional overview for only the most important facts could be needed too in my opinion. Since it reduces the time for reading and the maintenance costs of the Docs and keeps the understanding high enough to spot vulnerabilities and leaks.

Yours Sincerely 👍 :-),

The client leaks the following information via the API to the luca servers:

• the phone number (request URL: https://app.luca-app.de/api/v3/sms/request)
• the location history (Request URL e.g. https://app.luca-app.de/api/v3/scanners/54f0a623-4753-4265-9e62-9ae1e76c2228)

That means that there is all information provided to the server that would be needed to build movement profiles around a phone number.

The luca app maintainers mentioned multiple times that the app is built based on trust to them, so this is not an issue from their perspective.

But as I see no reason why I should trust a few incompetent venture-funded 🤡 with influencer friends, I don't see why the entire security concept should work out.

From an architectural perspective, it would be totally possible (e.g. by utilizing the signal protocol and decentralized storage of the personal/tracking data) to work without a trusted central platform to tackle the same issues. But as the luca team didn't come up with these ideas themselves, I don't think it makes sense to discuss them here 🤷‍♀️.

Moin,

Beim ersten Öffnen der App wurde ich in einer Update-Schleife gefangen.

Nach Eingabe aller Kontaktdaten und Bestätigung dieser per Button wurde ich auf die Hauptseite geleitet. Von dort bin ich auf "App Details" gegangen und habe die Kameraberechtigung gesetzt.
Dann bin ich zurück zur Hauptseite. Welchen der beiden Buttons ich dazu genutzt habe, weiß ich leider nicht mehr.
Einen weiteren Klick im 3P-Menü habe ich noch gemacht, aber abgebrochen, weil sich eine Website öffnen wollte.
Zurück auf der Hauptseite habe ich aus unklaren Gründen einfach mal den Android-Zurück-Button geklickt.
Dann war ich wieder in der Kontaktdatenerfassung. Nach Klick auf "Update" bin ich aber darin geblieben.
Nochmaliges Klicken hat mich immer wieder zu dieser Seite gebracht. Beenden der App und Neustart hat geholfen.
Erwartetes Verhalten war, nach Klick auf "Update" auf die Hauptseite zu gelangen.

Gruß und Danke für die App,
Lars

Scanners currently share the same id as the location. They expose the current and total checkins (Maybe more?). Scanners should have their own secret id only visible to the operator.

Overview

Relying only the information contained in this repository it seems to be the case that it is possible for a malicious user to generate a forged check-in QR code in such a way that the forgery is not detectable by the venue or the Luca backend. If I am correct this would allow a malicious user to successfully check into a venue without disclosing any information necessary for contact tracing.

Introduction

https://github.com/lucaapp/security-concept/blob/main/content/processes/guest_app_checkin.md describes the data which is encoded in the QR code generated by the Luca app which is intended to be scanned by the venue:

• version (QR code protocol version)
• device_type
• key_id (ID of the daily keypair used for this Check-In)
• timestamp
• trace_id
• enc_data
• ephemeral_keys.public
• verification_tag
• checksum

where

timestamp        = UNIX timestamp rounded down to the last full minute (little endian encoding)
trace_id         = HMAC-SHA256(user_id || timestamp, tracing_secret)  # truncated to 16 bytes
ephemeral_keys   = a new secp256r1 key pair (for DLIES with the daily public key)
dh_key           = ECDH(ephemeral_keys.private, daily_keypair.public)
enc_key          = SHA256(dh_key || 0x01)  # truncated to 16 bytes
iv               = ephemeral_keys.public   # truncated to 16 bytes
enc_data         = AES-128-CTR(userId || data_secret, enc_key, iv)
verification_tag = HMAC-SHA256(timestamp || enc_data, data_authentication_key)

and the tracing_secret, the data_secret and the data_authentication key are neither known by the venue, nor by the attacker nor by the Luca backend. Additionally it is assumed that daily_keypair.public, key_id, version and device_type are public information.

Description of the attack

In order to perform the attack a maliciuous user has to generate a QR code containing the information mentioned above which is accepted by the scanning venue and the Luca backend. So let's have a look at all elements of the QR code:

version

Public information

device_type

Public information

key_id

Public information

timestamp

Public information

trace_id

For an honest user the trace_id is calculated as follows:

HMAC-SHA256(user_id || timestamp, tracing_secret)  # truncated to 16 bytes

The attacker does not know the tracing_secret but neither do the venue nor the Luca backend. This in turn means that any 16 byte random information has to be accepted by the venue and the Luca backend, because they can not verify it.

enc_data

For an honest user this value is calculated as

ephemeral_keys   = a new secp256r1 key pair (for DLIES with the daily public key)
dh_key           = ECDH(ephemeral_keys.private, daily_keypair.public)
enc_key          = SHA256(dh_key || 0x01)  # truncated to 16 bytes
iv               = ephemeral_keys.public   # truncated to 16 bytes
enc_data         = AES-128-CTR(userId || data_secret, enc_key, iv)

It has to be noted that none of the involved parties knows the data_secret but the other information can be generated by the attacker. If the attacker performs the calculations above using a random value (of correct length) for the data_secret and the user_id the results have to be accepted by the backend and the venue because neither of them holds the private daily_key and therefore can not perform the decryption operation which would be necessary in order to detect the forgery.

ephemeral_keys.public

Can be generated by the attacker.

verification_tag

For an honest user this value is caclulated as follows:

verification_tag = HMAC-SHA256(timestamp || enc_data, data_authentication_key)

For this calculation the data_authentication_key is needed. This key is not known to the attacker, the venue and the Luca backend. This again means that any random 8 (the HMAC is truncated to 8 bytes according to this documentation) byte value has to be accepted by the venue as well as the backend because they have no means to verify it.

checksum

Checksum is the SHA-256 hash truncated to 4 bytes of the previously described data and can be easily generated by an attacker.

Conclusion

If I have not missed a central piece of information an attacker can easily create a QR code which can be used to check in to a venue but is unusable for contact tracing and does not disclose the identity of the attacker.

In the security objectives you are stating

Traced Guest’s Contact Data is disclosed to the Health Department only after Venue Owners’ consent

Theoretically, on initiation of a Contact Tracing Process and immediately after a Venue Owner's technical consent, Luca app could automatically notify all concerned app users without having to know their individual contact data. Luca app could als prompt this user segment for additional consent to share their contact data.

This would eliminate the often slow and cumbersome manual processes in the respective Health Departments and immediately and automatically notify potentially infected guests.

It would also make sure that at no time (in the future) any authority could abuse the tracking data without the consent of the respective owner.

Requiring the Venue Owner's consent sounds good in theory, but realistically, a governmental authority will likely be able to force Venue Owner's to decrypt the collected data, hence not protecting individual guests privacy.

Has this been part of Luca's thought process and what is Luca's position on this?

Heya,

the docs outline an assurance for guests being notified about data access by the health department after their contact data has been decrypted.

With the wide rollouts of Luca and your recent open source release of the app (thanks btw) I've tried to confirm if I got how that works but I'm a bit confused:

• The code that uses the endpoint related to traces that should be notified (DataAccessManager::fetchRecentlyAccessedTraceData) seems to be invoked exclusively in tests.
• The staging endpoint returns traces in the expected format while the production endpoint errors out with a 401 and expects some form of authentication I cannot find in the open source release or apk.

Given the above: Do I inherently misunderstand something in the concept / is this simply not yet implemented / how can users be certain that they are notified when their data is decrypted and accessed by a health department?

edit 1: clarified on Twitter the endpoint is actually periodically checked in the app code.

Since it seems like that you'll only maintain the security concept here on GitHub, please link to your GitLab so that everybody who's looking for the source code can find it.

Thanks for providing the Security Concept behind Luca. In the introductory paragraphs you’re stating:

This Check-In is encrypted in a way that only the public health authorities can read it. The encrypted Check-In is then transferred to the venue owner via a QR code, where the Check-In is encrypted once again by the venue owner so that nobody can access the user’s personal information at this stage.

Since there is no Luca “server“ infrastructure operated or owned by the venue owner, what exactly does “transferred to the venue owner” mean?

Hallo,
gestern wollte ich mir einen Überblick über das Sicherheitskonzept verschaffen.
Mein Tipp ist: Stellt (per automatischem Bauprozess oder so) auch eine PDF Version mit Nummer zur Verfügung.

Das hat zwei Vorteile:

• Lesen von Papier ist in der Regel immer noch schneller als vom Bildschirm, gerade wenn es um das Verständnis
  der Struktur geht und ich es ganz lesen würde.
• Die fixe Versionsnummer ist leicht angebbar, habe Version 0.9.1 oder Hash xyz vom 2021-03-dd gelesen. (Als nur den Repo-Hash jetzt anzugeben.)

Dieser Wunsch ist natürlich optional, da ich mir ja die Bauwerkzeuge selbst holen und die Anleitung befolgen und ein PDF bauen kann. Zumindest bei mir würde es die erste Zugangshürde leicht senken.

(Technisch noch besser wäre ein offenes Standardformat, wie ODT, aber Ihr habt ja den Bauprozess für PDF schon.)

Please include all licence informations in https://app.luca-app.de/webapp/static/js/2.1ae68762.chunk.js.LICENSE.txt
At least a licence info for the used Ascii85/Base85 implementation is missing.

Regards
Tobias

You are stating

Private keys of daily keypairs that are older than the epidemiologically relevant time span (specifically, four weeks) can be destroyed. The Luca Server removes all such encrypted private keys for all Health Departments. Furthermore, the Health Department Frontend removes all locally stored copies of such private keys.

How can Luca guarantee the removal / deletion of locally stored daily key pairs at the Health Departments? I assume that Health Departments could in theory store a copy of those keys forever or simply not log into the HD Frontend for any given time, hence preventing deletion.

It is my understanding that Health Departments and governmental organizations can create an archive of all Daily Keypairs ever used and store it outside Luca's system for eternities. Is this correct?

As outlined by this tweet here, the API rate limiting seems to be bypassable by switching the casing of API endpoints.

I wasn't able to find a proper way to report security issues, so I assumed creating this issue here is a proper place to do so.
I believe this should be fixed quickly, especially as some endpoints can be abused if no proper rate-limiting policy is enforced (f.e. auth endpoints & brute-forcing logins).

Kind regards,
Tobias Grether

You are stating

The encrypted private keys are stored on the Luca Server.

Given that culture4life GmbH and the parties contracted to operate the Luca infrastructure at any time do have access to Luca Server, this would immediately break the promise, that Luca has no access to the data protected by the Health Departments' key pair. Private keys must not be stored in infrastructure owned or operated by an intermediary or they cannot be considered private anymore.

What is the rationale behind storing the Health Departments' private keys on Luca owned infrastructure?

The webapp uses 'dd.mm.yyyy' as formatstring for dates with momentjs. This results in loading the current daily key every minute. To fix this the string should be 'DD.MM.YYYY'. See https://momentjs.com/docs/#/displaying/

It would be the right decision to make it open source.

As your TOS currently states

(c) Teile der Dienste dekompilieren, im Wege des Reverse Engineerings rekonstruieren, zerlegen oder auf eine andere Weise versuchen, Quellcodes, Objektcodes oder zugrundeliegende(s) strukturelle Ideen, Know-how oder Algorithmen oder andere Funktionsmechanismen der Dienste zu erlangen, es sei denn, dies ist im Einzelfall aufgrund zwingender gesetzlicher Vorschriften zulässig; (d) alle oder einen Teil der Dienste modifizieren, anpassen, übersetzen oder abgeleitete Werke erstellen, die auf den Diensten basieren (außer in dem durch luca gestatteten Umfang oder sofern dies im Rahmen der Dienste genehmigt wurde);

it is basically illegal to do any kind of serious security research except reading your br0ken security documentation.

So if I do any responsible disclosure stuff for your system the next thing I probably would have to expect from you is a letter from your lawyer.

As I hope this is not what you venture-funded 🤡 actually want, just remove this part from your TOS.

The contact form https://app.luca-app.de/contact-form/{location-id} does not send any additional data.

As the code of the webapp is freely editable, it is possible to uncomment the verification step or to change the phone number in between. This leads to a wrong phone number (not reachable or somebody else) being submitted in the encrypted data object.

A false identity has 2 consequences (as with the analog way)
a) I am not informed if I am a risk person and cannot be tested.
b) someone else is informed, resolves the misunderstanding, and effort was generated for nothing.

As it is not possible to secured the JS code executed in the browser from manipulation, let's evaluate some mitigation or resolutions.

Hello,
just started to work with locations and Luca app.
I created a location, enabled Automatic Checkout, checked in via printed QR-code and tried to checkcout manually (AUSCHECKEN (<--)).
Now I get an Info (Error) message my position is required to checkout.
(Info: Wir brauchen deine Position, um zu überprüfen, ob du dich bei befindest. Wähle in deinen Luca Standort Einstellungen "immer".)

Is this intended behavior to disallow manual checkout if location has automatic checkout enabled?

Thanks.