key: cord-0048160-69rio2hx
authors: Grube, Tim; Heinrich, Alexander; Stroscher, Jan-Philipp; Schomberg, Sabrina
title: Datensicherheit von Corona-Apps nach der DSGVO
date: 2020-07-27
journal: Datenschutz Datensich
DOI: 10.1007/s11623-020-1314-0
sha: 001139d307c2329d2b34a25d5b35ba84c6deb382
doc_id: 48160
cord_uid: 69rio2hx

Der Beitrag analysiert die Protokolle der Konsortien DP-3T und PEPP-PT aus technischer Perspektive und grenzt diese voneinander ab. Zudem wird die technische Ausgestaltung der Entwicklerschnittstelle (API) von Google und Apple dargestellt. Aufbauend darauf erfolgt eine rechtliche Beurteilung der sich aus Art. 5 Abs. 1 lit. f, 25, 32 DSGVO ergebenden und die Datensicherheit betreffenden Kriterien und deren konkrete Umsetzung in den Protokollen.

zogen. Es ist davon auszugehen, dass dies nicht zuletzt erfolgte, um mehr Akzeptanz für eine solche App in der Bevölkerung zu schaffen. Ein weiterer ausschlaggebender Punkt könnte gewesen sein, dass die von Apple und Google entworfene API ausschließlich einen dezentralen Ansatz unterstützt. Die Nutzung dieser Schnittstelle ist aber mitentscheidend für die Effektivität der Kontaktnachverfolgung, da beim Betriebssystem iOS von Apple eine Hintergrundnutzung von Bluetooth durch Apps auf Systemebene unterbunden wird und somit eine fortwährende Nachverfolgung der Kontakte nur durch Nutzung der API mit dem dahinterliegenden Bluetooth-Service gewährleistet werden kann.

Das Grundprinzip für eine Bluetooth basierte Kontaktnachverfolgung ist dabei in allen hier verglichenen Ansätzen gleich: Die Smartphones aller Nutzerinnen und Nutzer der App senden permanent Daten über BLE (Bluetooth Low Energy) an alle anderen sich in der Nähe befindenden Smartphones mit kompatiblen Apps. Diese Daten enthalten Identifikationsdaten (IDs), welche den installierten Apps zugeordnet werden können. Um eine Reidentifizierbarkeit und eine damit verbundene Profilbildung zu erschweren, werden diese IDs regelmäßig geändert. Mit Hilfe der IDs lässt sich die Kontakthistorie der Nutzerinnen und Nutzer nachvollziehen und eine entsprechende Kontaktbenachrichtigung erstellen.

Über den Datenschutz der Apps zur Kontaktnachverfolgung, insbesondere über die Zulässigkeit der Datenverarbeitung, wurde bereits viel diskutiert. 1 

Für den Vergleich der Ansätze sollen zunächst ihre jeweiligen technischen Spezifikationen zur Kontaktnachverfolgung dargestellt werden. Hierbei gilt für alle Ansätze, dass die Daten, die über BLE gesendet werden, öffentlich einsehbar sind. Nur so kann sichergestellt werden, dass jedes Empfangsgerät die Daten auch verwerten kann, was aber auch eine Kenntniserlangung durch Dritte, nicht am Versendevorgang beteiligte Akteure ermöglicht.

Die Erzeugung der zu versendenden IDs findet auf dem Smartphone in drei Schritten statt: Zu Beginn wird auf dem Smartphone ein zufälliger Tagesschlüssel für den aktuellen Tag erzeugt (Schritt 1). Von diesem Schlüssel ausgehend werden nun mit Hilfe von kryptografischen Einweg-Funktionen mehrere IDs für den aktuellen Tag generiert. Diese werden über BLE versendet und ändern sich im Abstand von 10-20 min. Die Empfängerin oder der Empfänger einer solchen ID kann anhand dieser nicht den initialen Tagesschlüssel herausfinden, da die kryptografischen Einweg-Funktionen nicht zurückgerechnet werden können (Schritt 2). Zuletzt wird von dem ursprünglichen Tagesschlüssel der Tagesschlüssel für den Folgetag abgeleitet, von dem wiederum neue IDs erzeugt werden können (Schritt 3).

