08_Corona_Tracking_RSub1_SAVE

Phone based contact tracing

Comment 7

Summary

Idee:

Das Ziel unseres Hackathon-Teams ist es, eine App zu schaffen, die den:die Nutzer:in aktiv über Infektionsfälle in der eigenen Begegnungshistorie informiert und so hilft, alle betroffenen in einer Ansteckungskette frühzeitig und anonym über notwendige Schritte aufzuklären. Die Begegnungshistorie wird lokal (dezentral) und verschlüsselt auf dem Gerät des Nutzers gespeichert. Die Begegnungen werden im Hintergrund über Bluetooth, Wifi und Audio festgestellt. Bemerkenswert ist, dass hierfür keine GPS- oder Lokationsdaten benötigt werden. Dies ist insbesondere im Bezug auf Datenschutz relevant Anhand der eigenen Begegnungshistorie und einer verschlüsselten, zentralen Datenbank kann ermittelt werden, ob der/die Nutzer:in einem inzwischen positiv-getesteten COVID-19 Fall begegnet ist. Die zentrale Datenbank beinhaltet die anonymen IDs der positiven COVID-19 Fälle und wird mit der verschlüsselten Begegnungshistorie des Nutzers abgefragt.

Links:

Pitch Zusammenfassung

Problemstellung

Wie können wir Menschen darüber informieren, dass sie eine Begegnung (von relevanter Dauer und Nähe) mit einem COVID-19-Fall hatten?

Lösung

Eine App, die Nutzer aktiv über Infektionsfälle in der eigenen Begegnungshistorie informiert.

Umsetzung

Anonyme und verschlüsselte Aufzeichnung der Begegnungen mit anderen Personen. Ermittlung eines Gefährdungsstatuses durch Abgleich der Begegnungen mit bestätigten COVID-19-Fällen

Mehrwert

Nachvollziehbarer Gefährdungsstatus

  • Ich als Bürger möchte erfahren, ob ich mit einem bestätigten COVID-19-Fall näheren Kontakt hatte.

Situationsgerechte Verhaltensempfehlung

  • Ich als Bürger möchte erfahren, wie ich mich angesichts meines Gefährdungsstatuses verhalten soll.

Anonyme Informationsverteilung

  • Ich als COVID-19-Fall möchte meine vergangenen Begegnungen (auch Fremde) anonym informieren.

Faktenbasierte Entscheidungshilfen

  • Wir als gesundheitliche Institutionen möchten individuelles Verhalten empfehlen können und dadurch entlastet werden.
  • Wir als gesundheitliche Ämter wollen Tests nicht nur anhand von Symptomen durchführen, sondern auch anhand von präzisen Ansteckungsketten genauer priorisieren können.

Projektstatus

  • Android-/iOS-App in Arbeit
  • Anonymer Schlüsselaustausch prototypisch umgesetzt
  • Prototyp: Backend (+ Sicherheitskonzept)

Ausblick

  • Zusammenarbeit mit Kooperationspartnern
  • Distanzhaltung durch Benachrichtigung
  • Risikogebiete in Kartenform

Wir bedanken uns ganz herzlich bei:

  • dem #WirVsVirusHack-Team
  • Alexandru Petrescu
  • Dominik Heller
  • Brigitte Strahlwald
  • Andreas Gebhard
  • Thorben Schulte
  • Oksana

Szenario:

Ein:e Nutzer:in hat bereits seit drei Wochen die App im Einsatz und protokolliert somit dessen:deren Begegnungen. Sollte eine Person positiv auf COVID-19 getestet werden, kann sie das über die App melden. Betroffenen Nutzer:innen wird daraufhin eine Risikomeldung angezeigt. Ob die Begegnung eine Risikomeldung auslöst hängt von der kumulativen Dauer, sowie der Distanz der Begegnung ab. So ist der:die Nutzer:in über seine:ihre COVID-19 Exposition informiert und der:die Angesteckte hat anonym alle (in der App aktiven) möglichen Kontaktpersonen informiert.

Technischer Stand des Prototyps

iOS App Github: RSub1-iOS-Swift

