Hatten Sie in letzter Zeit direkten Kontakt mit einem Corona-Infizierten? Bereits die Einstiegsfrage jeder Corona-Hotline deckt das aktuelle Informationsdefizit zur Bekämpfung des COVID-19-Virus gnadenlos auf. Denn oft weiß man nicht ob und wenn ja, wann man einem Infizierten begegnet ist. Diese Lücke soll nun mit unseren Smartphones geschlossen werden: Corona-Tracking-Apps sorgen dafür, dass das eigene Smartphone mit umliegenden Geräten kommuniziert und an diese, bei erfolgter Eigen-Infektion, eine Infektions-Warnung sendet.

Aktuell existieren zwei grundlegende Konzepte zur technischen Ausgestaltung von derartigen Tracking-Apps. Während das Projekt „DP-3T“1 einen dezentralen Ansatz mit minimaler Einbindung von zentralen Servern verfolgt, setzt das Projekt „PEPP-PT“2 auf einen zentralen Backend-Server. In der Funktionalität sind sich beide Projekte allerdings sehr ähnlich: Mittels Bluetooth Low Energy (BLE) sendet ein Smartphone seine eigene Geräte-ID an nahe gelegene Geräte während es gleichzeitig die fremden IDs der anderen Geräte empfängt und für eine gewisse Zeit speichert.

Zusammen mit der ID wird die Dauer des Kontakts zwischen den einzelnen Smartphones erfasst. Nach erfolgter Infektion wird eine Infektions-Warnung an sämtliche Geräte versendet, die über einen bestimmten Zeitraum Kontakt mit dem Smartphone des Infizierten hatten.

Beide Konzepte nutzen einen zentralen Backend-Server. Allerdings in unterschiedlichen Intensitätsgraden. Beim Projekt „PPEP-PT“ ist der zentrale Server essentiell: Der Server erstellt mit erfolgter Registrierung durch den Nutzer eine (permanente) Geräte-ID für das entsprechende Gerät. Dabei handelt es sich um pseudonymisierte und damit personenbezogene Daten iSd DSGVO. Im Infektionsfall werden sämtliche vom Smartphone des Infizierten gesammelten Daten in den Server geladen, die Infektionsgefahr eingeschätzt und die mit dem Infizierten in Kontakt gekommenen App-Nutzer informiert. Die dafür notwendigen Geräte-IDs der fremden Nutzer liegen bereits griffbereit am Server.

„PPEP-PT“ wird für die Übermacht ihres Backend-Servers und die lediglich pseudonymen Geräte-IDs stark kritisiert. Seine zentralisierte Struktur ist besonders anfällig für Datenschutz-Verletzungen und Cyber-Risiken. Weiters setzt die Lösung enormes Vertrauen in den Betreiber des Backend-Servers (bspw. die Gesundheitsbehörden) voraus. Der Server-Betreiber könnte etwa jederzeit mit Hilfe der permanenten Geräte-ID und der flüchtigen Bluetooth-ID eines Geräts3 auf den Standort eines spezifischen Smartphones schließen.

Aufgrund der genannten Probleme und Überwachungsängste, die wie ein Damoklesschwert über dem „PPEP-PT“ Projekt schweben, dürfte sich nun – nach einem erbitterten Meinungsstreit – der dezentrale Ansatz des „DP-3T“-Projekts durchgesetzt haben4.

Auch in Deutschland und Österreich soll nun auf dieses Modell aufgebaut werden5 6.

Dabei erfolgen sämtliche Datenverarbeitungsschritte dezentral auf dem jeweiligen Smartphone. Zur Identifizierung werden lediglich flüchtige Geräte-IDs verwendet, die direkt auf dem Smartphone generiert werden. An den zentralen Backend-Server wird ausschließlich die flüchtige Geräte-ID des Infizierten kommuniziert. Die Smartphones sämtlicher App-Nutzer gleichen die Liste der Infizierten-IDs mit den mit ihnen in Kontakt gekommenen Geräte-IDs ab. Die Auswertung und Infektions-Warnung eines Nutzers erfolgt daher dezentral auf dem jeweiligen Smartphone.

