Die Beta der NHS-COVID-19-Kontaktverfolgung ist jetzt sowohl für iOS als auch für Android Open Source, zusammen mit einer Dokumentation. Als Fortsetzung unseres Beitrags „Am Leben bleiben“ haben wir uns den Quellcode genauer angesehen. Es ist eine angenehme Überraschung, dass er unter der MIT-Lizenz steht, was auf ein Bekenntnis von NHSX zu Transparenz und Qualität hindeutet.
In den letzten zwei Tagen haben mehrere Entwickler die App untersucht, um herauszufinden, ob — und wie! — sie am Leben bleibt. Das zu verstehen, erforderte ein tieferes Verständnis des relevanten CoreBluetooth-Frameworks, als die meisten Entwickler es besitzen. Es ist kein Framework, mit dem sich Entwickler typischerweise eingehend befassen müssen.
Ziemlich früh haben wir entdeckt und berichtet, wie der Trick bei Android-Geräten funktioniert. Heute Abend teilen wir, was genau unter iOS passiert. Gehen wir es Schritt für Schritt durch.
Erster Start
Beim ersten Start sendet die App eine PUT-Anfrage an https://api.svc-covid19.nhs.uk/api/devices/registrations mit einem Aktivierungscode, einem Push-Benachrichtigungs-Token und der ersten Hälfte der vom Nutzer eingegebenen Postleitzahl. Als Antwort schickt der Server einen linkingId zurück, der in den Einstellungen der App gespeichert wird.
Die App fragt außerdem, wie zu erwarten, Berechtigungen für Push-Benachrichtigungen und Bluetooth an. Sie fragt keine Standortberechtigungen an und überprüft daher die Postleitzahl des Nutzers nicht. Es werden nur die ersten Ziffern einer Postleitzahl benötigt.
Es gab Behauptungen, die Android-App greife auf Standortdaten zu, da die Abfrage nach Zugriff auf die Bluetooth-API auf Android-Geräten scheinbar Standortberechtigungen verlangt. Das haben wir gestern jedoch widerlegt: Es ist eine Folge davon, wie Android Anfragen nach Bluetooth-Berechtigungen verwaltet.
Am Leben bleiben unter Android
Zu verhindern, dass eine App im Hintergrund einschläft, ist unter Android trivial, da die Standard-APIs diese Funktion unterstützen und Entwicklern Zugriff auf niedriger Ebene auf die Bluetooth-Hardware geben.
Unter iOS ist die Sache jedoch nicht ganz so einfach. Wenn Apps unter iOS in den Hintergrund wechseln, wird ihre Funktionalität erheblich eingeschränkt. Das gilt auch für CoreBluetooth, das Apple-Framework, das Entwicklern Zugriff auf Bluetooth gibt. Ohne einen cleveren Workaround macht das es für die App wesentlich schwerer, iPhones zu erkennen, die möglicherweise im Hintergrundmodus laufen. Wir haben mit mehreren iOS-Geräten getestet, die mehrere Stunden lang unberührt blieben, und festgestellt, dass die Abfragen seltener stattfanden, die Geräte aber trotzdem über Nacht kommunizierten.
Mit Android iPhones aufwecken
Gestern haben wir auch berichtet, dass iOS-Apps im Hintergrund weiterhin Bluetooth-Advertisements senden, aber auf eine andere, Apple-spezifische Weise. Wir vermuteten, dass die Entwickler von NHSX und Pivotal dies per Reverse Engineering nachgebaut und der Android-App Unterstützung dafür hinzugefügt hatten. Wir können bestätigen, dass das der Fall ist, und ihre technischen Details dazu finden sich hier. Das bedeutet: Zusätzlich dazu, dass iOS-Geräte die App im Hintergrund halten können, können Android-Geräte ein „schlafendes“ iOS-Gerät aufwecken, unabhängig davon, wie lange es schon im Hintergrund ist.
Was bedeutet das also? Nun, es heißt, dass ein iPhone, damit die App funktioniert, ziemlich oft in Reichweite eines Android-Geräts sein muss, damit es Keepalives senden kann, um sich selbst im Hintergrund zu halten. Das allein ist vielleicht keine praktikable Lösung, aber ...
iOS-Geräte nutzen, um … andere iOS-Geräte aufzuwecken
In unserem gestrigen Beitrag „Am Leben bleiben“ haben wir berichtet, dass wir glaubten, die iOS-App verwende „Keepalives“, um Hintergrundbeschränkungen zu umgehen. Nach der Untersuchung des Quellcodes der iOS-App sind wir zu dem Schluss gekommen, dass dem tatsächlich so ist. Wie genau funktionieren sie aber?
Einfach gesagt ist ein Keepalive — in diesem Zusammenhang — eine Idee der Entwickler der App: eine Benachrichtigung, die zwischen zwei iOS-Geräten gesendet wird, auf denen die App läuft, um die Verbindung zwischen den Geräten aufrechtzuerhalten. Das Interessante daran ist, dass es auch dazu führt, dass die App deutlich länger wach bleiben kann, denn wenn ein Gerät ein Keepalive empfängt, erlaubt iOS der App, wach zu bleiben, um zusätzliche Verarbeitung durchzuführen.
Praktisch gesehen bedeutet das, dass die App ihren aktiven Zustand aufrechterhalten kann, solange sie sich in der Nähe anderer Geräte befindet. Das ist gewissermaßen der Grundgedanke des COVID-19-Tracing-Projekts: Auch ohne diesen technischen Trick muss eine kritische Masse von Nutzern die Tracing-App einsetzen, um ein gutes Ergebnis für die öffentliche Sicherheit zu erzielen.
Unabhängig davon schläft die App nicht sofort ein und geht in einen angehaltenen Zustand über, wenn sie in den Hintergrund wechselt. Die Frage lautet also, ob die meisten Nutzer sich oft genug in der Nähe von genügend iOS- oder Android-Geräten aufhalten, damit die Workarounds funktionieren. Unserer Ansicht nach ist das wahrscheinlich, umso mehr für Nutzer, die sich regelmäßiger in dicht besiedelten Gebieten aufhalten. Bluetooth hat eine ordentliche effektive Reichweite.
Einige Beobachter haben vermutet, die Fähigkeit der App, stille Benachrichtigungen zu empfangen, bedeute, dass sie diese Funktionen nutzte, um sich aus der Ferne selbst aufzuwecken. Diese Funktionen werden jedoch lediglich dazu verwendet, den Nutzer darüber zu informieren, ob er sich in der Nähe von jemandem aufgehalten hat, der an COVID-19 erkrankt ist. Die App nutzt außerdem lokale Benachrichtigungen, die erkennen, wenn die App vom System beendet wird, und Nutzer anweisen, die App erneut zu öffnen. Eine ähnliche Benachrichtigung wird verwendet, wenn der Nutzer Bluetooth deaktiviert.
Aidan Fitzpatrick, CEO von Reincubate, sagt:
Ja, es stimmt, dass das kommende
ExposureNotification-Framework von Apple in iOS 13.5 diese Keepalives überflüssig macht. Es ist jedoch erwähnenswert, dass:
- iOS 13.5 nicht veröffentlicht ist und es möglicherweise erst in einigen Wochen sein wird
- die letzte iOS-13.5-Beta bis gestern eine schwerwiegende Sicherheitslücke hatte, was darauf hindeutet, dass in Apples Entwicklerteams noch viel Arbeit anfällt
- es nach der Veröffentlichung voraussichtlich Monate dauern wird, bis die Mehrheit der iOS-Nutzer es installiert hat (ungewöhnlicherweise könnte die Verbreitung bei Android schneller gehen)
- ältere iOS-Geräte — wie das iPhone 6 — iOS 13 nicht ausführen können und die Technik von Apple nicht nutzen können werden
- es keinen Grund gibt, warum die NHS-COVID-19-App künftig nicht automatisch auf das Framework von Apple umsteigen könnte — oder sogar beide Mechanismen parallel laufen lassen könnte
Die App wird immer wirksamer, je mehr Menschen sie nutzen, und der Nutzen einer breiten Verbreitung erzeugt in diesem Sinne einen Schwungradeffekt. Die australische COVIDSafe-App tat sich schwer, weil sie das Erkennen von im Hintergrund laufenden iOS-Geräten von einem Android-Gerät aus nicht unterstützte und diesen cleveren iOS-zu-iOS-Keepalive-Mechanismus nicht hatte.
Es ist wichtig zu überlegen, unter welchen Umständen der Einsatz einer solchen Technologie angemessen ist. Wenn die Kontaktverfolgung erfolgreich Leben rettet, nach welchen Kriterien sollte beurteilt werden, ob sie bei künftigen Krankheiten angewendet wird? Sobald der Präzedenzfall geschaffen ist, gibt es dann ein Argument dafür, diese Technologie auch zur Bekämpfung bereits bestehender Infektionskrankheiten einzusetzen? Es ist absehbar, dass verschiedene Gesellschaften die Abwägungen unterschiedlich bewerten werden.
Datenschutzvorkehrungen
Eine detaillierte Analyse der Mathematik hinter dem Protokoll zu schreiben, würde den Rahmen dieses Beitrags etwas sprengen, aber wir haben uns die Datenschutzvorkehrungen angesehen. Die App scheint sich strikt an das vom NCSC veröffentlichte Papier zu halten. Wir können bestätigen, dass keine Schlüsseldaten das Gerät des Nutzers verlassen, bis er Symptome meldet, und erst dann verlassen die anonymisierten Schlüssel von Geräten, mit denen er in engem Kontakt war, das Gerät. Die erste Hälfte der vom Nutzer eingegebenen Postleitzahl wird im Rahmen des Registrierungsdienstes an die API gesendet.
Letztlich deutet der Code darauf hin, dass die Nutzung der App technisch kaum ein Datenschutzrisiko birgt, bis ein Nutzer Symptome meldet und den NHS kontaktiert, um einen Test zu vereinbaren. Zu diesem Zeitpunkt würde sein Testergebnis vom NHS verwaltet, was sich jedoch mit oder ohne die App nicht unterscheidet. Sobald jedoch mehrere Nutzer in Kontakt kommen, Symptome melden und Tests unter Verwendung der Kennung vereinbaren, die die App ihnen zugewiesen hat, kann es möglich sein oder auch nicht, sie zentral miteinander zu verknüpfen. Das ist eine Frage des Back-Ends, und wie NHSX in seinem Datenschutzbericht zur App festhält, ist in dieser Hinsicht der Code die Wahrheit.
Schutz vor falschen Meldungen
Da das Back-End des Systems nicht als Open Source veröffentlicht wurde, lässt sich das nicht bestätigen, aber es scheint, als würden keine Push-Benachrichtigungen an andere Geräte gesendet, bis Bürger positiv auf COVID-19 getestet werden. Sobald ein Nutzer Symptome meldet, erhält er einen Referenzcode, mit dem ein Test gebucht werden kann. (Dieser Code stimmt zufällig mit dem überein, was wir im Abschnitt zur Registrierung als linkingId beschrieben haben.)