Die iOS App hat zur Zeit der Einreichung des Devposts eine Startseite, die einen Aktivieren-Button beinhaltet. Bei der Auswahl des Aktivieren-Buttons wird die “Nearby Messages API” zum Austausch der Schlüssel gestartet. Eine Kommunikation mit einer anderen Apps (iOS/Android) wurde bereits getestet. Die Funktionalität kann auch im Hintergrund gewährleistet werden, wie das PoC-Repo beweist. Perspektivisch wird das PoC-Repo (entwickelt in Objective-C) in das Haupt-Repo (entwickelt in Swift) migriert.

Database Backend GitHub: rsubone-backend

Das Backend ist eine einfache nodeJS REST-API, mit einer hintergelagerten mongoDB. Das Backend erlaubt:

  • Das Erstellen neuer User
  • Das Abfragen von dem eigenen Risikos einer Infektion
  • Das Aktualisieren des Infektionsstatus eines Users
  • Die Anfrage des RSA-Public-Keys zum anonymisieren des eigenen Identifikators

Android UI Github: RSub1-Android

In diesem Repository ist die Android UI gemäß den Mockups implementiert. Hier fehlen jedoch noch die funktionalen Oberflächen und die Anbindung an das Backend/Nearby Message API (siehe anderes Android Schnittstelle)

Android Schnittstelle Github: rsub1-android-backend

Dieses Teilprojekt implementiert die Kommunikation mit dem Backend und die Nutzung der Nearby Messages API. Dazu wurden unterschiedliche Klassen implementiert, die das beschriebene Szenario abbilden und einfach in die UI eingebettet werden können.

Sicherheitskonzept

Allgemein

Im folgenden Abschnitt machen wir uns Gedanken wie unsere Lösung sowohl konzeptionell als auch technisch angreifbar ist.

Ein Vorbehalt, den man gegenüber dem System haben könnte ist, eine Datenkrake zu sein. Hierbei könnte man sich auf unnötige Datensammlung, Zweckentfremdung der Daten beziehen. Auch könnte man den Vorbehalt haben, das Informationssystem für Bürger sei tatsächlich als Auswertungstool für Institute gedacht ist.

Das Ziel von SAVE ist, technisch sicherzustellen, dass das Informationssystem im Vordergrund steht. Hierfür wird eine dezentrale Datenspeicherung der Begegnungen angestrebt. Auch ist das Ziel so wenig Daten wie möglich zentral speichern zu müssen. Mehr dazu im Kapitel “Dezentrale Datenhaltung”.

Ein weiterer Angriffspunkt könnte der Missbrauch des Meldesystems sein. Sollte es ein Meldungssystem geben, welches die Nutzer dazu auffordert sich selbst als COVID-19-Fall einzustufen, könnte diese Funktionalität missbraucht werden indem die man sich selbst fälschlicherweises als positiv getestet meldet. Diesem Missbrauch kann nur entgegengewirkt werden, indem eine offizielle Institution die Bestätigung der positiv-getesteten Nutzer übernimmt und dazu autorisiert ist. Hierbei sind gesundheitliche Institutionen oder Behörden für eine Ansiedlung dieser Verwaltung zu betrachten.

Allgemein ist es ein großes Anliegen Datendiebstahl zu verhindern UND im Falle eine Datendiebstahls so wenig schützenswerte Daten wie möglich preiszugeben. Durch ein Anonymisierungs- und Verschlüsselungskonzept wollen wir diese Sicherheitsrisiken angehen. Die Anonymisierung geschieht durch Generierung eines persönlichen Identifikators, welcher durch das Verschlüsselungskonzept nicht auf die eigentliche Person zurückschließen lässt. Hierbei wird bei jedem Schlüsselaustausch ein anderer Schlüssel ausgetauscht. Mehr dazu im Anonymisierungskonzept. Zudem werden grundsätzlich keine personenbezogenen Daten erfasst. Die einzige persönliche Information ist die (ebenfalls anonymisierte) Covid-19-Positiv-Meldung. Direkt nach dieser Meldung werden alle erfassten Daten vom Telefon gelöscht.

Dezentrale Datenhaltung

