Contact Tracing App DP3T - Das sind die Risiken der Schweizer Lösung

Contact Tracing App DP3T

Das sind die Risiken der Schweizer Lösung

Marc Ruef
von Marc Ruef
am 27. April 2020
Lesezeit: 7 Minuten

Keypoints

Diese Risiken gehen von der Schweizer Contact Tracing App aus

  • Zur Eindämmung der Coronakrise wollen verschiedene Staaten sogenannte Contact Tracing Apps einsetzen
  • Diese werden genutzt, um Kontakte über Smartphones festzuhalten
  • Die Lösung DP3T von ETH und EPFL setzt auf einen möglichst dezentralisierten Ansatz, um die Sicherheitsbedenken der Nutzer zu respektieren
  • In diesem Beitrag werden die dennoch verbleibenden Risiken zusammengefasst

Im Zuge der Coronakrise versuchen verschiedene Länder mit der Hilfe von sogenannten Contact Tracing Apps die Infektionsketten nachvollziehen und aufzubrechen. In der Schweiz steht das Framework DP3T, das durch die ETH Zürich und EPFL Lausanne entwickelt wird, bereit. Dieser Beitrag zeigt auf, welche Möglichkeiten und Risiken die Lösung mit sich bringt.

Die von DP3T eingesetzten Ansätze haben offensichtlich zum Ziel, den Endbenutzern ein Maximum an Sicherheit und Privatsphäre zu gewähren. Die durch das Projekt gelebte Transparenz ist vorbildlich, stehen sowohl die Dokumentation als auch eine Beispiel-Implementierung auf GitHub zur Verfügung. So werden verschiedene sicherheitstechnische Verfahren eingesetzt, um eine sichere und möglichst anonyme Nutzung gewährleisten zu können. Diese sind sinnvoll eingesetzt und zeugen von einem hohen Bewusstsein, welche Risiken es zu adressieren gilt. Im Gegensatz zu vielen anderen Frameworks und Produkten steht hier sehr stark das Bedürfnis des Endanwenders im Mittelpunkt. Die Schweizer Lösung hat damit den Produkten anderer Länder und Hersteller einiges voraus.

Im Folgenden sollen die grössten aktiven Risiken von DP3T, die bei der Durchsicht der Dokumentation und des Quelltexts aufgefallen sind, zusammengefasst werden. Das Dokument Privacy and Security Attacks on Digital Proximity Tracing Systems, das durch das Projekt veröffentlicht wurde, geht auf einige zusätzliche Angriffsmöglichkeiten ein. Die in diesem Text genannten Referenzen in Klammern beziehen sich auf eben dieses Dokument.

Erhöhte Angriffsfläche des Smartphones durch App

Die Installation jeder zusätzlichen Software erhöht naturbedingt die Angriffsfläche eines Endgeräts. Eine fehlerhafte Implementierung kann dazu führen, dass Angreifer die Apps in ihrem eigenen Kontext missbrauchen oder gar aus dem Kontext ausbrechen können.

Es ist deshalb wichtig, dass die Implementierung einer sorgfältigen Sicherheitsüberprüfung (Concept Review, Source Code Analyse, Penetration Test) unterzogen wird.

Auswertung von Kommunikationsdaten zu Backend-Server

Eine Person kann sich nach erfolgter Diagnose im Zusammenschluss mit seinem Arzt über sein Endgerät als “infiziert” deklarieren. Diese Information wird an einen zentralisierten Backend-Server geschickt. Zu diesem wird zudem regelmässig eine Kommunikation aufgebaut, um den Bestand der aktuellen Infektionen herunterzuladen.

Jemand, der diese Kommunikation mitlesen kann – dazugehören in erster Linie Provider und Server-Betreiber -, kann statistische Auswertungen dieser Kommunikationen anstreben (NR 1, NR 2). Durch die Auswertung von Meta-Daten lassen sich zum Beispiel unter Umständen Kontakte via IP-Adressbereiche und Geolokalisierung ausmachen. Und durch ein Fingerprinting kann das Tracking einzelner Benutzer stattfinden. Umso mehr Daten vorhanden sind, umso besser kann das Aufdecken von Identitäten und Beziehungen geschehen. Man muss in diesem Fall also darauf vertrauen, dass keine solche Auswertung stattfindet.

