Corona-Warn-App – Welche Daten werden geteilt?

Die nicht-technischen, aktuellen Themen zur Corona-Warn-App habe ich vor einigen Tagen im Artikel Corona-Warn-App Revisited beschrieben. In diesem Artikel will ich etwas technischer auf die App und die zugehörige Infrastruktur schauen.

Mein erster technischer Test mit der Corona-Warn-App war ein einfacher Man-in-the-Middle-Angriff mit Hilfe eines (vorbereiteten) Raspberry Pi als Hotspot und der Software mitmproxy. Die generierten Zertifikate des mitmproxy sind im entsprechenden Test-Handy vom Typ Android auch schon hinterlegt.

Kommunikation mitlesen oder stören

Die Corona-App auf meinem Test-Gerät hat sich geweigert, sowohl mit dem Server svc90.main.px.t-online.de also auch mit dem Server verification.coronawarn.app Verbindung aufzunehmen, solange die Server sich nicht mit dem echten Zertifikat ausgewiesen haben.
Der erste Server ist der für die Verteilung der Keys zu Begegnungen mit Infizierten verantwortlich, im weitesten Sinne also das Content Delivery Network (kurz: CDN) der App. Der zweite Server ist der für den Upload von eigenen Keys bei einem positiven Corona-Test notwendig. Die Fehlermeldungs-Details entsprachen jeweils einem Fehler in der Pfad-Verifikation der Zertifikate.
Der Versuch in Form von einem bösartigen, fälschenden DNS-Server die Verbindungen umzuleiten wurden weitestgehend durch den hartnäckigen Einsatz der Google-DNS-Server innerhalb App verhindert, obwohl der DHCP-Server einen anderen lokalen DNS-Server verteilt hat. Ein Verbindungsaufbau kam nicht zustande, auch wenn der Zugriff auf Google DNS 8.8.8.8 vollständig unterbunden wurde.
Es konnte auch kein Szenario simuliert werden, um ein Upload der App als erfolgreich zu „verkaufen“, obwohl in Wirklichkeit keine Verbindung zustande kam. Jedes mal wurde der Verbindungsaufbau mit einer technischen Fehlermeldung quittiert.
Nach dem im Vorfeld der Veröffentlichung durchgeführten Pentest war ein anderes Verhalten der App auch nicht zu erwarten.

Datenexport aus dem Gerät

Wie sieht es denn jetzt aber mit den Daten aus, die die Corona-Warn-App verwendet? Sowohl auf dem eigenen Telefon als auch auf den Download-Servern? Die Daten in der eigenen App können als JSON-Datei exportiert werden. Auf dem iPhone beispielsweise über Einstellungen / Datenschutz / Health / COVID 19 Begegnungsaufzeichnungen / Begegnungsüberprüfungen / [ PIN eingeben ] / (ganz unten) Begegnungüberprüfungen exportieren. Diese nun generierte Datei kann man sich dann beispielsweise per Mail selbst zuschicken oder anderweitig über die üblichen Möglichkeiten sharen.

Diese Datei hat unter iOS folgendes Format (gekürzt an …):

{
  "Build": "17G68",
  "ExportVersion": 1,
  "ExposureChecks": [
  {
    "Hash": "D7F52D05797DE8A3E4F11F30B371431230F461B3D69E88A0DA88173131C763B7",
    "RandomIDCount": 200,
    "MatchCount": 0,
    "DataSource": "de.rki.coronawarnapp",
    "Timestamp": "2020-07-16 21:52:14 +0200"
  },
  {
    "Hash": "638C8E711B63D8A99D6EA597F0359921FAE894B029C6DA7D08E56B15C764D17E",
    "RandomIDCount": 440,
    "MatchCount": 0,
    "DataSource": "de.rki.coronawarnapp",
    "Timestamp": "2020-07-16 21:52:14 +0200"
  },
  …
  }
  ],
  "DeviceProductType": "iPhone8,4"
}

Diese Daten entsprechen den entsprechenden Zufallswerten für die verschiedenen Begegnungen. Alle hier aufgelisteten Daten sind außerhalb des relevanten 14-Tage-Zeitraums, sodass auf eine Anonymisierung verzichtet wurde.

Die Android-Exporte sehen etwas anders aus:

{
  "timestamp": "July 23, 2020 15:17",
  "keyCount": 0,
  "matchesCount": 0,
  "appName": "Corona-Warn",
  "hash": "lLj+nNfIDIVKqrwIRv6+7ohsUzZBLpssSdEicl+wonY="
}

Hier ist der Hash als Base64 codiert und nicht als Hex-Wert, das sind das reine Themen der Repräsentation. Aus Sicht einer Genauigkeit fehlt mir hier an dieser Stelle eine zuverlässige Definition der Zeitzone, also die Information ob es sich um einem lokalen Zeitstempel oder einen in UTC handelt. Im Export unter iOS ist hier die vollständige Definition gegeben.

Das sind jetzt die Werte, wie die lokale App sie vorhält, es handelt sich nicht um die Temporary Exposure Keys. Es handelt sich um 32 Byte-Werte, die die Basis für einen Abgleich mit den Temporary Exposure Keys anderer Apps ermöglichen. Das darunterliegende Verfahren ist in der krypographischen Spezifikation von Apple und Google beschrieben. Es wird an dieser Stelle auch nicht geprüft, was wirklich im System, in den verschlüsselten SQLite-Datenbanken, gespeichert ist, sondern nur die Daten, die über die offizielle Export-Schnittstelle erreichbar sind.

Daten in Content Delivery Network

