Kontakt-Tracing-Apps

Die Corona-Warn-App (CWA [1]) wurde von den Unternehmen SAP und Deutsche Telekom AG entwickelt und wird vom Robert Koch-Institut betrieben. Bei der Entwicklung der Corona-Warn-App wurde ein Privacy-first-Ansatz verfolgt, um einen höchstmöglichen Schutz der Nutzerdaten zu erreichen. Alle Daten werden hier zunächst dezentral auf den Smartphones der Nutzer gespeichert und verarbeitet. Personenbezogene Daten wie Name und Telefonnummer werden nicht erhoben und sind für den Betrieb auch nicht notwendig. Die grundsätzliche Funktionsweise des dezentralen Kontakt-Tracings ist in Abb. 1 schematisch dargestellt. Um in eine Location einzuchecken, ist lediglich eine Interaktion mit dem entsprechenden QR-Code notwendig. Alle mit dem Check-in verbundenen Daten verbleiben auf dem Smartphone. Eine regelmäßige Kommunikation mit dem Backend dient lediglich dem Abruf gemeldeter Infektionen, um das eigene Risiko zu berechnen und den Nutzer gegebenenfalls warnen zu können. Eine Profilbildung nicht am Coronavirus infizierter Nutzer durch den Betreiber des Backends oder einen Angreifer ist daher unmöglich. Ebenso erfolgt die Erstellung von Events und Locations clientseitig über die CWA oder ein Webfrontend. Eine zentrale Speicherung von angelegten Veranstaltungen erfolgt nicht. Um die Warnung naher Kontakte zu ermöglichen, ist es jedoch notwendig die Check-in-Daten infizierter Nutzer in das Backend zu übertragen und dort zugänglich zu machen. Bewegungsprofile von infizierten Personen wären also durchaus denkbar. Um die Datensätze auszuwerten und ein Profil zu erstellen, müssten jedoch die IDs und entsprechenden Metadaten der Locations zur Verfügung stehen, welche, wie oben genannt, nicht zentral gespeichert werden. Letztlich müsste eine Sammlung aller QR-Codes erstellt werden, etwa durch manuelles Abfotografieren. Die Erstellung einer solchen Sammlung von QR-Codes ist zwar nicht unmöglich, wäre jedoch mit einem unverhältnismäßig hohen personellen Aufwand verbunden. Um die Profilbildung weiter zu erschweren, werden außerdem vom CWA-Backendsystem falsche Datensätze eingestreut.

Die Luca-App [2] wird von dem Berliner Startup-Unternehmen culture4life GmbH entwickelt und betrieben. Der von der Luca-App verfolgte zentrale Ansatz zum Kontakt-Tracing ist in Abb. 2 schematisch dargestellt. Vor der Nutzung muss sich eine Person durch Angabe der Kontaktdaten registrieren und dabei die Telefonnummer verifizieren. Alle Nutzerdaten werden auf einem zentralen Server gespeichert, um im Falle einer Infektion dem Gesundheitsamt zur Verfügung gestellt zu werden. Die App ruft regelmäßig unter Angabe der eigenen Tracing IDs den Check-in-Status beim zentralen Server ab. Nach einem erfolgreichen Check-in werden die mit den Nutzerdaten verknüpften Check-in-Information verschlüsselt im Backend gespeichert. Im Gegensatz zu der Vielzahl an populärwissenschaftlichen Artikeln, siehe z. B. [3], liegt der Fokus in diesem Artikel auf den technischen Aspekten. Wie in [4] gezeigt, ist es, trotz der Verschlüsselung, aufgrund des regelmäßigen Abrufs des Check-in-Status über die Tracing ID und die Verknüpfung von Check-in und Nutzerdaten für den Betreiber oder einen Angreifer im Backend möglich, Bewegungsprofile einzelner Nutzer zu erstellen. Sollte das Mitlesen des Netzwerkverkehrs bereits bei der Registrierung erfolgen, kann sogar eine Verknüpfung des Bewegungsprofils mit der Telefonnummer des Nutzers erfolgen. Für einen Check-in müssen die notwendigen Location-Informationen beim Luca-Server abgefragt werden. Bedenklich ist, dass der Betreiber des Backends so in Echtzeit die Ankunfts- und Abgangszahlen für jede Location erfassen und auswerten kann. Diese Probleme sind architekturbedingt [4] und bis heute nicht behoben.

Genau wie die CWA bietet die Luca-App ihren Nutzern an, Impfzertifikate zu scannen und zu speichern, um die App so als Zertifikats-Wallet zu nutzen. Während diese hochsensiblen Patientendaten in der CWA jedoch ausschließlich für diesen Zweck auf dem Smartphone verbleiben, nutzen die Luca-Betreiber die personenbezogenen Daten aus dem Zertifikat, um die hinterlegten Nutzerdaten zu validieren, was datenschutzrechtlich äußerst bedenklich ist [5].