Der Ablauf für die Rückmeldung einer COVID-19-Erkrankung ist nach beiden Ansätzen des DP-3T-Konsortiums gleich. Eine Per-son erhält nach einer COVID-19-Diagnose einen Code (beispielsweise einen QR-Code) von einer autorisierten Stelle. Diesen gibt sie in der App ein, welche eine verschlüsselte TLS-Verbindung zum Server öffnet und den Autorisierungscode und die Tageschlüssel des relevanten Zeitraums an den Server sendet. Nach dem Upload auf den Server verifiziert dieser den Autorisierungscode und speichert die Tagesschlüssel. Dadurch wird sichergestellt, dass alle Tagesschlüssel auf dem Server von erkrankten Personen stammen. Es werden keine anderen Informationen im Zusammenhang mit dem Upload (wie IP-Adressen oder Uhrzeit) gespeichert. Die installierten Apps laden nur die Tagesschlüssel (nicht alle ausgetauschten IDs) des relevanten Zeitraums von allen infizierten Personen von einem entsprechenden (zentralen) Server herunter, um dann lokal auf dem Gerät einen Vergleich mit allen empfangenen IDs durchzuführen. Jeder Tageschlüssel ist fest mit einem Datum verknüpft. Dadurch wird verhindert, dass andere Personen getäuscht werden können, indem ein Schlüssel von einer infizierten Person verwendet wird, um neue IDs zu erzeugen und zu versenden. 9

Die Erzeugung der IDs erfolgt bei diesem Ansatz komplett zufällig. Es gibt also keinen Tagesschlüssel, von welchem die IDs abgeleitet werden. Für jeden Zeitraum (10-20 min), in dem eine ID versendet wird, wird ein neuer zufälliger Wert generiert, von dem die ID abgeleitet wird. Außerdem wird nur ein wechselnder Teil dieser ID versendet. Diese einzelnen Teile der ID lassen sich nur zu einer vollständigen ID zusammenfügen, wenn zwei Nutzerinnen oder Nutzer sich für eine bestimmte Zeit (ca. 10-15 Minuten) in unmittelbarer Nähe aufgehalten haben (Abstand 1,5 bis 2 m), weil sich dann aus mehreren Übermittlungen eine vollständige ID ergibt. Dies hilft zugleich bei der Risiko-Bewertung, da somit auch die Dauer eines Kontakts abgeschätzt werden kann.

Der Ablauf für die Rückmeldung einer COVID-19-Erkrankung an die App erfolgt hingegen genau wie im ersten Ansatz (s. o.). Nachdem die (vollständigen) IDs der infizierten Personen auf den Server hochgeladen wurden, erzeugt dieser einen kryptografischen Filter, den alle Nutzerinnen und Nutzer erhalten, um lokal abgleichen zu können, welche IDs zu einer infizierten Person gehören. Dadurch besteht zwar weiterhin die Möglichkeit, herauszufinden, zu welcher Zeit man eine infizierte Person getroffen hat. Es ist aber nicht mehr möglich, neue IDs aus den initialen Werten zu generieren. Auch hier gilt, dass keine weiteren Nutzerdaten erhoben werden.

Überdies kann eine Person mit Zugriff auf den Server keine sozialen Graphen erstellen und somit nicht nachvollziehen, welche Personen miteinander in Kontakt standen. Da alle auf dem Server gespeicherten Informationen allen Nutzerinnen und Nutzern der App zugänglich sind, erhalten Angreiferinnen und Angreifer durch Zugriff auf den Server nicht mehr Informationen, als ohnehin bekannt sind. Somit können mit Hilfe der Serverdaten nur die IDs von Erkrankten mit eventuell vorher aufgenommenen IDs vergleichen werden.

