Ein erster Blick auf Apple’s Privacy-Preserving Contact Tracing

Letzte Woche noch hatte Frank Thelen im ZDF bei Lanz „gehofft“, Pandemie Contact Tracing wäre eine Chance für Technologie aus Europa. Heute dann die Ankündigung von Apple und Google: Privacy-preserving Contact Tracing kommt von den Herstellern der beiden wichtigsten mobilen Plattformen aus Amerika und als integraler Bestandteil der Betriebssysteme.

Hier ist mein erster Eindruck von Apples Spezifikation:

1. Die vorgeschlagene Implementierung ist sehr nah an bekannten Überlegungen wie DP-3T und wirkt überzeugend. Der zentrale, nutzerbezogene Schlüssel wird sicher in der Secure Enclave gespeichert. Dort ist er vor dem Zugriff durch Apps und Dritte geschützt.
   
   Das System erzeugt täglich wechselnde Tages-Identifier, von denen wiederum im 10-Minuten-Interval neue Identifier erzeugt werden, die dann per Bluetooth ausgesendet werden. Diese Rolling Proximity IDs sind es, die von anderen Geräten gesehen und aufgezeichnet werden. Alles das macht das Operating System selbst, es ist für Apps eine Blackbox, sie sehen davon nichts. Der Nutzer muss das Verfahren aktiv einschalten. (Ob Apps einen Betriebssystem-Dialog dazu anstoßen können, oder der Nutzer in den Einstellungen die Funktion aktivieren kann, ist offen. Erfahrungsgemäß ermöglicht Apple beides.)
   
   
2. Im Infektionsfall kann eine App die Tages-IDs der letzten 14 Tage beim Betriebssystem anfordern. Der Nutzer muss manuell zustimmen, damit die Tages-IDs vom Betriebssystem an die App weitergereicht werden. Diese Notwendigkeit zur Zustimmung wird vom Betriebssystem erzwungen und überwacht; man kennt den Ablauf zum Beispiel von der Zustimmung zur Nutzung des Standortes.
   
   Stimmt der Nutzer zu, liefert das Betriebssystem außerdem zusätzlich zu den Tages-IDs der letzten 14 Tage 14 weitere Tage lang im Hintergrund die jeweilige Tages-ID an die App aus.
   
   Diese Tages-IDs werden auf einen Server hochgeladen. Der Server erhält so also im idealen Fall die Tages-IDs des infizierten Nutzers für einen Zeitraum von 28 Tagen.
   
   
3. Apps laden ebenfalls in regelmäßigen Intervallen alle Tages-IDs infizierter Nutzer vom Server auf das lokale iOS Gerät.
   
   
4. Will man überprüfen, ob eine der Rolling Proximity IDs, die man selbst via Bluetooth “gesehen hat”, in deren Nähe man sich also befand, in Verbindung mit den heruntergeladenen Tages-IDs von infizierten Nutzern steht, gibt die App die heruntergeladenen Tages-IDs in Blöcken an das Betriebssystem weiter. Das Betriebssystem leitet von diesen die ursprünglichen Rolling Proximity IDs ab und führt die Überprüfung durch. Diese Überprüfung erfolgt in einer Blackbox lokal auf dem Gerät, ist aber von Apple beschrieben.

Soweit liest sich das erst einmal gut. Einige Anmerkungen:

• Die Spezifikation bezieht sich zunächst einmal nur auf das, was auf dem Gerät passiert. Über die Plattformen, welche die Tages-IDs entgegennehmen und verteilen enthält sie keine Details. Ihre Realisierung und Betrieb bleiben Aufgabenstellungen für Dritte. Gleiches gilt für den von der App zu implementierenden Up- und Download-Mechanismus und ggf. Sicherheitsanforderungen an diesen.
  
  
• Das Verfahren mit dem Nutzer sich als nachweislich infiziert ausweisen ist nicht spezifiziert. Es wird wohl in jedem Fall eine Bestätigung von einer offiziellen Gesundheitsbehörde Anwendung finden, zum Beispiel die Eingabe einer TAN durch den Nutzer, welche nur von den Behörden ausgehändigt wird, um einen positiven Test zu bestätigen.
  
  
• Da die Tages-IDs keinerlei Länderkennung beinhalten, müssen für den Aufbau eines effizienten föderalen Systems, bei dem zum Beispiel inländische Identifier vorrangig synchronisiert werden sollen, individuelle Absprachen zwischen Ländern getroffen werden. In der Spezifikation von Apple wird den Betreibern von Servern das Speichern von Meta-Informationen zu den Identifiern allerdings explizit untersagt.
  
  
• Eine Liste mit Identifiern für 1. Mio. infizierte Benutzer wird nach meinen Berechnungen mindestens ca. 450 MB Datenübertragung vom Server an das lokale Gerät erfordern. (Ohne dass ich an dieser Stelle Optimierungspotential ausgelotet hätte.)
  
  
• Ich gehe davon aus, dass Apple den Zugriff auf diese neuen APIs sehr restriktiv vergibt. Die Prozesse und Infrastruktur für diese Art von kontrolliertem Funktionszugriff gibt es bereits, unter anderem für Apple Car Play.
  
  
• Die umfangreichere Ankündigung von Google deutet an, dass beide Unternehmen vielleicht mittelfristig auch den Plattform-Teil anbieten werden. Bei Apple könnten also iCloud und Apple Health erweitert werden.
  
  
• In Google’s Statement wird konkret der Mai 2020 als frühestes Datum für die Verfügbarkeit dieser Funktionen genannt, was die Frage aufwirft, was die von PEPP-PT Initiator Chris Boos bereits für nächste Woche angekündigte App macht, und wie sie die Restriktionen insbesondere von iOS umgeht.
  
  Eventuell ist die Verschwiegenheit von PEPP-PT bezüglich dieser Details auch Folge strenger Geheimhaltungsvereinbarungen mit Apple (NDA), wie man das von Apple gewohnt ist. Das wäre jedoch hinsichtlich Vertrauensbildung eine kommunikative Katastrophe. Denn wenn eine PEPP-PT App bereits Contact Tracing Erweiterungen des Betriebssystems nutzen würde, die für Mai angekündigt sind, hätte man uns diese quasi “untergeschoben”.

Die heutige Ankündigung ist eine gute Nachricht.

Ohne die Unterstützung von Apple und Google auf der Ebene des Betriebssystems hätte sich das Thema nur sehr eingeschränkt umsetzen lassen.

Der kritische Blick auf die Server-Implementierungen bleibt weiterhin angebracht, denn auch Apple sieht ein Risiko und beschreibt dies in der Spezifikation so:

A server operator implementing this protocol does not learn who users have been in proximity with or users’ location unless it also has the unlikely capability to scan advertisements from users who recently reported Diagnosis Keys.

Apple Inc.

Ein Angriffsszenario übrigens, welches ich hier ebenfalls gesehen habe.