Unter einem Fake-Check-in soll hier das Einchecken in eine Location gemeint sein, ohne dass der Nutzer tatsächlich physisch anwesend ist, bzw. ohne dass der hinterlegte Nutzer überhaupt existiert. In der CWA sind Fake-Check-ins einfach möglich. Wie in Abb. 3 dargestellt, reicht es den, eventuell vorab fotografierten, QR-Code der Location zu scannen, eine Anwesenheit vor Ort ist dafür nicht notwendig. Da allerdings alle Daten zunächst auf dem Smartphone gespeichert werden, geht von solchen Check-in-Daten keine direkte Gefahr für das System aus. Diese Check-in-Daten werden nur nach dem anonymen Melden einer Infektion zum CWA-Server übertragen.

Bei einer, auf Check-in basierten, Warnung wird dem Nutzer allerdings angezeigt, durch welchen Check-in die Warnung ausgelöst wurde (siehe Abb. 4). Dadurch ist es für einen Angreifer möglich, durch massenhaftes Einchecken in verschiedene Locations diese zu tracken und festzustellen, wo es zu Infektionen kam.

Die Luca-App versucht durch eine Verifizierung der Telefonnummer eine hohe Datenqualität zu erreichen sowie das massenhafte Anlegen von Fake-Accounts zu verhindern. Da diese Verifizierung allerdings zunächst nur clientseitig auf dem Smartphone erfolgte, konnte sie auf einfachste Weise umgangen werden. Diese Telefonverifizierung findet nach eigenen Angaben mittlerweile serverseitig statt, sodass das Anlegen von Fake-Accounts zumindest erschwert ist. Aufgrund der Verfügbarkeit kostenloser SMS-Dienste und der Tatsache, dass eine Telefonnummer mehrfach zur Registrierung genutzt werden kann, ist das automatisierte Anlegen von Fake-Accounts immer noch sehr einfach möglich. Da das Luca-Backendsystem aufgrund der zweifachen Verschlüsselung der Check-in-Datensätze die Fake-Daten nicht von validen Daten unterscheiden kann, ist hier keine Filterung möglich. Alle Check-ins werden zunächst in der zentralen Datenbank persistiert. So ist es möglich, in großer Menge, Nutzer und Check-in-Datensätze mit beliebigen Namen und Adressen zu erzeugen und im Backend zu hinterlegen. Das Vorgehen ist in Abb. 5 schematisch dargestellt. Dies gefährdet nicht nur die Datenqualität. DDoS-Angriffe auf das zentrale Luca-Backendsystem sind dadurch denkbar, was eine Nutzung des Dienstes für alle Beteiligten unmöglich machen würde. Durch eine große Anzahl von Check-ins mit falschen Daten könnte außerdem die Arbeit der Gesundheitsämter massiv behindert werden. Im Infektionsfall müssten diese alle eingecheckten Nutzer kontaktieren und zunächst die falschen Datensätze von den echten Nutzern trennen, was zu viel Zeit in Anspruch nimmt. Aber auch die Locationbetreiber sind unter Umständen darauf angewiesen, dass das Luca-System ihnen die korrekte Zahl eingecheckter Nutzer anzeigt, um die behördlich angeordneten maximalen Besucherzahlen einhalten zu können.

Ein schwerwiegendes Problem, welches in beiden Systemen besteht, ist, dass durch die Fake-Check-ins Warnungen für andere Nutzer erzeugt werden können. Hierzu ist ein positiver Corona-(Schnell‑)Test notwendig, bzw. muss ein Mitarbeiter der Gesundheitsbehörden durch Social Engineering zumindest überzeugt werden, dass ein solcher positiver Test vorliegt. Im Luca-System kann die Anzahl an Warnungen und Meldungen zumindest noch dadurch eingedämmt werden, dass die Mitarbeiter des Gesundheitsamtes nur epidemiologisch relevante Orte betrachten und nicht alle verfügbaren Daten abrufen. Im CWA-System fehlt diese menschliche Kontrollkomponente. Alle Nutzer, die zeitgleich an derselben Location eingecheckt waren, werden automatisch gewarnt. Wenn man davon ausgeht, dass ein gewarnter Nutzer sich an die Empfehlungen hält, sich also zunächst isoliert und anschließend testen lässt, können durch solche Falschmeldungen gezielt bestimmte Personengruppen zeitweise in die Isolation gezwungen werden. Der einzige effektive Schutz gegen solche Fake-Check-ins durch Sammlungen von QR-Codes ist die regelmäßige Neugenerierung und der Austausch der QR-Codes, was in der Praxis allerdings aufgrund des hohen Aufwands nicht oder zu selten gemacht wird.