Bei der zunächst geplanten zentralisierten Lösung des PEPP-PT-Konsortiums wäre eine begrenzte Anzahl von IDs zufällig auf 9 vgl. zum Ablauf: Overview of Data Protection and Security, DP-3T https:// github.com/DP-3T/documents/blob/master/DP3T%20-%20Data%20Protec-tion%20and%20Security.pdf einem zentralen Server erzeugt und sodann an die Smartphones mit der Kontaktnachverfolgungs-App übermittelt worden. Diese IDs können dann in einem bestimmten Zeitraum über BLE versendet werden. Sobald die übermittelten IDs verbraucht sind, werden vom Server neue IDs an die App übermittelt. Falls zu diesem Zeitpunkt keine Verbindung zum Server besteht, kann die Kontaktnachverfolgung mangels IDs nicht erfolgen. Das hat hingegen nicht zur Folge, dass eine dauerhafte Verbindung zum Server notwendig wäre. Dem zentralen Server wäre jede jemals versendete ID bekannt gewesen. Ohne weitere Sicherheitsmaßnahmen wäre es theoretisch möglich gewesen, auf dem Server soziale Graphen zu erstellen. Solch ein Graph könnte eine Deanonymisierung der Daten und damit auch eine Überwachung ermöglichen, was als einer der größten Kritikpunkte gegenüber einer zentralisierten Lösung formuliert wurde. Die Protokolle des DP-3T-Konsortiums und die API von Apple und Google sehen als technische und organisatorische Maßnahme i. S. d. Art. 25 DSGVO u. a. eine Pseudonymisierung vor. Eine echte und vollständige Anonymisierung ist hingegen in keinem Ansatz vorgesehen. Allerdings dürfte diese sich auch funktional nicht mit dem Zweck der App vertragen, sodass sie rechtlich nicht gefordert ist. Immerhin beabsichtigt keiner der Ansätze Klarnamen oder Handynummern zu nutzen, da alle Ansätze mindestens eine Pseudonymisierung vorsehen. Ansatz 1 des DP-3T-Konsortiums sieht vor, einen zufälligen Tagesschlüssel auf dem Smartphone zu erzeugen, welcher dann mit Hilfe kryptografischer Einweg-Funktionen IDs erzeugt. Ansatz 2 geht darüber sogar noch hinaus, indem nur ein wechselnder Teil der zufällig erzeugten IDs versendet wird und sich erst nach einiger Zeit aus diesen Teilen die vollständige ID zusammensetzen lässt. Die Verbesserung der Datensicherheit erfolgt in diesem Ansatz durch das Aufbrechen der ID: Bewegt sich eine Nutzerin oder ein Nutzer, während die IDs von Geräten zur stillen Beobachtung empfangen werden, so werden wahrscheinlich nicht alle notwendigen Teile der ID empfangen und die Wahrscheinlichkeit der Zuordnung einer ID zu einer Nutzerin oder einem Nutzer sinkt.

Das PEPP-PT-Protokoll sieht hingegen vor, dass die IDs zufällig auf dem Server erzeugt werden, weswegen diesem Server alle IDs bekannt wären. Im Gegenzug müssten die IDs der Infizierten jedoch nicht an alle Nutzerinnen und Nutzer versendet werden.

Art. 32 DSGVO behandelt die Datensicherheit, also die Gesamtheit aller technischen und organisatorischen Maßnahmen, die einen unzulässigen Umgang mit personenbezogenen Daten verhindert. Im Gegensatz zu Art. 25 DSGVO, welcher auf alle Datenschutzgrundsätze verweist, setzt Art. 32 DSGVO vornehmlich am Datenschutzgrundsatz der Integrität und Vertraulichkeit aus Art. 5 Abs. 1 lit. f DSGVO an. 11 Da die Maßnahmen zur Pseudonymisierung bereits im Rahmen des Art. 25 DSGVO aufgeführt wurden, konzentrieren sich die Ausführungen im Folgenden auf die Punkte der Verfügbarkeit, Vertraulichkeit und Integrität.

Die Verfügbarkeit von Dienstleistungen, Funktionen eines IT-Systems, IT-Anwendungen, IT-Netzen oder auch von Informationen ist vorhanden, wenn diese von den Anwendern stets wie vorgesehen genutzt werden können. 12 Dies gilt auch für den Fall eines Hackerangriffes oder einer Naturkatastrophe. Verfügbarkeit kann z. B. dadurch erreicht werden, dass eine Lösung ohne die regelmäßige Verbindung zu einem Server auskommt oder durch die Verwendung resilienter Server-basierter Lösungen, die im Falle eines Angriffs automatisch ein zweites System starten.