Obwohl der dezentrale Ansatz für ein gesteigertes Datenschutz-Niveau sorgt, bleiben gewisse Restrisiken bestehen. Bluetooth-Schnittstellen, Smartphones, App-Zugriffsmöglichkeiten oder die Smartphone-Server-Kommunikation sind nur einige der fortbestehenden Cyber-Angriffsflächen. Stresstests7 und state-of-the-art Sicherheits­vorkehrungen (z. B. Verschlüsselungen, Sandbox-Apps und Nutzer-Authentifizierungen) werden daher für die Cyber-Resilienz einer dezentralen Corona-App entscheidend sein. Daneben muss sichergestellt werden, dass die an den Backend-Server übermittelten und dort gespeicherten Daten (i.e. die Liste der Infizierten) korrekt und integer sind. Würde der Server über falsche Infizierten-Daten verfügen, wäre die Warnung und somit die gesamte App ad absurdum geführt8.

Die Integrität der Infizierten-Daten hat zwei immanente Baustellen: Falsche Angaben durch Nutzer und mögliche Datenmanipulationen durch Zugriffe auf den zentralen Backend-Server als Single Point of Failure. Das „DP-3T“-Projekt stellt die Richtigkeit von Infizierten-Meldungen durch einen vom Arzt bzw der Gesundheitsbehörde ausgestellten Authentifizierungscode sicher, der erst nach erfolgter Diagnose ausgestellt wird. Über Maßnahmen zur Gewährleistung der Integrität und Cyber-Resilienz des Backend-Servers ist bislang wenig bekannt. Geeignete Security Layer werden dabei unverzichtbar sein.

Dem dezentralen Geist des „DP-3T“-Projekts folgend, könnte etwa eine dezentrale Backup-Lösung implementiert werden. Denkbar wäre eine Verankerung von Hashwerten der Geräte-IDs in einem dezentralen Netzwerk mit einem automatisierten Tool zur Aufdeckung von Manipulationen. So könnte die Integrität des Backend-Servers für jedermann transparent nachvollzogen werden.

Es obliegt den Verantwortlichen der Datenverarbeitungen (etwa nationalen Gesundheitsbehörden) bei der Entwicklung und dem Betrieb von Corona-Apps auf Basis des „DP-3T“-Ansatzes geeignete Auftragsverarbeiter auszuwählen und mit diesen entsprechende Auftragsverarbeitungsverträge abzuschließen. (Siehe den Beitrag von Dr. Jana Moser zur Einordnung der datenschutzrechtlichen Rollen).

Dabei ist besonders bei Anbietern aus dem EU-Ausland auf ein Datenschutzniveau gemäß Art. 45 DSGVO zu achten. Bei US-Anbietern wäre dies etwa gegeben, wenn sie dem EU-US Privacy Shield unterliegen.

Die ausschließliche Beauftragung von US-Anbietern könnte aber selbst bei Anwendbarkeit des EU-US Privacy Shields eine besondere Gefahr für den angestrebten Datenschutz der App darstellen. Durch US-Gesetze könnte ein US-Auftragsverarbeiter etwa zur Datenherausgabe an US-Behörden verpflichtet sein. Aus diesem Grund wurde bspw. das österreichische Rote Kreuz für die US-lastige Auswahl seiner Auftragsverarbeiter kritisiert, derer es sich bei der österreichischen „Stopp Corona“-App, die ebenfalls auf das dezentrale Grundgerüst setzt bzw darauf umgestellt werden soll, bedient. Aufgrund der vorherrschenden Smartphone-Betriebssysteme wird man an Google (Android) und Apple (iOS) allerdings keinesfalls vorbeikommen.

1. Stärkung der Smartphone-Sicherheit beim App-Nutzer durch hinreichende User-Aufklärung (insb. zum Passwortschutz), Authentifizierungs­mechanismen und Verschlüsselungen bei der Anwendung von Bluetooth-Schnittstellen.

2. Gewährleistung eines hinreichenden Schutzes der Corona-App an sich durch eine dem Stand der Technik entsprechende Verschlüsselungen und Sandbox-Anwendungen.

3. Dezentrale Datenspeicherung und -verarbeitung auf den Smartphones.

4. Transparente und dokumentierte Löschkonzepte beim zentralen Backend-Server.

5. Implementierung von (dezentralen) Backup-Konzepten und Tools zur Aufdeckung von Datenmanipulationen im zentralen Backend-Server.

6. Gewissenhafte Auswahl der Auftragsverarbeiter und Abschluss von geeigneten Auftrags­verarbeitungs­verträgen.