Open rfuehrer opened 4 years ago
secradar
commented
4 years ago 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
commented
4 years ago 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
commented
4 years ago which kind of brute-foce should be protected? I can think of at least three:
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
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:
Ausblick: