Prof. Ahmad-Reza Sadeghi hat dem Darmstädter Echo in einem Interview ein Update zum TraceCORONA-Projekt gegeben.
Im Artikel „Auf taube Ohren gestoßen“ (Darmstädter Echo, 02.07.2021) kritisiert Prof. Sadeghi zunächst das Vorgehen bei der Entwicklung der Corona-Warn-App: Anstatt auf Innovationen und Start-ups zu setzen, kamen bei der Entwicklung der Corona-Warn-App Google und Apple zum Zuge. Für beide Unternehmen seien Daten wichtiger als Gold, wird Sadeghi zititert. Ebenfalls enttäuschend ist, dass die TraceCORONA-App seitens der Politik keine Aufmerksamkeit bekommen hat, obwohl die an der TU Darmstadt entwickelte App vor der Corona-Warn-App einsatzfähig war.
Neben seiner Kritik stehen aktuelle Entwicklungen wie die Implementierung der TraceCORONA-App auf Smartwatches und Fitnesstrackern und deren Einsatzmöglichkeiten im Vordergrund. Mit der App auf den sogenannten „Wearables“ könnten auch Menschen ohne Smartphones erreicht werden. Meist am Körper getragen, kann die Smartband-Anwendung anonymisierte Daten wie den Puls u.ä. sammeln und damit z.B. die Behandlung unterstützen. An die App soll eine digitale Plattform angeschlossen sein, auf der entsprechende Adressaten wie etwa Ärzt:innen die Daten auswerten und für die weitere Behandlung nutzen können.
Diese Plattform würde Prof. Sadeghi gern auf das gesamte Gesundheitssystem ausweiten. Damit könnte es zum Beispiel einen direkten Austausch zu Symptomen mit Ärzt:innen geben oder ein sicherer Austausch von Gesundheitsdaten zwischen Apotheken, Krankenhäusern und Ärzt:innen stattfinden. Und das alles anonym und datenschutzkonform.
Da nun die Impfkampagnen weltweit an Fahrt gewinnen, wächst auch der Bedarf und das Interesse an digitalen Lösungen zum Nachweisen des Impfstatus. Auch wir sind gerade dabei, unseren eigenen sicheren Prototyp für einen Impfpass zu entwickeln, mit besonderem Fokus auf leichte Handhabung für alle Benutzertypen jeden Alters. Insbesondere die Integration in tragbare Geräte wie Smartwatches ermöglicht den Einsatz in den unterschiedlichsten Szenarien, in denen die Nutzung eines Smartphones umständlich oder unerwünscht sein kann. Auch die Erreichbarkeit von Benutzergruppen, die den Umgang mit einem Smartphone nicht gewohnt sind (z. B. ältere Menschen), wird durch diese Lösung verbessert.
Die Corona-Warn-App nutzt zur Kontaktverfolgung das Exposure Notification Framework von Google und Apple, das die beiden Unternehmen in iOS und Android implementiert haben. Um die Privatsphäre zu gewährleisten, können Apps nicht auf die gesendeten und empfangenen IDs für die Kontaktverfolgung zugreifen. Google schreibt jedoch genau diese IDs unter Android in eine Log-Datei, auf die System-Apps zugreifen können. Das Problem wurde Google gemeldet, aber innerhalb von 60 Tagen nicht behoben.
Lesen Sie hier im sehr informativen Tweet von Serge Egelman mehr über die Gefahren, über die wir schon lange sprechen.
Das Projekt „Sichere und die Privatheit schützende Pandemie-Verfolgungsplattform“ wurde von der Europäischen Union aus dem Europäischen Fonds für regionale Entwicklung kofinanziert.
Das Forschungsteam des System Security Labs forscht an vielen Themen aus dem Bereich der IT-Sicherheit und Privatheit, insbesondere an Themen, die Bürgerinnen und Bürger betreffen. Seit Januar 2020 beschäftigen wir uns mit den Sicherheits- und Privatheits-Aspekten der sogenannten Corona-Apps weltweit und insbesondere mit der Corona-Warn-App (CWA).
Tägliche Anzahl der an das RKI gemeldeten Infektionen, einschließlich des Anteils, der innerhalb der CWA geteilt wurde. Für den 24. Dezember und den 31. Dezember 2020 wurden keine Daten veröffentlicht
Unser Team hat weitere Daten zur Nutzung der Corona-Warn-App gesammelt und die neuen Feldversuche bestätigen erneut die Sicherheits- und Datenschutzlücken. Die Ergebnisse zeigen, dass auch die bisher theoretischen Forschungsansätze zu verschiedenen Sicherheitslücken der Corona-Warn-App unter realistischen Bedingungen in die „freie Wildbahn“ übertragen werden konnten. Dabei ist der Versuchsaufbau verhältnismäßig simpel: Handelsübliche und günstige ESP32 Microcontroller, die mit Bluetooth und Wi-Fi-ausgestattet sind, wurden von den Studierenden zu sogenannten „Sniffern“ umgebaut.
Die batteriebetriebenen Sensoren wurden wetterfest in der Darmstädter Innenstadt und Umgebung, an ausgewählten Orten (z.B. an Verkehrsknotenpunkten, in Parks und in Supermärkten) platziert. Mehrere Wochen sammelten die Sensoren verschiedene Daten: MAC-Adressen und Rolling Proximity Identifier, kurz RPI, die von der Corona-Warn-App via Bluetooth Low Energy gesendeten Zufalls-IDs. Darüber hinaus wurden die dazugehörigen Zeiten gesammelt.
Mehr als Theorie – Bewegungsprofile in „freier Wildbahn“
Mehr als 21.000 gesammelte MAC-Adressen ließen Rückschlüsse auf die Corona-Warn-App „Hotspots“ in Darmstadt zu wie die Heatmap verdeutlicht.
Heatmap der „Hotspots“ in Darmstadt
Durch die Analyse der an den verschiedenen Orten gesammelten Daten konnte die Erstellung von Bewegungsprofilen infizierter Nutzer:innen der Corona-Warn-App in „freier Wildbahn“ erprobt und nachgewiesen werden. Die installierten Sensoren erfassten alle RPIs, die an ihnen vorbeikamen und versahen diese mit dem dazugehörigen Zeitstempel. Während des Experiments zwischen Mitte Dezember 2020 und Anfang März 2021 wurden über 97.000 einzigartige RPIs gesammelt.
Zur Auswertung dieser eindeutigen RPIs wurden zudem die Temporary Exposure Keys (TEK), die sogenannten Tagesschlüssel, die das Smartphone alle 24 Stunden generiert, herangezogen. Mittels kryptografischer Algorithmen und verschiedener Berechnungen konnte ausgehend von insgesamt 17 Temporary Exposure Key (TEK), die aufgrund eines positiven Testergebnisses auf den Corona-Warn-App-Server hochgeladen wurden, einige der gesammelten RPIs exakt zugeordnet werden. Obwohl es sich hierbei um eine kryptografische Einweg-Funktion handelt, könnten mit genügend „Sniffing“-Sensoren, die zusätzlich die Ortsdaten enthalten, Bewegungsprofile infizierter Corona-Warn-App-Nutzer:innen erstellt werden. Darüber hinaus ließen die gesammelten Daten Rückschlüsse auf das genutzte Endgerät und dessen Betriebssystem zu.
RPIs verlinken – Bewegungen verfolgen
Ein weiterer Feldversuch demonstrierte, dass die Corona-Warn-App auch „in freier Wildbahn“ für die im Juli 2020 zur SwissCovid-App veröffentlichte „Little Thumb Attack“ anfällig ist. Die Schweizer Wissenschaftler haben nachgewiesen, dass Benutzer:innen der SwissCovid-App zurückverfolgt werden können, wenn sich die MAC-Adresse und der RPI nicht gleichzeitig aktualisieren, sondern zeitversetzt. Diese Überschneidungen in der Aktualisierung führt zu sogenannten „Pebbles“, d.h. fehlerhaften Bluetooth-Nachrichten, die eine Verlinkung der RPIs der Nutzer:innen über einen gewissen Zeitraum ermöglichen. Solche „Pebbels“ konnten in unserem Feldversuch nachgewiesen werden. Es ist gelungen einige Nutzer:innen durch einen solchen Pebble über zwei Sensoren hinweg nachzuverfolgen. Dies war nur möglich, da es diese Schwachstelle in der Exposure Notification Schnittstelle von Google und Apple (GAEN genannt) gibt, obwohl sie nicht existieren sollte.
Ändern sich MAC-Adresse und RPI synchron, ist keine Verknüpfung der Daten möglich. Über sogenannte Callbacks, d.h. über das Betriebssystem wird der Corona-Warn-App mitgeteilt, dass sich die MAC-Adresse geändert hat, so dass sich auch der RPI aktualisieren kann, wird eine synchrone Änderung gewährleistet. Anhand der erfassten Daten scheint es, dass dies in verschiedenen Geräten unterschiedlich implementiert wird, daher sind nicht alle Smartphones gleich stark betroffen. Während es bei iOS-Betriebssystemen einen Callback gibt, hatten neun von zehn parallel getesteten Android-Geräten keine solche Rückversicherung. Auch wenn die im Labor getesteten Android-Geräte keine vollständigen „Pebbels“ generieren konnten, wurden „Teil-Pebbels“, sogenannte „Overlaps“ aufgezeichnet.
Kaum Schutz vor Sicherheitslücken
Über diese Schwachstellen konnten Bewegungsprofile infizierter Nutzer:innen z.B. im Supermarkt für eine bestimmte Zeit identifiziert werden. Trotz vieler Updates ist es Google und Apple bisher noch nicht gelungen, die Schwachstellen endgültig zu beseitigen.
Um den Einzelhandel, die Gastronomie oder auch Kultureinrichtungen und Künstler:innen zu unterstützen und den Menschen Besuche zu ermöglichen, sind die sogenannten Check-in-Apps besonders die Luca-App derzeit in aller Munde. Wir begrüßen diesen Trend.
Gleichzeitig haben wir seit Mai 2020 immer wieder gerade lokale Lösungen thematisiert – auch in den Medien. Wir finden lokale Lösungen deutlich effektiver als nationale Lösungen wie etwa die Corona-Warn-App, die keine Effektivität aufweisen. Unser Forschungsteam beschäftigt sich bereits seit Januar 2020 mit digitalen Kontaktnachverfolgungssystemen.
Wie üblich analysieren wir alle populären Systeme, denn auch diese haben ihre Tücken. Wir haben uns im ersten Schritt die Luca-App genauer angesehen. Uns ging es dabei in erster Linie um die Unsicherheiten und Datenschutzprobleme der Check-in-App.
Wir sind dabei auch die anderen Check-in-Apps weiter und tiefergehend zu analysieren und auf diese Systeme einzugehen. Dazu werden weitere Untersuchungsergebnisse folgen.
Im Folgenden finden Sie unsere ersten Analyseergebnisse zur Luca-App.
Einsatz der Check-in Apps im Indoor-Bereich zur Kontaktnachverfolgung
Geschäfte, Dienstleister (z.B. Gastronomen, Veranstalter) oder öffentliche Eirichtungen (z.B. Museen) können unter bestimmten pandemiebezogenen Einschränkungen Kunden ihre Dienste anbieten. Typischerweise müssen die Gäste bei einem Besuch ihre Kontaktdaten in Papierformulare eintragen, wobei gleichzeitig das Ausfüllen und Sammeln umständlich und fehleranfällig ist. Digitale Apps oder Online-Dienste können hier helfen. Mit solchen Check-in Apps „checken“ die Gäste ein, um Informationen zu ihrem Besuch und Kontaktdaten zu hinterlegen. Sollte sich im Nachhinein ein Gast mit dem Coronavirus infizieren, können die gespeicherten Informationen zur Kontaktverfolgung der anderen Gäste genutzt werden.
Es existieren bereits eine Reihe mobiler Apps oder Web-basierte Check-in Apps wie Gastident, eGuest, Kontakterfassung.de, Smartmeeting, darfichrein.de und die Luca-App. Im Folgenden konzentrieren wir uns jedoch auf die Luca-App, die seit kurzem öffentliche Aufmerksamkeit genießt und lokal wie kommunal bereits eingesetzt wird.
Photo by Proxyclick Visitor Management on Unsplash
Die Luca-App
Die Luca-App, intensiv vom deutschen Rapper Smudo der Fantastischen Vier vermarket, wird als einfache und datenschutzfreundliche Alternative zum Ausfüllen von Formularen oder zur Übermittlung von Daten im Klartext an eine Website beworben.
Wir haben erste Sicherheits- und Datenschutzanalysen der Luca-App durchgeführt und diskutieren hier die ersten Zwischenergebnisse.
Wie funktioniert die Luca-App
Bei der Luca-App gibt es vier Hauptakteure: Der Gast, der Dienstleister, das Gesundheitsamt und der Luca-Service-Betreiber. Im einfachsten und häufigsten Szenario wird die Luca-App wie folgt eingesetzt:
Der Dienstleister registriert sich beim Luca-Server und generiert einen QR-Code, der seine URL und ID enthält.
Der Gast muss sich ebenfalls beim Luca-Server registrieren, indem er seine Kontaktdaten wie Telefonnummer, Name und Adresse angibt. Die Kontaktdaten werden gesichert an den Luca-Server gesendet und verschlüsselt gespeichert.
Der Gast betritt z.B. das Lokal und scannt den ausgedruckten QR-Code, der in der Regel am Eingang angebracht ist. Durch das Scannen wird ein Check-in für diesen Gast erstellt, der gesichert an den Luca-Server gesendet wird.
Wird ein Gast positiv getestet, gibt der Gast quasi seine Geheimnisse (kryptografische Schlüssel) an die Gesundheitsbehörde frei.
Die Gesundheitsbehörde fragt den Luca-Server nach allen Check-ins dieses Gastes ab. Anhand dieser Check-ins fragt die Gesundheitsbehörde nun alle Dienstleister ab, bei denen einer dieser Check-ins durchgeführt wurde, und erhält die notwendigen Informationen, um mögliche Kontaktpersonen zu identifizieren.
Einige Unsicherheitsaspekte der Luca-App
Das Hauptziel der App ist, dass kein Akteur allein auf die Kontaktdaten des Gastes zugreifen kann, ohne dass dieser 1) infiziert ist und seine Schlüssel freigibt oder 2) in einem Suchprozess auftaucht. Damit dies geschehen kann, müssen der Betreiber des Veranstaltungsorts und das Gesundheitsamt zusammenarbeiten. Außerdem muss ein Gast seine Schlüssel freigeben, um den Prozess zu starten. Außerdem können Check-ins nicht miteinander und auch nicht mit einem Gast verknüpft werden, wenn sie verschlüsselt sind. Durch die Verwendung von Metadaten, wie z. B. der IP des Gastes, ist es jedoch dem Luca-Service-Operator möglich, Check-ins mit IP-Adressen zu verknüpfen (https://luca-app.de/securityconcept/processes/guest_app_checkin.html#id4). Diese Möglichkeit wird von Luca-Team eingeräumt. Um dies abzumildern, versprechen sie, keine IP-Adressen zu protokollieren.
Das Luca-Team verspricht zudem, eine Reihe von definierten Sicherheitszielen (https://luca-app.de/securityconcept/properties/objectives.html#objective-contact-data) in Bezug auf bestimmte Akteure in ihrem System zu erfüllen. Die Webseite der Luca-App weist jedoch auf mögliche Sicherheitsprobleme hin, ohne die Konsequenzen genauer zu beschreiben.
Ein wichtiges Ziel hierbei ist, dass „die Kontaktdaten nicht-infizierter Gäste nur ihrer eigenen App bekannt sind“. Das wiederum impliziert, dass die Luca-App die angegebenen persönlichen Daten nicht validieren kann, obwohl die Gesundheitsbehörden auf gültige Kontaktdaten angewiesen sind. Um dieses Problem zu entschärfen, bietet die Luca-App eine „Trade-off“-Lösung in Form einer clientseitigen SMS-Verifizierung der Telefonnummer, die der Gast bei der Registrierung eingibt (https://luca-app.de/securityconcept/processes/guest_registration.html#verification-of-the-guest-s-contact-data).
Diese Lösung hat jedoch ein Problem, da der Verifizierungsprozess missbraucht werden kann, indem eine unbegrenzte Anzahl von Konten mit einer einzigen gültigen Telefonnummer registriert wird. Denn es gibt keine inhärent überprüfbare Verbindung zwischen den angegebenen Kontaktdaten und der Telefonnummer, die für die Registrierung der App verwendet wird.
Neben der Smartphone-basierten App-Lösung bietet Luca auch eine webbasierte Lösung (Web-App) für Situationen an, in denen der Gast kein eigenes Smartphone nutzen kann oder möchte. Auch diese Lösung zeigt Probleme im Hinblick auf die Überprüfbarkeit der angegebenen Kontaktdaten. Denn in der Luca-Web-App ist es möglich, durch eine relativ einfache Modifikation des Webseiten-Quellcodes auf der Client-Seite die SMS-basierte Verifizierung ganz zu überspringen.
Abgesehen von den Problemen mit der Verifizierbarkeit der Kontaktdaten, sind auch die gesammelten Check-in-Informationen einem potentiellen Missbrauch ausgesetzt. Das liegt daran, dass Luca mehrere Möglichkeiten bietet, einen Check-in durchzuführen. Die einfachste Möglichkeit ist, dass der Dienstanbieter einen gedruckten QR-Code bereithält, den der Gast scannen kann. Diese sogenannten „statischen“ QR-Codes laufen nicht ab und kodieren eine URL, um sich mit der App am Dienstanbieterort anzumelden. Statische QR-Codes sind relativ einfach zu kopieren und zu vervielfältigen, was auch dem Luca Entwicklungsteam bekannt ist, wie sie erklären: „Von Natur aus sind QR-Codes leicht zu fälschen, indem man sie einfach kopiert […] es liegt am Dienstanbieter, sicherzustellen, dass gedruckte QR-Codes nicht physisch ersetzt werden.“ (https://luca-app.de/securityconcept/processes/guest_self_checkin.html#authenticity-of-printed-qr-codes)
Ein weiterer Missbrauch ist, dass QR-Codes einfach gescannt werden können und die URL für Remote-Check-ins verwendet werden kann, ohne dass der Gast am Ort des Lokals physisch anwesend sein muss.
Wie bereits erwähnt, wird die Luca-App als digitaler Ersatz für das Ausfüllen eines physischen Kontaktinformationsformulars auf Papier vermarktet. Dementsprechend erwarten die Gäste, dass für diese Lösung ähnliche „Sicherheitsannahmen“ gelten. In der Praxis können die oben erwähnten Probleme im Aufbau von Luca jedoch zu einer Reihe von neuen Angriffsszenarien führen, die eine Manipulation des Gesamtsystems zur Folge haben können.
Im Folgenden beschreiben wir zwei Angriffe: „Generierung falscher Kontakte“ und „Framing von Gästen“ (jemanden etwas anhängen).
Generierung falscher Kontakte:
Es kann gezeigt werden, dass ein Angreifer die Luca-Web-App nutzen kann, um eine beliebige Anzahl „falscher“ Gäste zu registrieren. Das liegt an den bereits erwähnten Problemen mit der SMS-Verifizierung.
Anschließend kann der Angreifer z.B. durch die Stadt streifen und die am Eingang oder an den Tischen üblichen QR-Codes der Lokale scannen und die darin enthaltenen URLs sammeln, die zum Einchecken verwendet werden.
Sobald eine ausreichende Anzahl dieser extrahierten URLs gesammelt wurde, werden diese verwendet, um automatisiert Check-ins für alle „falschen“ Gäste an jedem Veranstaltungsort zu erstellen und zwar mehrmals an verschiedenen Tagen. Um solche Angriffe vor den Augen möglicher menschlicher Prüfer besser zu verschleiern, können diese Check-ins in Bezug auf ihre Dauer und die Anzahl der eincheckenden „Gäste“ randomisiert werden.
Folge: Sobald gemeldet wird, dass eines der avisierten Lokale von einem infizierten Gast besucht worden ist, erhalten die Gesundheitsbehörden Zugriff auf entsprechende Check-in-Kontaktdaten, die auch die „gefälschten“ Gäste-Check-ins enthalten. Dies kann zu einem großen Reputationsproblem des Lokals führen, da für die Gesundheitsbehörden der Anschein erweckt wird, dass viel mehr Gäste das Lokal besucht haben, als es z. B. die Vorschriften zulassen würden. Außerdem würde dies eine hohe Arbeitsbelastung für die manuelle Kontaktverfolgung der Gesundheitsämter bedeuten, da sie viel Zeit aufwenden müssten, um „falsche“ Gäste zu kontaktieren. Erfolgreiche Angriffe könnten möglicherweise auch zu falschen Verbreitungszahlen in der Statistik führen.
Einen solchen, auf physischen Kontaktformulare basierenden Angriff durchzuführen, wäre sehr umständlich und erfordert viele Ressourcen. Durch die Nutzung der Luca-App könnten solche Angriffe leicht automatisiert werden.
Framing von Gästen:
Der zweite Angriff betrifft eine bestimmte Person, wir nennen ihn „Framing von Gästen„.
Der Angreifer beginnt mit der Erstellung eines gefälschten Kontos unter Verwendung der Kontaktdaten seines Opfers.
Wie im vorherigen Angriffsszenario beschrieben, kann der Angreifer dann in einem Zielgebiet umherziehen und Login-URLs sammeln, die aus den QR-Codes von Veranstaltungsorten extrahiert wurden.
Anschließend kann der Angreifer für das gefälschte Konto, das die Kontaktdaten des Opfers enthält, Check-ins in allen vermeintlich besuchten Geschäften erstellen.
Folge: Sobald eines dieser Lokale einen infizierten Gast meldet, würde unser avisiertes Opfer vom entsprechenden Gesundheitsamt kontaktiert werden. Das kann dazu führen, dass das Opfer selbst fälschlicherweise in Quarantäne muss, oder dass der Prozess der Kontaktsuche der Gesundheitsbehörden unnötig komplizierter wird.
Wenn in den Medien weit verbreitete Berichte über eine falsche Verteilung oder unnötige Infektionsmeldungen erscheinen, kann dies außerdem dazu führen, dass das Vertrauen in die Ermittlung von Kontaktpersonen in den Augen der Öffentlichkeit insgesamt sinkt.
Einige Datenschutzprobleme der Luca-App
Im Hinblick auf Datenschutzaspekte lassen sich u.a. folgende Beispiele erkennen:
Der Luca-Server kann aus der Zählung der Check-ins ableiten, wie viele Gäste am entsprechenden Ort eingecheckt haben.
Der Luca-Server kann die IP-Adresse und Telefonnummer bei der Registrierung eines Gastes (während der SMS-Verifizierung) sowie die IP-Adresse und die Uhrzeit bei jedem Check-in aufzeichnen und zu den Pseudonymen infizierter Gäste zuzuordnen, um diese zu de-anonymisieren. Dies ist möglich, da der Server Zugriff auf die Check-in-Historie von infizierten Gästen erhält, einschließlich der Pseudonyme von Gästen, die zur gleichen Zeit die Veranstaltungsorte besuchen (d. h. die möglichen Kontaktpersonen).
Verknüpfung der Check-ins von Gäste-Gruppen durch Metadaten (z. B. IP und Zeit).
Die Ursachen dieser Probleme liegt im Systementwurf z.B., dass die Daten von einem Server gesammelt werden. Auch wenn diese verschlüsselt sind, gibt es notwendige Metadaten, die wiederum Verknüpfungsinformationen liefern. Also, die zugrundeliegende Annahme ist, dass der Luca-Server kompromittiert werden kann oder böswillig ist. Diese Informationsverknüpfungen sind jedoch systeminhärent und stellen somit keine Überraschung dar.
Sicherlich ist es wichtig, dass die Privatsphäre der Gäste unter Berücksichtigung angemessener Datenschutzanforderungen gewährleistet wird. In einer Krisensituation, wie einer Pandemie, brauchen wir jedoch einen sinnvollen Kompromiss zwischen Sicherheit, Privatsphäre und Effektivität. Metadaten können im Allgemeinen mit Hilfe intelligenter Datenverarbeitung miteinander verknüpft werden. Allerdings können diese Gefahren durch eine genaue und durchdachte Risiko- und Bedrohungsanalyse minimiert werden, damit Digitaltechnologien effektiv gegen Pandemie in der Praxis eingesetzt werden können. Das kann wiederum bedeuten, dass der Gast in bestimmten Fällen einige Metadaten über sich (z.B. beim Einchecken in ein Lokal) offenbaren sollte.
Wir hören immer wieder das Argument, dass der Datenschutz die Effektivität eines digitalen Kontaktnachverfolgungssystems verschlechtert. Beispielsweise sei dies der Grund für die Ineffektivität der Corona-Warn-App (CWA): Wenn der Datenschutz teilweise aufgehoben wird, dann kann man eine zentralisierte Lösung einsetzten, die nützliche Informationen über die Entwicklung der Pandemie liefern kann. Aus unserer Sicht jedoch ist der Datenschutz kein Hindernis, sondern eine essentielle Funktion in einer demokratischen Informationsgesellschaft. Eine datenschützende und effektive Digitaltechnologie für Kontaktnachverfolgung benötigt deshalb eine datenschützende Infrastruktur, wobei die App nur eine Komponente davon ist. Eine solche Infrastruktur fehlt im Fall der Corona-Warn-App komplett.
Bisher wurde Corona-Warn-App (CWA) von vielen Wissenschaftler:innen kritisiert. Beanstandet wurden mangelnde Sicherheit und Privatheit sowie die Tatsache, dass die genutzte Kerntechnologie für die Nachverfolgung von Google und Apple stammt, die nun offiziell mehr Daten sammeln können, da die Corona-Warn-App in Deutschland von der Politik unterstützt wird. Daher ist die Aussage, dass die Ineffektivität der Corona-Warn-App am Datenschutz läge fraglich. Gleichzeitig sind Kompromisse nötig.
Autoren: André Davidoff, TU Darmstadt Richard Mitev, TU Darmstadt Thien Nguyen, TU Darmstadt Ahmad-Reza Sadeghi, TU Darmstadt
Ein Update des Berichts "Sinn und Unsinn der Corona-Warn-App"
Die Coronavirus-Pandemie hat die Welt seit Monaten im Griff. Die Zahl der Infektionen steigt und die zweite Welle, sie rollt. Dies macht eine zuverlässige und effiziente Kontaktverfolgung notwendiger denn je. In vielen Ländern wurden bereits digitale Apps zur Kontaktverfolgung eingeführt, um die manuelle Kontaktverfolgung zu unterstützen und damit Infektionsketten zu unterbrechen sowie die weitere Ausbreitung des Virus einzudämmen. Je nachdem wie wichtig die Privatsphäre sowie der Datenschutz in den einzelnen Ländern sind, kommen dabei unterschiedliche Ansätze zum Tragen. Diese lassen sich in zwei Kategorien einteilen: ein zentrales oder dezentrales Kontaktverfolgungs-system. Dabei spielt es auch eine Rolle, welche Art von Informationen über den sogenannten sozialen Graphen der Nutzer*innen an die den Backend-Server betreibende Organisation weitergegeben werden. Die zentralen Systeme werden diesbezüglich stärker kritisiert, weil sie zu viele Informationen durchsickern lassen.
Während noch kontrovers diskutiert wurde, ob eine dezentrale oder zentrale Lösung besser sei, entdeckten Google und Apple – für uns etwas überraschend – ihre beispiellose Freundschaft und einigten sich auf ihr ganz spezielles dezentrales System zur Ermittlung von Kontakten. Die dafür entwickelte Schnittstelle, die Exposure Notification API (genannt GAEN), integrierten die beide Hersteller zudem zügig in ihre mobilen Betriebssysteme. Obwohl die Dokumentation der Schnittstelle als solche offen ist, wird sie stark von der Unternehmenspolitik der beiden Datenriesen kontrolliert: In jedem Land darf die Regierung nur einer einzigen nationalen Gesundheitsorganisation den Zugang zu dieser Schnittstelle gewähren.
Mit dem Ziel eine kritische Auseinandersetzung zu initiieren und die wissenschaftliche Forschung voranzutreiben, wollen wir in diesem Bericht verschiedene Aspekte und Probleme der auf der Google- und Apple-Technologie basierenden Tracing-Apps am Beispiel der Corona-Warn-App beleuchten. Neben den Ergebnissen unserer eigenen Untersuchungen sind auch internationale Studien und die neuesten Medienberichte eingeflossen.
Seit mehreren Monaten haben international renommierte Forscher*innen ebenso wie wir in unterschiedlichen Studien darauf hingewiesen, dass die bisher in einigen Ländern eingesetzte Technologie von Apple und Google grundlegende Sicherheits- und Datenschutzprobleme hat. Diese beiden Aspekte können nicht nur die Integrität unseres Gesundheitssystems untergraben, sondern im schlimmsten Fall die nationale Sicherheit gefährden. Deshalb sollten diese Schwachstellen so schnell wie möglich durch ein umfassendes Technologie-Update behoben werden, um das Vertrauen in die Kontaktverfolgungssysteme zu stärken. Darüber hinaus brauchen wir eine digitale Infrastruktur und genauere Informationen, die es uns ermöglichen, die Wirksamkeit der dezentralen Kontaktverfolgung zu bewerten. Nicht zuletzt werfen wir die Frage auf, warum nur eine nationale Tracing-App eingesetzt wird, obwohl bereits innovative Ideen für Unternehmen, Schulen und Indoor-Veranstaltungen verwirklicht wurden und eingesetzt werden.
Die Corona-Warn-App auf dem Prüfstein: Was lässt sich nach mehr als 100 Tagen sagen?
Die Coronavirus-Pandemie hat seit Monaten die Welt fest im Griff. Die Infektionszahlen steigen. Die zweite Welle, sie rollt. Umso wichtiger ist eine sichere und schnelle Nachverfolgung der Kontakte und der damit verbundene Schutz aller Menschen. In vielen Ländern wurden deshalb bereits digitale Tracing-Apps eingeführt, um eine weitere Ausbreitung der Pandemie zu verhindern. Je nachdem wie hoch die Priorität der Datenschutzaspekte in den einzelnen Ländern ist, kommen dabei unterschiedliche Ansätze zum Tragen: ein zentrales oder dezentrales Kontaktnachverfolgungssystem.
In Deutschland gab es eine lebhafte Debatte über die Einhaltung des Datenschutzes und letztendlich fiel die Wahl auf eine dezentrale Lösung. Die Mitte Juni veröffentlichte Corona-Warn-App ist in Deutschland gut angenommen worden. Inzwischen mehren sich jedoch die Zweifel an ihrem Nutzen – besonders im Hinblick auf die Kosten. Es ist nicht klar, wie viele Menschen sie tatsächlich nutzen und welchen Mehrwert sie für die Eindämmung der Corona-Pandemie hat.
Um zu beurteilen, ob und inwiefern die Corona-Warn-App bei der Eindämmung der Corona-Pandemie nützlich ist, liefert der folgende Beitrag einen Überblick. Dazu sind neben Ergebnissen eigener Untersuchungen internationale Studien sowie die aktuelle Berichterstattung eingeflossen.
Unser Ziel ist es, eine kritische Auseinandersetzung zu initiieren, die die Kosten-Nutzen-Relation und noch wichtiger die technologische Souveränität erörtert. Außerdem geht es darum, die wissenschaftliche Forschung voranzutreiben. Dafür wurden folgende Aspekte näher betrachtet:
Datenübertragung via Bluetooth-Technologie und deren Tücken
Angriffe auf die Corona-Warn-App – wie sicher sind die Daten?
Wie viele Menschen nutzen die Corona-Warn-App?
Dezentrale App ohne datenschützende digitale Infrastruktur
Vor kurzem veröffentlichten wir eine Publikation, die im Detail erläutert, wie ein Angreifer die Informationen, die durch den Kontaktnachverfolgungsansatz von Google und Apple (GAP) freigegeben werden, dazu verwendet, detaillierte Bewegungsprofile der Infizierten Personen zu erstellen. Auch die deutsche Corona-Warn-App ist hiervon betroffen, da sie auf dem GAP-Ansatz aufbaut und daher auch dieselben Schwachstellen hat.
Wir haben viele Fragen zu dieser Publikation bekommen und wollen deshalb hier noch in einer etwas vereinfachten Form darstellen, warum der GAP-Ansatz die Informationen preisgibt, die es erlauben, die Bewegungen von infizierten Personen im Detail nachzuvollziehen.
Der GAP-Ansatz
Wie viele andere Tracing-Ansätze auch, basiert der GAP-Ansatz auf mobilen Smartphone-Apps, die Informationen über Bluetooth LE austauschen, wenn zwei App-Nutzer eine Begegnung haben, bei der sich unter Umständen eine Ansteckung stattfinden könnte. Im GAP-Ansatz geschieht dies, indem die Apps kurzlebige Bluetooth-Kennungen, sogenannte Rolling Proximity Identifier (RPIs), in ihre Umgebung ausstrahlen. Diese RPIs werden von anderen Apps in der Nähe registriert und lokal gespeichert. Mithilfe der gespeicherten RPIs können Apps im Nachhinein feststellen, ob ein Kontakt mit einem infizierten App Nutzer stattgefunden hat, wenn sie die RPIs dieses Nutzers in Erfahrung bringen und mit ihren lokal gespeicherten RPIs abgleichen können.
Im GAP-Ansatz, wie in Abbildung 1 unten gezeigt, generiert jede Tracing App täglich sogenannte Daily Tracing Keys (DTK), also sich täglich ändernde ‚Tagesschlüssel‘. Von diesen Tagesschlüsseln werden dann die RPIs für den jeweiligen Tag abgeleitet, sodass jedes dieser RPIs ca. 10 Minuten gültig ist und dann gegen ein neues RPI ausgewechselt wird. An einem Tag (24 Stunden) verwendet eine App insgesamt 144 verschiedene RPIs.
Abbildung 1: Google-Apple (GAP) Tracing-Ansatz
Wenn ein App Nutzer positiv auf COVID-19 getestet wird, kann er seine Kontaktpersonen warnen, indem er seine RPIs durch das Tracing-System freigibt. Dies passiert, indem die App dieses Nutzers die Tagesschlüssel (DTKs) der letzten Tage (bis zu 14 Tage) an den Tracing-Server schickt. Der Tracing-Server verteilt die Tagesschlüssel dann weiter an alle anderen Apps im System.
Andere Apps laden sich regelmäßig die neuen DTKs von infizierten Personen auf ihre lokalen Geräte herunter, und generieren mithilfe der DTKs die RPIs der infizierten Personen. Dann vergleichen sie diese RPIs mit den lokal gespeicherten RPIs. Falls es eine Übereinstimmung gibt, ist dies ein Beweis für einen Kontakt mit einer infizierten Person und die App kann den Nutzer hierüber warnen.
Das Problem
Das Problem beim GAP-Ansatz ist, dass die DTKs jeweils für 24 Stunden gültig sind, und daher alle am System Teilnehmenden nicht nur die RPIs einer infizierten Person ableiten können, sondern auch ganz genau wissen, dass diese RPIs derselben Person zugeordnet werden können. Dies heißt, dass wenn ein Angreifer in einem bestimmten Gebiet strategisch platzierte Bluetooth-Sensoren dazu benutzt, um RPIs von vorbeilaufenden Tracing-App-Nutzern zu sammeln, der Angreifer im Nachhinein in der Lage ist, mithilfe der von infizierten Nutzern freigegebenen DTKs, die dazugehörigen RPIs abzuleiten und diese mit seinen aufgezeichneten RPIs abzugleichen. Dadurch kann der Angreifer feststellen, ob und wann eine infizierte Person an seinen Beobachtungssensoren vorbeigelaufen ist und kann unter Umständen ein detailliertes Bewegungsprofil der infizierten Nutzer erstellen.
Der Angriff
Die oben geschilderte Schwachstelle am GAP-Ansatz wurde schon von vielen Sicherheitsforschern theoretisch diskutiert. Um zu zeigen, dass es sich hierbei nicht nur um einen theoretischen, sondern auch um einen durchaus reellen Angriff handelt, haben wir ein Angriffsszenario experimentell nachgestellt und unter realen Bedingungen ausgeführt.
Wir haben, wie in Abb. 2 dargestellt, an diversen Stellen in Darmstadt Bluetooth-Sensoren aufgestellt, die die Sensoren eines Angreifers darstellen sollten. Diese Sensoren waren sehr einfache Smartphone-Apps, die die RPIs von vorbeilaufenden Tracing-App Nutzern über Bluetooth LE sammelten und speicherten.
Abbildung 2: Platzierung der Bluetooth-Sensoren des Angreifers in der Stadtmitte von Darmstadt
Während des Experiments zeichneten wir die RPIs von zwei Testnutzern auf, die sich zeitgleich in der Stadtmitte bewegten. Die Testnutzer nutzten Tracing Apps, die RPIs gemäß der Spezifikation von GAP in ihre Umgebung ausstrahlten.
Ein Beispiel der gesammelten Sensordaten an den Beobachtungsstellen B und E ist in Abb. 3 dargestellt. Wie zu sehen ist, scheinen die gesammelten RPIs zufällig, und lassen keine Rückschlüsse über Bewegungen der Nutzer zu.
Abbildung 3: Gesammelte RPI-Daten an den Beobachtungsstellen B und E
Dieses Bild verändert sich jedoch drastisch, wenn man den Fall simuliert, dass einzelne Nutzer sich mit COVID-19 infiziert haben, und ihre DTKs freigeben, mit deren Hilfe die RPIs der einzelnen Nutzer abgeleitet werden können. Da nun die RPIs eindeutig einzelnen Nutzern zugeordnet werden können, kann man, wie in Abb. 4 exemplarisch gezeigt, Rückschlüsse über die Anwesenheit einzelner Nutzer in der Nähe der Beobachtungsstellen machen.
Abbildung 4: Verlinken der RPIs des Nutzers 1 mithilfe des freigegebenen DTK
Dadurch ist es möglich, die Bewegungen von infizierten Nutzern nachzuvollziehen, wenn sie ihre DTKs freigeben. In unserem Experiment konnten wir dadurch die Bewegungen von zwei Testnutzern rekonstruieren. Abb. 5 zeigt das Resultat.
Abbildung 5: Rekonstruktion der Bewegungsprofile von zwei Nutzern mithilfe der freigegebenen Trading-Daten
Mithilfe der Beobachteten RPIs konnten wir feststellen, dass Nutzer 1 zunächst in der Nähe von Beobachtungspunkt A (ein Wohnquartier) gesichtet wurde und danach in D (Klinikum und Apotheke), C (Polizeistation), B (Rathaus) und E (eine Kneipe), bevor der Nutzer die Runde bei Position A beendete. Es wäre also denkbar, dass Nutzer 1 irgendwo in der näheren Umgebung von A wohnt, da es sich dabei um ein Wohnquartier handelt. Auch könnte man spekulativ ableiten, dass der betroffene Nutzer gesundheitliche Probleme hat, oder mit der Polizei zu tun hat. Für Nutzer 2 konnten wir feststellen, dass er vom Rathaus (B) gestartet ist, einen Abstecher in die Kneipe (E) gemacht hat, bevor er bei Position F gesichtet wurde, in der Nähe eines Lokals für Sportwetten. Des Weiteren konnten wir feststellen, dass beide Nutzer die Position B zur gleichen Zeit verließen und zur gleichen Zeit in der Nähe der Kneipe (E) ankamen, dort eine Weile verbrachten und sogar zur gleichen Zeit die Kneipe wieder verließen. Dadurch liegt die Annahme nahe, dass diese beiden Nutzer eine soziale Beziehung zueinander haben.
Fazit
Unser Experiment zeigt, dass Beobachtungen von Nutzern in Verbindung mit den dazugehörigen Zeitstempeln eine Menge an Informationen über Nutzer verraten können, da der Angreifer Informationen darüber bekommt, welche Orte infizierte Nutzer besucht haben und wie viel Zeit sie dort verbrachten. Diese Informationen können wiederum dazu genutzt werden, um spezifische Lebensumstände von Personen in Erfahrung zu bringen, z.B., in welchem Gebiet die Person wohnt (Aufenthaltsort während der Nacht) und wo sie arbeitet (Aufenthaltsort tagsüber). Je mehr der Angreifer solche distinktiven Einzelheiten über die betroffene Person ableiten kann, desto einfacher ist es für ihn, die Person eindeutig zu identifizieren und dadurch die Anonymität des Systems zu brechen.
Ein Forschungsteam der Technischen Universität Darmstadt, der Universität Marburg und der Universität Würzburg hat jüngst in Publikationen als theoretisch möglich beschriebene Datenschutz- und Sicherheitsrisiken der Spezifikation des von Google und Apple vorgeschlagenen Ansatzes für Corona-Apps unter realistischen Bedingungen praktisch demonstriert und bestätigt. Auf dem Ansatz basiert unter anderem die von der Deutschen Telekom und SAP im Auftrag der Bundesregierung entwickelte deutsche Corona-Warn-App; aber auch die schweizerischen und italienischen Kontaktnachverfolgungs-Apps nutzen diese Plattform.
Durch Experimente in realen Szenarien zeigte das Forschungsteam, dass bereits theoretisch bekannte Risiken mit gängigen technischen Mitteln ausgenutzt werden können. So kann zum einen ein externer Angreifer detaillierte Bewegungsprofile von mit COVID-19 infizierten Personen erstellen und unter bestimmten Umständen die betroffenen Personen identifizieren. Zum anderen ist ein Angreifer in der Lage, die gesammelten Kontaktinformationen durch sogenannte Relay-Angriffe zu manipulieren, was die Genauigkeit und Zuverlässigkeit des gesamten Kontaktnachverfolgungssystems beeinträchtigen kann.
Kontaktnachverfolgungs-Apps auf mobilen Geräten versprechen die Möglichkeit, den manuellen Aufwand zur Identifizierung von Infektionskreisläufen erheblich zu reduzieren und die Abdeckung der Kontaktnachverfolgung zu erhöhen. Einer der bekanntesten Vorschläge zur Kontaktnachverfolgung stammt aus der Zusammenarbeit der Konzerne Google und Apple. Es ist zu erwarten, dass die beiden US-amerikanischen Firmen diese neue Standardfunktionalität in ihre jeweiligen mobilen Betriebssysteme, Android und iOS, integrieren werden. Einige Länder, darunter auch Deutschland, haben in ihren nationalen Projekten zur digitalen Ermittlung von Kontaktpersonen bereits diesen Ansatz gewählt.
Ausgangspunkt für die Experimente der IT-Sicherheitsexperten und -expertinnen der drei Universitäten waren zuvor veröffentlichte Berichte über mögliche Datenschutz- und Sicherheitsrisiken im Zusammenhang mit den Entwicklungen des sogenannten „Google Apple Protokoll“ (GAP). Das Forschungsteam testete, ob die konzeptionell beschriebenen Angriffe in der Praxis ausgeführt werden können. Die Experimente zeigen, dass GAP einerseits anfällig ist für die Erstellung von Profilen und so möglicherweise die De-anonymisierung von infizierten Personen erlaubt. Andererseits sind in GAP auch so genannte Relay- oder Wurmloch-Angriffe möglich, wodurch Angreifer falsche Kontaktinformationen generieren können und somit die Genauigkeit und Korrektheit des Gesamtsystems leidet.
Das Forschungsteam realisierte die Angriffe mithilfe handelsüblicher preiswerter Werkzeuge wie Bluetooth-Sniffer (als App auf Smartphones oder Raspberry Pis), die auch in mobilen Umgebungen eingesetzt werden können. Da die Implementierung des GAP-Ansatzes noch nicht für die breitere Wissenschafts-Community verfügbar ist, hat das Forschungsteam die Angriffe basierend auf bereits publizierten Spezifikationen konstruiert. Die Ergebnisse zeigen, dass bei Verwendung strategisch platzierter Sensoren auf Smartphones in einem bestimmten Gebiet die Bewegungen infizierter Personen, simuliert durch Testpersonen, detailliert rekonstruiert werden können. Dadurch war es möglich, sensible Aufenthaltsorte der Testpersonen sowie mögliche soziale Beziehungen zwischen ihnen zu identifizieren.
Die Anfälligkeit von GAP für sogenannte Relay- oder Wurmloch-Attacken offenbart ebenfalls Schwächen. Diese Methode versetzt einen Angreifer in die Lage, die sogenannten Bluetooth-Benutzer-IDs, die von einer Kontaktnachverfolgungs-App erzeugt werden, zu sammeln und unbemerkt an weiter entfernte Orte weiterzuleiten. Unter anderem konnten erfolgreich Bluetooth-IDs zwischen zwei 40 Kilometer voneinander entfernten Städten übertragen werden. Dadurch kann ein Angreifer das Kontaktnachverfolgungssystem als Ganzes beeinträchtigen, indem er Informationen über die Anwesenheit von Infizierten an vielen Orten fälschlicherweise dupliziert, was zu einer erheblichen Zunahme von Fehlalarmen über das potenzielle Infektionsrisiko führen könnte.
Insgesamt sieht das Forschungsteam noch deutliches Verbesserungspotenzial für den von Google und Apple vorgeschlagenen Ansatz für Corona-Apps. Eine detaillierte Beschreibung der Experimente und ihrer Ergebnisse ist im vollständigen Studienbericht zu finden.
