DP-3T vs. PEPP-PT: Worum es im Streit um die Corona-App geht

Der Streit über die zentrale Auswertung von Tracing-Daten gefährdet die Akzeptanz der Corona-App. Sind die Bedenken gegen PEPP-PT berechtigt?

Eine Analyse von Friedhelm Greis veröffentlicht am 21. April 2020, 15:23 Uhr

Von der DP-3T-App gibt es bereits eine Testversion auf Github. (Bild: Friedhelm Greis/Golem.de)

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) zufolge lediglich ein geheimer Seed Key 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 Entwickler von DP-3T haben bereits eine erste Version ihrer App veröffentlicht. (Foto: Friedhelm Greis/Golem.de)

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) 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) 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.