Die deutsche Corona-Warn-App

Das neuartige Coronavirus kann ansteckend sein, bevor die infizierte Person auch nur leichteste Symptome entwickelt. Manche Personen haben keine Symptome und werden eher zufällig durch Reihentestungen entdeckt. Das verursacht eine erhöhte Ansteckungsrate.

Baustein zur Eindämmung

Aus diesem Grund ist es wichtig, dass infizierte Menschen sich in Quarantäne begeben. Neben der manuellen Nachverfolgung durch die Gesundheitsämter und ausreichenden Testkapazitäten gilt die Kontakt-Nachverfolgung durch eine App als möglicherweise bedeutender Baustein, um das Infektionsgeschehen einzudämmen (siehe https://ogy.de/studie-uni-oxford).

Tracing

Der Begriff „Tracing“, zu Deutsch „Ablaufverfolgung“, war bislang eher aus der IT-Technik für die Protokollierung von Systemereignissen bekannt. Geht es darum, Infektionskontakte nachzuverfolgen, suggeriert der Begriff eine Nähe zum „Tracking“.

Doch diese Nähe täuscht. Denn die Verfolgung funktioniert ohne die negativen Begleiterscheinungen wie Identifizierbarkeit oder die Bildung von Persönlichkeitsprofilen.

Tracing-Techniken

Es gibt nach momentanem technischem Stand drei Varianten, um das Kontaktverhalten von großen Teilen der Bevölkerung zu erfassen:

1. Funkzellen

Jedes Smartphone ist permanent in mehrere Funkzellen eingeloggt. Während nur eine dieser Zellen die Daten- oder Sprachverbindung realisiert, lässt sich über einfache geometrische Funktionen anhand der Signalstärke und des Standorts der Masten der Standort eines Nutzers abschätzen.

Diese Technik nutzt die Polizei unter strengen rechtlichen Anforderungen mitunter im Rahmen ihrer Aufgaben.

2. Standortdaten

Standortdaten zu erfassen, ist technisch sehr einfach. Jedes Smartphone hat einen integrierten Standortdienst. Er erfasst die Position des Geräts anhand von GPS- und Wifi-Signalen in der Regel auf wenige Meter genau.

Innerhalb von Gebäuden kommt diese Technik allerdings an ihre Grenzen. Denn hier ist keine GPS-Koordination vorhanden, und die Positionsbestimmung mit Wifi-Signalen verliert deutlich an Genauigkeit.

3. Funksignale

Jedes Smartphone hat integrierte Funkchips. Sie realisieren das Funkprotokoll Bluetooth. Die neueste Variante, Bluetooth Low Energy (BLE), bietet neben verbesserten Sicherheitseigenschaften einen geringeren Stromverbrauch.

Das Corona-Tracing verwendet BLE recht kreativ: Anhand der Signalstärke wird der Abstand zwischen zwei Smartphones abgeschätzt. Das ist keineswegs trivial. Denn die Signalstärke schwankt und variiert zwischen Hardwaremodulen und Softwaretreiberversionen.

Die deutsche Corona-Warn-App arbeitet mit BLE. Warum hat man sich dafür entschieden? Den datenschutzrechtlichen Grundsatz der Erforderlichkeit definiert die Datenschutz-Grundverordnung (DSGVO) wie folgt: Geeignet, um einen bestimmten Zweck zu erreichen, und es ist kein milderes Mittel (im Sinne eines Grundrechtseingriffs) vorhanden.

Bei den drei beschriebenen Tracing-Varianten erfüllt insbesondere mit Blick auf geschlossene Räume die Variante, die Funksignale nutzt, konkret BLE, beide Voraussetzungen am besten.

Direkte Identifizierbarkeit vs. Pseudonymität vs. Anonymität

Die Frage, ob eine Tracing-Erfassung von weiten Teilen der Bevölkerung mit direkt identifizierbaren Merkmalen wie Telefonnummer oder Name bzw. Adresse stattfinden sollte, wurde schon frühzeitig politisch entschieden: Der Datenschutz sollte so weit möglich umgesetzt werden. Die direkte Identifizierbarkeit war damit vom Tisch.

Das führte zu dem Konzept, dass stabile kryptografische Verfahren Zufallskennungen erzeugen. Diese Kennungen werden als Bestandteil eines Kontaktdatensatzes, der auch einen Zeitstempel oder die Signalstärke enthält, gespeichert.

Diese Zufallskennung erfüllt die Voraussetzung zur Pseudonymisierung nach DSGVO. Denn die Kennung ist nicht mit einem unmittelbar identifizierbaren Merkmal verknüpft. Es könnte aber verfügbares Zusatzwissen geben, das eine Identifikation ermöglicht.

Es lässt sich jedoch durchaus auch der Begriff der Anonymität begründen. Denn hier fordert die DSGVO, alle Mittel zu berücksichtigen, die der Verantwortliche oder eine andere Person nach allgemeinem Ermessen wahrscheinlich nutzt, um die natürliche Person direkt oder indirekt zu identifizieren. Gerade mit Blick auf den gleich beschriebenen dezentralen Ansatz ist diese Sichtweise nicht allzu abwegig.

Zentral vs. dezentral

Beim Infektions-Tracing geht es darum, Personenkontakte in räumlicher Nähe über einen gewissen Zeitraum zu erfassen. Hat einer dieser Kontakte einen positiven Corona-Test gehabt, informiert das Tracing alle relevanten Personenkontakte über ein mögliches Infektionsrisiko.

Dabei sind drei grundlegende Fragen zu klären:

• Wo werden die zufälligen Personenkennungen erzeugt?
• Wo werden die Kontaktinformationen (von zwei Smartphones) gespeichert?
• Wie werden Nutzer über einen risikobehafteten Kontakt informiert?

Beim zentralen Modell erzeugt ein zentraler Server die Kennungen und speichert sie. Die Information über einen Kontakt zu bestätigten Corona-Personen erfolgt ebenfalls serverseitig an die Geräte, die einen Kontakt zu der Person hatten.

Den zentralen Ansatz verfolgte ursprünglich auch Deutschland. Die konkreten Realisierungskonzepte hatten bereits den Grundgedanken Data Protection by Design verfolgt und wären grundsätzlich auch mit der DSGVO in Einklang zu bringen gewesen.

Dass es dann zum dezentralen Modell kam, lag an zwei Faktoren: Die in der Öffentlichkeit geführte Diskussion um die zwei unterschiedlichen Architekturansätze führte dazu, dass besorgte Bürger der Meinung waren, es sollten keine Bewegungsprofile mit Standortinformationen und direkter Identifizierbarkeit zum Corona-Tracing eingesetzt werden.

Der andere Grund war viel schlichter: Smartphone-Apps auf dem Apple-Betriebssystem unterstützen keine dauerhaft laufenden Hintergrundprogramme mit Zugriff auf die Bluetooth-Schnittstelle. Es musste also eine Lösung für dieses „Problem“ her.

In Frankreich hat der zentrale Ansatz übrigens den „Segen“ der französischen Datenschutzaufsichtsbehörde erhalten; zwar mit gewissen Bauchschmerzen, aber immer noch in Einklang mit der DSGVO.

Das dezentrale Modell der Corona-Warn-App

Das dezentrale Modell, das in Deutschland die „Corona-Warn-App“ umsetzt, besitzt also folgende Eigenschaften:

• Die Generierung der Zufallskennungen erfolgt auf dem Smartphone ohne Speicherung auf einem zentralen Server.
• Kontaktinformationen zwischen zwei Smartphones bleiben auf den Geräten und werden nicht an einen zentralen Server zur Speicherung übertragen.
• Die Information über mögliche Corona-Kontakte erfolgt von einem Smartphone über eine zentrale Stelle an alle Smartphones, die die Tracing-App installiert haben. Ein Abgleich erfolgt ausschließlich lokal auf dem Gerät, genauso wie die Meldung, dass man ein erhöhtes Infektionsrisiko besitzt.

Plattformunterstützung durch Google und Apple

Soll ein Infektions-Tracing über das Bluetooth-Signal erfolgen, sind neben der Frage des Batterieverbrauchs und dauerhaft laufender Hintergrundprozesse umfangreiche Kenntnisse über das Bluetooth-Protokoll, die verwendete Hardware und ggf. Softwaretreiber erforderlich.

Aus diesem Grund haben die beiden großen Plattformanbieter für Smartphones, die Firmen Google und Apple, das Exposure Notification Framework (https://www.google.com/covid19/exposurenotifications/) entwickelt. Die Plattform soll es App-Entwicklern ermöglichen, über eine Softwareschnittstelle auf Zufallskennungen zuzugreifen, wenn sie ein dezentrales Architekturmodell realisieren.

Das Framework arbeitet mit einem Risikomodell, das eine externe Parametrisierung unterstützt. Das bedeutet, dass der App-Betreiber gewisse Stellschrauben bezüglich des aktuellen Infektionsgeschehens einstellen kann. In Deutschland ist dies das Robert-Koch-Institut.

Außerdem ist sichergestellt, dass nicht alle anderen Apps auf einem Smartphone auf diese Schnittstelle zugreifen können. Denn das würde Re-Identifikationsrisiken mit sich bringen.

WICHTIG: Das Aufsetzen auf das Exposure Notification Framework setzt voraus, dass die Firmen Google und Apple vertrauenswürdig sind und sie die Zufallskennungen nicht mit Benutzerkonten oder Werbe-IDs verknüpfen.

Bei Android ist es zudem so, dass dieses Framework Bestandteil der „Google Play Services“-App ist. Rein als Open Source betriebene Android-Smartphones mit sogenannten Custom-ROMs werden damit (noch?) nicht unterstützt.

Interoperabilität

Wie ist denn der Kontakt in der Kneipe im Urlaubsort zu werten, von dem eher der Ouzo als der Name des Trinkpartners in Erinnerung ist?

Sollten auch Apps anderer Länder das Exposure Notification Framework von Apple/Google nutzen, ist eine grenzübergreifende Benachrichtigung technisch kein Problem, sofern der politische Wille vorhanden ist. Sollte das Framework nicht genutzt werden, dann sieht es schon anders aus – machbar ist es aber.

Wie steht es um den Datenschutz durch Technikgestaltung?

Der „Datenschutz durch Technikgestaltung“ von Art. 25 Abs. 1 DSGVO fordert,

• den Datenschutz schon in der Planungsphase zu berücksichtigen und
• die Datenschutzgrundsätze von Art. 5 Abs. 1 DSGVO risikoorientiert umzusetzen.

Wie hat nun die Warn-App diese Grundsätze umgesetzt?

1. Transparenz für den Betroffenen

Die Transparenz für den Betroffenen ist durch Datenschutzbestimmungen für die unterschiedlichen Zwecke und die Einholung der Einwilligung zentral in der App integriert. Die Sprache ist einfach gehalten. Eine Mehrsprachigkeit ist angedacht.

2. Datensparsamkeit & Zweckbindung

Die Datensparsamkeit setzt die App durch den dezentralen Ansatz und die lokale Erfassung von sich ändernden Zufallskennungen durch BLE um. Die Zweckbindung stellen die weitgehend pseudonymen / anonymen Zufallskennungen sicher. Die nach Zwecken getrennten Systemeinheiten in der Grundarchitektur unterstützen ebenfalls die Zweckbindung.

3. Richtigkeit der Daten

Bei der Richtigkeit der Daten ist der unsichere Faktor, ob die schwankenden Signalstärken der BLE-Funksingale nicht im Einzelfall eine Risikoexposition mit sich bringen, obwohl in Wirklichkeit z.B. eine Glasscheibe dazwischen war.

Die Richtigkeit im Sinne von Authentizität von Corona-Infektionen realisieren abseits der App einzulesende TAN-Nummern (z.B. in QR-Codes) – das setzt allerdings voraus, dass diese TAN-Nummern im Gesamtsystem robust gegen Zufallsangriffe geschützt sind.

4. Speicherbegrenzung

Die Speicherbegrenzung wird derart umgesetzt, dass die Zufallskennungen im Exposure Notification Framework nach 30 Tagen automatisch gelöscht werden. Darüber hinaus kann der Nutzer die eigene Zufallskennungen-Reihe löschen, indem er die App deinstalliert.

5. Integrität und Vertraulichkeit

Den Grundsatz der Integrität und Vertraulichkeit, also die Informationssicherheit der App und der beteiligten Server, sollen folgende Maßnahmen umsetzen:

• saubere Softwareentwicklung
• begleitende Pen-Tests
• Orientierung an Best-Practice-Maßnahmen (z.B. BSI-IT-Grundschutz)
• Source-Codes werden der Öffentlichkeit und damit externen Sicherheitsforschern o.Ä. zur Verfügung gestellt.

Im Ergebnis enthält die Warn-App zumindest alle relevanten Bereiche von Art. 5 Abs. 1 DSGVO. Damit ist dieses Projekt ein sehr gutes Beispiel dafür, dass sich Funktionalität und ein hohes Maß an Datenschutz nicht widersprechen.

Datenschutz-Folgenabschätzung für die Corona-Warn-App

Dass eine Datenschutz-Folgenabschätzung (DSFA) bei einem solchen Infrastrukturprojekt erforderlich ist, überrascht nicht. Eher schon, dass man auch hierbei dem Transparenzansatz vollumfänglich nachgekommen ist.

Die DSFA samt Risikoanalyse sowie technischen und organisatorischen Maßnahmen, um erkannte Risiken einzudämmen, lässt sich frei herunterladen (https://ogy.de/cwa-dsfa; PDF mit 117 Seiten).

Die DSFA kommt zu dem Ergebnis, dass es hohe Restrisiken gibt, die sich nicht wirksam eindämmen lassen. Die DSFA ruft an dieser Stelle Art. 36 DSGVO aus (Konsultation der Aufsichtsbehörde).

Art. 36 DSGVO sagt nicht, dass ein Verantwortlicher die Verarbeitung nicht starten dürfe, sondern „nur“, dass er die zuständige Datenschutzaufsichtsbehörde konsultieren muss. Das lässt sich als weiterer Schritt zu einem hohen Datenschutz-Standard werten.

Hier stellt sich eher die Frage, wieso Art. 36 DSGVO in der Praxis bei Unternehmen abseits der Corona-Tracing-App faktisch nicht vorkommt.

Was ist mit einem Zweckänderungsverbot?

Die Rechtsgrundlage für die Corona-Tracing-App ist die datenschutzrechtliche Einwilligung nach Art. 6 Abs. 1 Buchst. a. Dass diese Einwilligung nicht freiwillig sein könnte, Gastronomen beispielsweise den Zugang zu ihren Betrieben von einer „grünen Anzeige“ in der App abhängig machen, haben die Datenschutzaufsichtsbehörden erkannt.

In ihrer Pressemitteilung sprechen sie daher bei solchen Fällen klar von einer „zweckwidrigen Verwendung“ (https://ogy.de/dsk-warn-app).

Trotzdem wäre es eine weitere vertrauensbildende Maßnahme gewesen, ein Zweckänderungsverbot der Tracing-Daten gesetzlich zu verankern.

Allerdings stellt die beschriebene dezentrale Architektur mit pseudonymen bzw. anonymen Zufallskennungen weitgehend sicher, dass zumindest keine zentrale Massenüberwachung der Bevölkerung möglich wäre.

Fazit: Gutes Beispiel für Privacy by Design und DSFA

Die Gesamtarchitektur der deutschen Corona-Tracing-App besitzt eine gewisse Komplexität – sie tut jedenfalls mehr, als nur flächendeckend personenbezogene GPS-Koordinaten auf einem Server zu sammeln.

Sie kann nach aktueller wissenschaftlicher Erkenntnis einen Baustein darstellen, der das Corona-Infektionsgeschehen effektiv eindämmt. Und dies unter Berücksichtigung der technischen Gestaltungsmöglichkeiten des europäischen Datenschutzes.

Die momentan höchsten Risiken, die abseits dieser Betrachtung existieren, liegen in Deutschland darin, dass noch nicht alle Labore daran teilhaben, die TANs digital zu generieren – ein Problem, das an sich leicht zu lösen ist.

Die DSFA zur Corona-Warn-App kann ein Referenzprojekt auch für andere Verantwortliche sein, die bislang der Meinung waren, mit ein bis zwei Seiten Risikoauswertung eine Datenschutz-Folgenabschätzung durchgeführt zu haben.

Andreas Sachs