Die Ansätze von DP-3T haben den Vorteil, dass die auf dem Protokoll aufbauenden Apps auch bei einem längeren Serverausfall weiterhin IDs versenden und empfangen können. Lediglich positiv Getestete können in diesem Zeitraum keine IDs mehr hochladen und auch andere Nutzerinnen und Nutzer können diese IDs nicht herunterladen. Somit kann zeitweise niemand mehr gewarnt werden, was im Falle eines Serverausfalls auch für den PEPP-PT-Ansatz gilt. Die Kontaktnachverfolgung der App bleibt jedoch nach den Protokollen des DP-3T-Konsortiums und bei der Lösung von Apple und Google auch bei einem Serverausfall verfügbar. Bei der Lösung von PEPP-PT funktioniert die App nur so lange autonom weiter, bis alle zuvor vom Server übermittelten IDs verbraucht wurden. Da bei einem Serverausfall keine IDs mehr übermittelt werden können, ist eine Kontaktnachverfolgung zu dieser Zeit nicht möglich und kann auch nicht nachgeholt werden.

Ein Nachteil, zumindest im Hinblick auf die Verfügbarkeit, ist der Umstand, dass die Lösung von Apple und Google in das Betriebssystem eingepflegt wird und damit jederzeit auf Grundlage einer eigenen Bewertung von den Herstellern deaktiviert werden kann. Daher bleibt es Apple und Google vorbehalten, über das Fortbestehen der Notwendigkeit zu entscheiden, was Apple und Google auch bereits angekündigt haben zu tun. Ein datenschutzrechtlicher Vorteil ist demgegenüber zweifelsfrei die Förderung des Grundsatzes der Datenminimierung und die Einhaltung der Zweckbindung. Soweit der Zweck erfüllt ist, dürfen auch keine weiteren personenbezogenen Daten verarbeitet werden. Kehrseite dieses Vorteils ist wiederum, dass man theoretisch der Bewertung der Zweckerreichung von Apple und Google "ausgeliefert" ist. Hierbei bleibt zu hoffen, dass eine Deaktivierung in Absprache mit den jeweiligen Länderregierungen erfolgt.

Weiterhin ist das Kriterium der Belastbarkeit als Unterpunkt der Verfügbarkeit auf dessen Erfüllung hin zu untersuchen. Dieses Kriterium beschreibt die Fähigkeit einer Organisation, einer Beeinträchtigung durch Störung zu widerstehen und eine rasche Wiederherstellung der Verfügbarkeit von bzw. dem Zugang auf personenbezogene Daten bei einem physischen oder technischen Zwischenfall zu gewährleisten. 13 Die dezentralen Systeme haben in diesem Fall den Vorteil, dass das System selbst bei Verlust aller Daten durch Nutzung eines neuen Servers wieder starten kann. Auf dem Server liegen nur Daten, mit denen die IDs von infizierten Personen berechnet werden können. Da die Apps sich automatisch aktualisieren, ist es wahrscheinlich, dass viele bereits die aktuellen Datensätze lokal gespeichert haben. Nach einem Neustart können sich die Apps wieder mit dem neuen Server verbinden und lokal die Möglichkeit eines Kontakts zu infizierten Personen prüfen. Ein Verlust dieser Daten wäre also weniger dramatisch als bei einem zentralen System, da bei diesem alle versendeten IDs aller Nutzer und Nutzerinnen verloren gehen würden und eine Identifizierung im Nachhinein nicht mehr möglich wäre. Wie die Belastbarkeit letztendlich zu bewerten ist, hängt von der konkreten Umsetzung dieser Systeme ab, die gegenwärtig noch nicht zur Verfügung steht.

Die Vertraulichkeit bezeichnet die Eigenschaft eines Systems, berechtigte Zugriffe festzulegen und das System vor unberechtigten

Die Dokumente und der Code der App sind über die Open-Source-Plattform Github einsehbar. 16 Die App startete erfolgreich und hat schon innerhalb der ersten Woche rund 10 Millionen Downloads erreicht. Die Maßnahmen zum Zweck der Datensicherheit des Ansatzes 2 des DP-3T-Konsortiums gehen noch über die im Ansatz 1 vorgesehenen Maßnahmen hinaus. Aus Sicht der Datensicherheit wäre daher eine Umsetzung der App nach dem Protokoll des Ansatzes 2 des DP-3T-Konsortiums wünschenswert gewesen. Ansatz 1 ist jedoch im Zusammenspiel mit der Schnittstelle von Apple und Google leichter umzusetzen und daher praktikabler. Auch Ansatz 1 des DP-3T Protokolls erfüllt die Anforderungen der Datensicherheit aus der DSGVO. Eine Veröffentlichung des Quellcode der API wäre jedoch wünschenswert