Ziel der dezentralen Datenhaltung ist es, so wenig Daten wie irgend möglich in einer Datenbank zu persistieren. Bei der dezentralen Datenhaltung wird lediglich eine ID, ein Infektionsstatus, sowie das Datum der gemeldeten Infektion gespeichert.

Auf Persistence-Ebene gibt es keine logische Verbindung von einer ID zu einer spezifischen Person und auch keine Relationen von IDs untereinander. Begegnungen werden somit nicht zentral persistiert. Die Clients speichern hingegen die anonymisierten IDs ihrer Begegnungen (siehe Anonymisierungskonzept) und senden diese an das Backend. Dieses prüft lediglich gegen, ob in der Kontaktliste ein bestätigter Fall ist.

Verschlüsselungs- und Anonymisierungskonzept

Encryption Visualisierung

Das Backend enthält ein private/public Key Pair zur asymmetrischen Verschlüsselung. Der public Key kann für alle zugänglich sein und wird zum verschlüsseln verwendet. Nur der private Key kann eine Nachricht entschlüsseln, die mit einem zugehörigen public Key verschlüsselt wurde. Es ist nicht ohne weiteres möglich, von einem public Key auf einen private Key zu schließen, sofern diese stark sind (empfohlen sind Keys einer Länge von 4096 Bytes). (Für mehr Details informieren Sie sich bitte über die Grundlagen asymmetrischer Verschlüsselung)

Ein Endpoint stellt den public Key bereit, sodass jeder Client seine persönlichen Identifikator (ID) verschlüsseln kann. Beim Verschlüsseln der ID mit dem public Key wird ein Salt verwendet, der bei jedem Verschlüsselungsvorgang einen anderen Ciphertext erzeugt. Am Beispiel:

  • Man hat einen private/public Key Xpriv/Xpub mit einem Salt und zu schützende Daten d.
  • Verschlüsselt man d mit Xpub erhält man Chiffre c1
  • Verschlüsselt man d erneut mit Xpub, erhält man eine Chiffre c2
  • usw, usw
  • c1, c2, (usw c…) sind jedoch nicht äquivalent.
  • Entschlüsselt man die verschiedenen Chiffren mit dem Xpriv erhält man jedoch immer wieder die ursprünglichen, zu schützenden Daten d.

Die ursprüngliche ID ist somit nur dem Nutzer und dem Backend bekannt. Die Nutzer sammeln somit nicht die konkreten IDs der Begegnungen, sondern nur Daten, die der Server interpretieren kann. Dies bietet folgende Vorteile:

  • Die verschlüsselten IDs können nicht deanonymisiert werden.
  • Sollte ein Unbefugter Zugriff auf eine Kontaktliste bekommen, oder man gleicht untereinander die Daten ab, kann man die verschlüsselten IDs aus der Begegnungshistorie nicht zuordnen.
  • Somit ist eine Katalogisierung und ein Missbrauch der Begegnungsdaten nicht möglich. Auch man selbst kann aus den Daten nicht nachvollziehen, ob man einer Person mehrfach begegnet ist.

Zu lösendes Datenschutzproblem:

Es ist mit dem aktuellen Konzept technisch möglich auszulesen, welche Person erkrankt ist. Hierbei ist zwar eine Verzögerung der Informationsgewinnung von 1-2 Wochen zu erwarten, jedoch datenschutz-technisch nicht vertretbar. Szenario: Eve trifft Bob im Bus und speichert sich seine ID, da niemand sonst in der Nähe ist. Somit kann Eve eine Relation zu Bob herstellen. Sollte Bob positiv getestet werden, kann es Eve durch eine Abfrage am Backend herausfinden.

  • Proaktive jedoch anonyme Inkenntnissetzung der Nutzer durch den COVID-19-Fall
  • COVID-19-Fall kann aus seiner Begegnungshistorie Begegnungen
  • Idee auf Kosten der Funktionalität: Mindestens 2 Begegnungen mit Positiv-Fällen wären nötig um eine Gefährdungswarnung vom Backend zu erhalten

Built With

+ 10 more
Share this project:

Updates