Discuss the current security approach (german language)

[rfuehrer]

Folgende Erweiterung des aktuellen Zustandes soll erreicht werden (aktueller Stand aus unserer gestrigen Diskussion). Bitte Erweiterungen, Korrekturen etc. als Antwort melden.

---

Funktionsweise

My co:radar ("die App") arbeitet als lokaler Service auf dem Mobiltelefon des Anwenders. Die App generiert beim ersten Aufruf eine eigene zufällige Kennung ("UUID"), die zudem mit einem gerätespezifisch generierten Code ("Code") gesichert wird. Dieser Code wird in der App als Klartext-Information für den Anwender angezeigt und ist später auch als QR-Code abrufbar.

Die App scannt alle 2:30 Minuten (konfigurierbar) per Bluetooth nach weiteren Geräten mit der App ("Ping"). Andere Geräte mit der App senden eine Bestätigung ("Pong") mit der eigenen UUID, die in der suchenden App lokal auf dem Gerät gespeichert wird ("Kontakt"). Gespeichert werden UUIDs des Kontakts und Zeitstempel des Kontakts.

Dabei ist für die abfragende App relevant, wie dicht man sich an anderen Geräten befindet (Signalstärke Bluetooth) und wie lange man sich in der Nähe des anderen Geräts aufhält (Anzahl der Pings). Diese Werte richten sich nach den Empfehlungen des Robert-Koch-Instituts ("RKI"): weniger als 2 Meter Abstand und länger als 15 Minuten. Diese Angaben lassen sich bei Bedarf anpassen.

Wird ein Anwender eines Gerätes nun als positiv COVID-19 getestete, meldet die App darauf hin alle in Kontakt gestandenen UUIDs der vergangenen 14 Tage (anpassbar; gemäß Empfehlung des RKI) an einen zentralen Service ("Backend").

Andere Geräte fragen über das Backend nun regelmäßig die EIGENE UUID gegen diesen Service ab und erhalten eine Rückmeldung. Diese kann entweder Wahr/Falsch oder eine konkrete Handlungsempfehlung beinhalten. Die Ausgabe erfolgt nur nach erfolgreicher AuthZ durch die App und betrachtet zudem nur die Daten, die gemäß RKI-Empfehlung relevant sind (z.B. 14 Tage). Das Backend löscht regelmäßig nicht mehr relevante UUIDs aus dem eigenen Bestand.

Die Nutzung der App als Service hat dabei den Vorteil dass die UUID nur an die App und nicht an das Gerät gebunden ist und bei einer Löschung der App die lokalen und auf dem zentralen Service gespeicherten UUIDs nicht mehr nutzbar sind (Exit-Strategie). Durch das Neugenerieren der UIUID bei erneuter Installation der App wird zudem sichergestellt, dass der Anwender selbstbestimmt an dem Datenaustausch teilnimmt.

Geplanter Informationsaustausch bei Abfragen:

1. UUID lokal generieren
2. Code lokal generieren (oder durch Anwender definieren)
3. UUID und Code an Server melden
4. Server hasht Code ("Hash")
5. Server speichert UUID und Hash
6. weitere Abfragen dann per UUID und Code
7. Server hasht wieder den Code
8. Server vergleicht Hashes und antwortet erst bei übereinstimmung

Ausblick:

• Abfrage von befreundeten/familären UUIDs, wenn die gerätespezifischen Kennwörter bekannt sind
• 2FA zur Meldung einer Infektion

[secradar]

Wenn die einmalig generierte UUID random, unique und genügend lang ist, wozu braucht man dann noch den Code aka Passwort, nur sinnvoll, wenn es jedesmal eingegeben werden muss und nicht abgespeichert werden kann, oder?

[rfuehrer]

Hi @secradar , danke dir für diesen Impulse. Wir haben den Code als zusätzliche Sicherheit einer Brute-force Abfrage vorgesehen, um den Status durch Kenntnis oder Erraten der UUID weiter abzusichern. Wie praktikabel der Ansatz ist, müsste sich in einem Test und bei Beobachtung der UX klären. Ich lasse den Issue und Deinen Impulse für eine Weiterentwicklung offen. Vielen Dank für das Feedback.

---

Hi @secradar , thank you for this impulse. We have provided the code as additional security of a brute-force query to further secure the status by knowing or guessing the UUID. How practicable this approach is, would have to be clarified in a test and by observing the UX. I leave the issue and your impulses for further development open. Thank you very much for the feedback.

[secradar]

which kind of brute-foce should be protected? I can think of at least three:

1. database from server is stolen, attacker uses brute-force to get the real device/app ID
2. attacker pulls/pushes the API brute-forcing the UUID
3. attacker has access to the app (which is only protected by the device's authenticator), and tries to misuse the app with other UUIDs

brute-forcing 2. and 3. is limmited by bandwidth of the connection, at least that of the server if it is a distributed brute-force; I don't yet see how the additional code make this attack harder