Covid-19-Contact-Tracing-Apps -Leitlinien des EDSA, ZD-Aktuell 2020

So hilft die Corona-Warn-App

Leitlinien 3/2020 für die Verarbeitung von Gesundheitsdaten für wissenschaftliche Forschungszwecke im Zusammenhang mit dem Covid-19-Ausbruch

Leitlinien 04/2020 für die Verwendung von Standortdaten und Tools zur Kontaktnachverfolgung im Zusammenhang mit dem Ausbruch von Covid-19

Datenschutz im Internet

Bedarf an und Inhalt eines Gesetzes für Corona-Tracing-Apps, ZD-Aktuell 2020

Formularhandbuch Datenschutzrecht

Das neue Datenschutzrecht in der betrieblichen Praxis

/Spiecker gen. Döhmann, I. (Hrsg.), Datenschutzrecht

Europäische Datenschutzgrundverordnung, Handkommentar

Europäische Datenschutz-Grundverordnung

Streit über Datenschutz bei Tracing-Apps, ZD-Aktuell 2020

Tracing-App: Verfassungsrechtliche Grundlagen und Kriterien für ihren Einsatz

Zugriffen zu schützen. 14 Bei der Vertraulichkeit der Daten kommt es darauf an, dass Dritte keinen einfachen Zugriff auf die Daten erhalten. Somit muss sichergestellt werden, dass sowohl die Daten auf dem Server als auch auf dem Gerät ausreichend geschützt sind. Hinzu kommt, dass die Daten auch während der Kommunikation zum Server oder vom Server nicht ausgelesen werden können.Auch hier bietet ein dezentrales System einige Vorteile. Alle IDs (oder, je nach Ansatz, Tagesschlüssel) von Erkrankten, die an den Server gesendet werden, sind öffentlich verfügbar, damit alle Nutzerinnen und Nutzer von Kontaktnachverfolgungs-Apps diese mit ihren empfangenen IDs abgleichen können. Da die IDs pseudonym sind, ist ein Schutz vor Angreifern nicht nötig. Auf dem Gerät sollten alle empfangenen IDs geschützt werden, was jedoch eine Frage der Implementierung der App ist. Diese Frage ist nicht Gegenstand dieses Beitrags. Eine entsprechende Verschlüsselung der Daten auf dem Smartphone ist jedoch ohne weiteres möglich.Da auch vom PEPP-PT-Konsortium keine fertige Lösung vorgestellt wurde, kann auch hier die Einhaltung dieses Kriteriums nicht bewerten werden. Wichtiger ist es ohnehin, einen entsprechenden Schutz der Server zu gewährleisten, auf denen sämtliche von den Nutzerinnen und Nutzern geteilten IDs gesammelt vorliegen. Dazu zählt auch die Geheimhaltung der Zuordnungsregeln, da andernfalls die Pseudonyme aufgelöst und Personen identifiziert werden könnten.Letztlich muss auch der schreibende Zugriff auf den Server geschützt werden. Die App wird die Möglichkeit haben, nach einem positiven COVID-19-Test IDs an den Server zu senden. Daher muss sichergestellt werden, dass es für Angreifer keine Möglichkeit gibt, sich dieser Schnittstelle zu bedienen, um falsche IDs an den Server zu senden, da dies zu falschen Benachrichtigungen führen würde.

Integrität bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Daten (dass die Daten vollständig und unverändert sind) und der korrekten Funktionsweise von Systemen. 15 Dieses Kriterium gilt für jeden Ansatz und kann nicht ohne eine veröffentlichte Softwarelösung validiert werden. Mit Hilfe von verbreiteten kryptografischen Funktionen ist es jedoch möglich, die Einhaltung dieses Kriteriums zu gewährleisten. Ansatz 2 des DP-3T-Konsortiums sieht beispielsweise vor, nicht die initiale, zufällige ID einer infizierten Person mit allen Nutzerinnen und Nutzern der App zu teilen, sondern diese in einen kryptografischen Filter zu integrieren. Durch diesen Filter ist es nicht mehr möglich, neue IDs aus den initialen Werten zu generieren und somit andere Menschen fälschlicherweise zu benachrichtigen.

Die Bundesregierung hat die Unternehmen SAP und Telekom mit der Entwicklung der Corona-Warn-App beauftragt, die auf einer dezentralen Lösung basiert. Dabei werden sie von der Fraunho-