DP-3T vs. PEPP-PT: Worum es im Streit um die Corona-App geht
Lassen sich die Begegnungen zwischen Smartphone-Nutzern zuverlässig detektieren und speichern, ohne die Privatsphäre der Nutzer zu gefährden? Über diese Frage ist in den vergangenen Tagen ein offener Streit zwischen den Entwicklern einer sogenannten Corona-App entbrannt . Der Knackpunkt in der Auseinandersetzung zwischen den Konzepten DP-3T und PEPP-PT: Braucht man für die Auswertung und Speicherung der Kontaktverfolgungsdaten einen zentralen Server oder lässt sich dies auch dezentral über die Geräte der Nutzer abwickeln? Beide Konzepte haben Vor- und Nachteile.
In der prinzipiellen Funktionsweise unterscheiden sich die Konzepte wenig. Zunächst geht es darum, dass ein Nutzer eine App auf seinem Smartphone installiert und mit Hilfe von Bluetooth Low Energie permanent flüchtige IDs aussendet sowie die IDs anderer Nutzer empfängt. Diese IDs werden lediglich lokal auf den Geräten gespeichert und nach einer bestimmten Zeitspanne wieder gelöscht. Ebenfalls gespeichert werden je nach Konzept Zeitangaben des Kontakts und weitere Daten, jedoch keine Standortdaten. Die Frage ist, was nach einer Infektion passiert und welche Daten dann an einen zentralen Server hochgeladen werden.
Nutzer-Apps analysieren Infektionsrisiko
Bei DP-3T, was für Decentralized Privacy-Preserving Proximity Tracing steht, wird der aktuellen Dokumentation (PDF)(öffnet im neuen Fenster) zufolge lediglich ein geheimer Seed Key(öffnet im neuen Fenster) hochgeladen, aus dem sich die flüchtigen IDs generieren lassen, die während des Infektionsfensters ausgesendet wurden. Das Hochladen der Seed Keys ist nur mit einem Authentifizierungscode möglich, der von den Gesundheitsbehörden bereitgestellt wurde. Nicht hochgeladen werden hingegen die IDs der anderen Nutzer, die der Infizierte in dem bestimmten Zeitraum empfangen hat.
Die übrigen Nutzer erhalten stattdessen regelmäßig vom Backend die flüchtigen IDs der Infizierten. Dazu haben sie bei der Installation der App eine entsprechende Notifizierungs-ID erhalten, über die sie mit dem Backend kommunizieren. Nun vergleicht die App die empfangenen IDs der Infizierten mit den gespeicherten IDs aus der Bluetooth-Kommunikation. Falls es eine Übereinstimmung gibt, berechnet die App auf Basis aktueller Parameter das Infektionsrisiko und zeigt es dem Nutzer an. Mit diesem Verfahren will DP-3T sicherstellen, dass der Backend-Server keine Daten erhält, die Aufschluss über die Kontakte von Infizierten ( Social Graph(öffnet im neuen Fenster) ) geben könnten. Vor allem würden keine Daten von Nicht-Infizierten übertragen.
Zentraler Backend-Server bei PEPP-PT
Anders hingegen beim Konzept von PEPP-PT, das für Pan-European Privacy-Preserving Proximity Tracing steht. Dort spielt der Backend-Server eine wichtigere Rolle, wie aus einem Konzeptpapier (PDF)(öffnet im neuen Fenster) hervorgeht. So generiert das Backend nach der Registrierung die flüchtigen Bluetooth-IDs aller Nutzer und stellt sie diesen auf Anfrage der App zur Verfügung. Allerdings müssen die IDs nicht ständig neu angefragt werden, sondern werden beispielsweise für einen Zeitraum von mehreren Tagen bereitgestellt.
Die Apps empfangen dann ebenso wie bei DP-3T die IDs anderer Nutzer. Darüber hinaus speichern sie weitere Metadaten, die für die Berechnung des Risikowertes benötigt werden, darunter die exakten Zeitstempel. Bei einer bestätigten Infektion erhält der Nutzer von den Behörden ebenfalls einen Code (TAN), um seine Daten an das Backend hochzuladen.
Alle Daten werden hochgeladen
Allerdings muss die App dann sämtliche während des Infektionsfensters empfangenen und gespeicherten Daten hochladen. Das Backend wertet diese Daten aus und berechnet anhand von Parametern das Infektionsrisiko der anderen Nutzer, deren flüchtige IDs ebenfalls hochgeladen wurden. Diese werden dann aktiv vom Backend darüber benachrichtigt, dass für sie eine neue Risikoeinschätzung vorliegt.
Das PEPP-PT-Papier nennt mehrere Gründe, warum der Algorithmus zur Risikoeinschätzung nicht lokal auf den Geräten, sondern auf dem Server vorliegen soll. So sei es erforderlich, den Algorithmus schnell auf Basis epidemiologischer Erkenntnisse anpassen zu können. Damit sollen vor allem Fehlalarme verhindert werden. Bei lokaler Verteilung des Algorithmus auf den Endgeräten könne dies zu einem fragmentierten System der Risikoeinschätzung führen, wenn nicht alle Apps auf demselben Stand seien.
Haben Daten Personenbezug?
Zudem müssten bei einer lokalen Risikoauswertung alle Nutzer jederzeit über neue Infektionen informiert werden. Bei einer zentralen Auswertung würden hingegen nur solche Nutzer informiert, die tatsächlich in Kontakt mit einem Infizierten gestanden hätten.
Strittig bei letztgenanntem Argument ist vor allem die Frage, ob die flüchtigen IDs der Nutzer bereits personenbezogene Daten darstellen. Denn die Registrierung der Apps soll jeweils anonym erfolgen, so dass keine Bestätigungs-E-Mails oder andere Authentifizierungen erforderlich sind. Das DP-3T-Konzept sieht beispielsweise vor, dass die ID zur Kommunikation zwischen Backend und App beim Hochladen des Seed Key nicht übertragen wird.
Nach Ansicht der Entwickler haben die Daten keinen Personenbezug, da keiner der Datenverarbeiter in der Lage sei, nachträglich die Daten mit einer konkreten Person zu verknüpfen.
Der Server von PEPP-PT generiert hingegen eine permanente ID der App (PUID), die für die Authentifizierung sämtlicher Kommunikation zwischen App und Backend benötigt wird. Allerdings können Nutzer die PUID jederzeit durch Neuinstallation der App neu generieren.
Viele Apps und Backend-Server möglich
Das Konzept von PEPP-PT sieht jedoch nicht vor, dass es in jedem Land nur eine App oder einen Backend-Server gibt. Mitbegründer Chris Boos erläuterte auf Anfrage von Golem.de , dass jede App mit einem bestimmten Server verknüpft werde, der auch mit den ausgestrahlten Bluetooth-Signalen angegeben werde. Die Server würden dann untereinander die jeweiligen IDs weiterleiten. Damit sei sichergestellt, dass betroffene Nutzer informiert würden, wenn ihre ID auf einem beliebigen Server hochgeladen worden sei.
Dem Konzeptpapier zufolge enthält jede flüchtige ID (EBID) ein Präfix, um die Ursprungsdomain zu identifizieren. Dadurch könnten die verschiedenen Server die Daten betroffener Nutzer untereinander austauschen. Das ist ohnehin erforderlich, falls eine der Kontaktpersonen aus dem Ausland stammen sollte und dort seine App registriert hat. Sollte es genügend Anbieter geben, die funktionsfähige Corona-Apps auf den Markt bringen, würde zumindest verhindert, dass beispielsweise in Deutschland sämtliche Daten auf einem Backend zusammengeführt werden. Aus dem Konzept von DP-3T geht hingegen nicht hervor, wie Daten zwischen verschiedenen Backend-Servern ausgetauscht werden können.
Hoher Traffic bei dezentralem System erwartet
Sowohl DP-3T als auch PEPP-PT sehen Verfahren vor, die die Kommunikation zwischen Backend und Nutzern obfuskieren sollen. Damit soll sichergestellt werden, dass aus dem Datentraffic nicht schon auf eine Infektion oder einen Kontakt geschlossen werden kann.
Laut PEPP-PT könnte es wiederum problematisch werden, wenn beispielsweise 50 Millionen Nutzer sich stündlich mit einem Backend verbinden und die IDs infizierter Nutzer herunterladen müssten, wie es beim dezentralen System erforderlich wäre. Ein solcher Service, inklusive Aufbau von TLS-Verbindungen, sei im Grunde nur von den großen Cloudanbietern wie Amazon, Google oder Microsoft zu stemmen. Bei der geplanten Push-Benachrichtigung der Kontaktpersonen von Infizierten ließe sich der Traffic hingegen auf wenige Tausend Nutzer pro Stunde beschränken.
Regierung warnt vor Flickenteppich
Welches Konzept sich durchsetzt, ist derzeit schwer abzusehen. Bundesregierung und Bundesländer haben in der vergangenen Woche mitgeteilt(öffnet im neuen Fenster) , das Konzept von PEPP-PT zu unterstützen, "weil es einen gesamteuropäischen Ansatz verfolgt, die Einhaltung der europäischen und deutschen Datenschutzregeln vorsieht und lediglich epidemiologisch relevante Kontakte der letzten drei Wochen anonymisiert auf dem Handy des Benutzers ohne die Erfassung des Bewegungsprofils speichert" . Jedoch soll "der Einsatz der App auf Freiwilligkeit basieren" .
Bund und Länder kommen zu dem Schluss: "Ein Flickenteppich von nicht zusammenwirkenden Systemen würde den Erfolg der Maßnahme zunichtemachen." Das trifft in der Tat zu. Denn eine App auf Basis von DP-3T wäre nicht mit einem zentralen Server kompatibel. Auf der anderen Seite könnten viele Nutzer von der App-Installation abgeschreckt werden, wenn sie kein Vertrauen in den Schutz ihrer Daten haben.
Zweite Welle in Singapur
Ob die Corona-Apps den Erfolg garantieren, den sich Regierung und Entwickler davon versprechen, steht auf einem anderen Blatt . So hat der südostasiatische Stadtstaat Singapur schon früh auf eine Bluetooth-App gesetzt , um Infektionsketten ermitteln zu können. Dies konnte jedoch nicht verhindern, dass es nun zu einer zweiten Infektionswelle gekommen ist(öffnet im neuen Fenster) , die die erste bei Weitem übersteigt.
Nachtrag vom 21. April 2020, 16:21 Uhr
In einer Antwort auf eine schriftliche Anfrage der Bundestagsabgeordneten Anke Domscheit-Berg teilte die Bundesregierung mit, dass sie derzeit weiterhin drei Modelle für Corona-Apps bewerte. Neben DP-3T und PEPP-PT zähle dazu noch die in Österreich eingesetzte Lösung der Accenture GmbH, heißt es in dem Schreiben des Bundesgesundheitsministeriums vom 20. April 2020, das Golem.de vorliegt. Die Bundesregierung ziehe ausschließlich eine Nutzung der Corona-Tracking-App auf freiwilliger Basis und dabei solche Modelle und digitale Anwendungen in Betracht, "die den Vorgaben des Datenschutzrechts entsprechen, bei denen die Datenverarbeitung auf Basis einer Einwilligung erfolgt, keine Standortdaten erhoben werden, höchstmögliche Sicherheitsstandards eingehalten werden, die Information der betroffenen Personen anonym erfolgt und das Modell anwenderfreundlich konzipiert sowie technisch geeignet ist, eine epidemiologisch nachvollziehbare Kontaktverfolgung zu ermöglichen" .