Wie sehen jetzt die Daten aus, mit denen diese lokalen Daten  verglichen werden?
Da die Entwicklung der Server-Software auch als OpenSource vorangetrieben wird, lässt sich auch diese Information entsprechend recherchieren.
Unter  https://svc90.main.px.t-online.de/version/v1/diagnosis-keys kann ich die aktuellen Diagnose-Keys herunterladen, der genaue Pfad für alle existierenden Daten ergibt sich nach auslesen des weiteren Pfades /country/DE/date:

curl -s -o- https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/DE/date | jq -r .
[
  "2020-07-22",
  "2020-07-23",
  "2020-07-24",
  "2020-07-25",
  "2020-07-26",
  "2020-07-27",
  "2020-07-28",
  "2020-07-29",
  "2020-07-30",
  "2020-07-31",
  "2020-08-01",
  "2020-08-02",
  "2020-08-03",
  "2020-08-04"
]

Das jq wird in diesem Fall nur zur lesbaren Darstellung der JSON-Datenstruktur eingesetzt. Es handelt sich einfach um eine Liste der letzten 14 Tage, da momentan nicht davon auszugehen ist, dass es Tage ohne Infektionsmeldung gibt.

Das Herunterladen eines Tages-Archivs ergibt sich dann mittels folgendem Befehl:

curl -s -odayX.zip https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/DE/date/2020-08-03
unzip -l dayX.zip 
Archive:  dayX.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
    49446  08-04-2020 00:05   export.bin
      134  08-04-2020 00:05   export.sig
---------                     -------
    49580                     2 files

Im zip-File sind zwei Dateien archiviert, die einmal die Diagnose-Daten und eine zugehörige Signatur enthalten. Die bin-Datei enthält die Datenstruktur im Format eines Google protobuf, wie sie auch direkt im in der Spezifikation von Google und Apple oder im Quellcode der Apps und Komponenten nachlesbar ist. Eine vereinfachte Decodierung führt zu folgenden Informationen, jetzt wieder von einem anderen Tag außerhalb des 14-Tage-Fensters:

unzip -qq -x -c dayY.zip export.bin | ./protobuf.pl | head
key_data transmission_risk_level rolling_period rolling_start_interval_number
008edc9ec9d97f30dd06b3a58dcd969c 3 144 2657808
009d46cd1944f4d9810d7e153f8bd82e 1 144 2657520
00e037b9dfae95ec388300cb868780ac 5 144 2657952
00fe13850d8c905f9bd1797c132c8ef1 1 144 2657520
03267a1b73366e3f6ac595d0efaeb8fc 6 144 2658528
03520d2cddd9dca048c2f517e28d14bf 3 144 2657808
036f4a87fee8ee659b46735f55e22d02 1 144 2657232
04147c140ec1142ee14694c84392235c 8 144 2658384
046add54f6c16c49c9f6420c5aa75d7c 1 144 2657376
054badcdb5b1fb1edb25d545ca9d8ee3 1 144 2657664

Die Auflistung erfolgt mittels eines einfachen Tools zum Lesen der protobuf-Strukturen und eine Ausgabe als Liste mit den entsprechenden Spalten.

Die wichtigsten Elemente dieser Struktur sind die Keys, die sogenannten Temporary Exposure Keys. Diese 16 Byte großen Temporary Exposure Keys, hier als 32-stellige Hexwerte aufgelistet, müssen von jedem Gerät individuell mit einer AES128-Operation gegen die lokal gespeicherten Informationen abgeglichen werden. Passt einer der Keys, basierened auf Zeitstempeln und Alter, zu dem Temporary Exposure Keys, wird der entsprechende Warnhinweis aus der App generiert. Diese Temporary Exposure Keys werden im Falle einer Corona-Infektion an die zentrale Infrastruktur übergeben und dann eben an alle anderen Apps übertragen. Zusätzlich benötige ich jetzt noch die Informationen über die lokale Bluetooth-Adressen, um die Werte entsprechend abzugleichen. Diese sind nur auf dem entsprechenden Gerät enthalten.

Hält die App nun was sie verspricht?

Die offiziell bereitgestellten und ausgetauschten Daten halten technisch das, was die Entwickler der App und der API versprochen haben. Es existieren keinerlei Geo-Informationen noch IP-Adressen oder sonstige Informationen in den ausgetauschten Daten. Die Kommunikation ist auch entsprechend abgesichert, so dass Angriffe auf die Kommunikations-Verbindungen auch unwahrscheinlich sind.

Aus technischer Sicht wurde damit das Ziel eines maximalen Datenschutzes erreicht. Es lassen sich weder Kontakte noch Bewegungsprofile anhand der Tracing-Daten ermitteln. Aktuelles analoge Begleit-Prozesse wie die teleTAN höhlen diesen Datenschutz noch aus, mittelfristig soll hier aber eben eine vollständige Digitalisierung stattfinden.

Offen bliebe jetzt noch zu prüfen, was ein Angreifer mit Zugriff auf Speicher und Dateien auslesen und auswerten könnte, also beispielsweise verschiedene Typen von Android-Malware. Dieser Angreifer ist aber möglicherweise gar nicht an Exposure-Notification-Daten interessiert sondern viel mehr an Banking-PINs oder TANs.

Weitere Informationen:

Bericht zur Datenschutz-Folgenabschätzung für die Corona-Warn-App
(PDF, Stand Version 1.0.1, 18.06.2020, nicht barrierefrei)
Quelle: Bundesregierung Deutschland

FAQ CWA: Ist ein datenschutzkonformer Umgang mit den Nutzerdaten möglich?

FAQ CWA: Was wird genau gespeichert und wer kann auf die über Bluetooth gesammelten Daten zugreifen?

Weitere FAQ auf der Projekt-Webseite coronawarn.app in der Rubrik Datenschutz und Sicherheit