Bei DP3T ist die Rede von einem primär dezentralisiertem Ansatz, da die Speicherung und Auswertung der Kontaktbeziehungen ausschliesslich auf den Endgeräten erfolgt. Auf dem zentralisierten Server werden nur die IDs und die Infektionen abgelegt. Dies ist der entscheidende Vorteil des Frameworks.

Zunahme von Angriffen auf Bluetooth

Die App setzt die Aktivierung von Bluetooth LE voraus. Dadurch wird ebenfalls die Angriffsfläche des Geräts erhöht. Schwachstellen wie CVE-2020-0022 (Android), CVE-2020-9770 (iOS) und CVE-2019-9506 (verschiedene Plattformen) demonstrieren, dass das Thema sehr aktuell ist.

Es ist absehbar, dass Bluetooth und die jeweiligen Implementierungen damit in den Fokus verschiedener Angreiferklassen kommen werden. Es ist mit einer Zunahme an Forschung und Veröffentlichung von Schwachstellen sowie Angriffen und Exploits in diesem Bereich zu rechnen.

Durch die allgemeine Manipulation von grundlegenden Bluetooth-Kommunikationen können zudem Kontakte verhindert (Jamming, GR 4) oder vorgetäuscht (Extending, GR 1, GR 2) werden.

Identifizierbarkeit dank Bluetooth durch Dritte

Das Aktivieren von Bluetooth macht das Gerät unter Umständen auch für andere Zwecke identifizierbar (GR 5, GR 6). So kann zum Beispiel gezielte Werbung durch Annäherung (Proximity Marketing) umgesetzt werden. Benutzer, die dem gezielt entgegenwirken wollen, müssten auf die Nutzung der App mit Bluetooth verzichten.

Eigene Implementierung zur Erhöhung der Identifizierbarkeit

Ein Angreifer kann eine eigene Implementierung der Smartphone App umsetzen, bei der nach jedem Kontakt mit einem anderen Gerät dieser in ein separates Konto gespeichert wird (IR 1, GR 3). Zusätzlich können andere Identifikationsmerkmale wie Zeitpunkt, GPS-Position, Name der Hotspots in der Nähe, etc. angelegt werden.

Wird dann ein bekanntes Gerät als “infiziert” markiert, kann durch die eigene und minimierte Dokumentation vereinfacht Rückschlüsse darauf gezogen werden, welches Gerät es war und wo der Kontakt stattgefunden hat.

Das Umsetzen eines solchen Angriffs erfordert eine erhöhte Anforderungen bezüglich technischem Verständnis und krimineller Energie. Zudem bleibt die Auswertungsmöglichkeit stark eingeschränkt, da schlussendlich nur jene Benutzer deanonymisiert werden können, die in einem persönlichen Kontakt angelegt werden konnte. Eine breitflächige Deanonymisierung, vor allem von Personen ausserhalb des persönlichen Kontakts, ist nicht möglich.

Abstriche durch Dezentralisierung

Das Einbringen der Dezentralisierung adressiert zwar die Sicherheitsbedenken der Endanwender. Zeitgleich gehen mit ihr aber Einschränkungen für eine zentralisierte Auswertung einher.

Dem Bundesrat bzw. BAG (Bundesamt für Gesundheit) bleibt es dadurch verwehrt, Trends im geografischen Kontext besser verstehen zu können. So lässt sich nicht genau sagen, ob sich an gewissen Stellen in der Schweiz gefährliche Hotspots entwickelt, wodurch ein nützliches strategisches Werkzeug aus der Hand gegeben wird.

Fazit

Design und die Umsetzung des Frameworks bemühen sich sehr stark, die Schwächen und Risiken zu minimieren. Die pauschale Deklaration als dezentralisierte Lösung mag zwar für die Auswertung der persönlichen Kontaktbeziehungen stimmen. Dennoch wird ein zentraler Datenbank-Server eingesetzt, um den Endgeräten die aktuellen Daten der verifizierten Infektionen bereitzustellen.

Pauschal zu behaupten, dass das Framework alle Probleme in Bezug auf Sicherheit und Privatsphäre löst, ist naiv. Gewisse Restrisiken verbleiben. Ob und inwiefern man als Teilnehmer diese App einsetzen will, muss deshalb einer persönlichen Abwägung standhalten.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Hochschulen, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Haben Sie Interesse an einem Penetration Test?

Unsere Spezialisten kontaktieren Sie gern!

×
Cyber Threat Intelligence

Cyber Threat Intelligence

Marc Ruef

3D Printing

3D Printing

Marc Ruef

Zoom Security

Zoom Security

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv