CoraLibre – Die Google-freie Corona-Warn-App

Kurz & knapp: Worum geht’s?

• Verbesserter Datenschutz durch Contact Tracing ohne Google Play Services. 
• Hardware-nahe Entwicklung am Smartphone. 
• Wie man eine App als Foreground-Service etabliert. 
• Die Google Play Services sind eine Black-Box. Reverse Engineering hilft. 
• Sicherer Austausch von Daten via Bluetooth Low Energy. 
• Der Corona-Warn-App Fork ist ein nachhaltiges Upstream-Projekt.

---

Die Pandemie hat unser Vokabular enorm erweitert. Begriffe wie Lockdown, Super Spreader oder auch Contact Tracing fanden Eingang in unseren Wortschatz und sind seither nicht mehr wegzudenken. Das Contact Tracing ist ein probates Mittel, die Ausbreitung des Virus’ einzudämmen. Hierfür gibt es sogar eine App von der Bundesregierung - Die Corona-Warn-App (CWA) informiert ihre Nutzerinnen und Nutzer, wenn sie Kontakt zu einer positiv getesteten Person hatten. Doch wie funktioniert das technisch? Wir haben im Rahmen des Förderprojektes Distr@l vom Digitalministerium Hessen die CoraLibre-App als Fork der offiziellen CWA nachgebaut, ohne Google Services zu verwenden. Hier erklären wir, welche Hürden wir dabei nehmen mussten und wie wir die einzelnen Google Services nachbauten, um eine effiziente Kontaktnachverfolgung sowie die Kompatibilität mit der offiziellen App zu gewährleisten, ohne Google Services zu verwenden. Welche Hürden räumten wir dabei aus dem Weg? Und wie haben wir die einzelnen Google Services nachgebaut, um eine effiziente Kontaktnachverfolgung sowie die Kompatibilität mit der offiziellen App zu gewährleisten? Antworten auf all diese Fragen finden sich in diesem Artikel. 

Genaueres über unseren Weg zum CoraLibre-Projekt gibt es unter Was wir Softwareentwickler gegen die Pandemie tun.

Wie funktioniert das Contact Tracing? 

Beim Contact Tracing verfolgt die App Begegnungen mit anderen Geräten und zeichnet sie auf. Dafür sendet sie via Bluetooth permanent ungerichtet Daten nach außen. Gleichzeitig sucht sie nach anderen aktiven Geräten mit einer Contact Tracing App in einem festgelegten Umkreis von wenigen Metern. Hat sie eine App gefunden, beginnen die Geräte, Daten voneinander aufzuzeichnen: Die wichtigsten Informationen sind die Dauer der Begegnung sowie der Abstand zueinander, also die Signalstärke. Halten sich also zwei Personen mit aktiven Contact Tracing Apps über einen längeren Zeitraum nah genug beieinander auf, tauschen die Apps eben jene Informationen aus und speichern sie lokal auf dem Smartphone ab. Hat nun eine der beiden Personen Symptome des Corona-Virus‘ und erhält ein positives PCR-Testergebnis, übermittelt sie dieses an die Kontaktverfolgungs-App. Daraufhin erhalten all die Geräte, die Codes mit der App der infizierten Person getauscht haben, eine Mitteilung, dass sie eine Risikobegegnung hatten. Dabei bleibt die Person selbst anonym, die App versendet keine personenbezogenen Daten. Die gewarnten Personen können nun entscheiden, ob sie einen Arzt aufsuchen, einen Test machen oder sich in häusliche Isolation begeben. So verhindert die App eine unkontrollierte Ausbreitung des Virus.

Was sind die Google Play Services? 

Die Google Play Services sind Hintergrunddienste auf Android-Geräten. Sie vereinfachen die Entwicklung am Smartphone, indem sie das Betriebssystem bei vielen Server-lastigen Aufgaben unterstützen. So sind sie beispielsweise für die Synchronisierung von Kontakten, den Zugriff auf die aktuellen Datenschutzeinstellungen der Nutzerinnen und Nutzer und weitere Vorgänge auf dem Smartphone verantwortlich. Man findet sie obligatorisch auf jedem Android Smartphone, das ein Google-Konto verwendet.  

Warum nutzt die offizielle Corona-Warn-App Google Play Services? 

In der iOS-Welt hat ein Update des Betriebssystems alle Smartphones befähigt, die für das Contact Tracing notwendigen systemimmanenten Services wie Bluetooth Low Energy und die Schnittstelle für die Übertragung der Codes zu nutzen. Bei Android-Smartphones sah das anders aus, da die Gerätehersteller zunächst eigenständig für die Updates der Betriebssysteme verantwortlich waren. So kam es zu unterschiedlichen Versionsständen auf Geräten unterschiedlicher Hersteller und nicht alle Android-Nutzerinnen und -Nutzer konnten auf alle notwendigen Services zugreifen. Die Google Play Services ermöglichen eine automatische Aktualisierung der systemrelevanten Services ohne Zutun der Hersteller oder der Nutzerinnen und Nutzer. Die Aktualisierung dieser Dienste erfolgt durch Google selbst, auch außerhalb der normalen Betriebssystem-Updates. Daher wurden die Google Play Services für Android-Geräte innerhalb der Contact-Tracing-API integriert. 

Warum die Google Services dadurch mehrere Millionen Android-Nutzerinnen und –Nutzer vom Contact Tracing ausschließen, lest ihr hier.

Wie wir es geschafft haben, alle relevanten Google Play Services aufzuspüren & ohne Google nachzuimplementieren. 

Mit CoraLibre realisierten wir ein Contact Tracing, für das Google Services nicht notwendig sind. Dazu haben wir jeden Google Play Service einzeln unter die Lupe genommen, seine Funktionsweise studiert und die interne Kommunikation auf dem Smartphone nachvollzogen. Da es sich bei den Google Play Services um unzählige APIs handelt, haben wir zunächst identifiziert, welche Teile der Google Play Services die CWA nutzt. Im nächsten Schritt bauten wir jeden Service einzeln aus und implementierten ihn eins zu eins für die CWA Fork nach. 

Was simpel klingt, ist tatsächlich hochkomplex. Ein Upstream-Projekt dieser Größenordnung, bei dem der Nachbau exakt dem Original entsprechen muss, forderte enorme Konzentration und Ingenieurskunst unserer Entwicklerinnen und Entwickler.

Neben einigen kleineren Services haben wir drei große Services nachgebaut, die allerdings nicht klar voneinander abgrenzbar sind. Einige Services konnten wir einfach durch Open-Source-Lösungen ersetzen, die nichts mit Google zu tun haben und verhältnismäßig einfach zu implementieren waren, z.B. eine alternative Datenbanklösung. Für einige dieser Anwendungsteile gab es gut angelegte Dokumentationen, aus denen wir schöpfen konnten. Die Schnittstellen sind öffentlich und können vergleichsweise einfach eingebunden werden, indem man ein Java Interface programmiert, das dem der Google Play Services gleicht. Auf der anderen Seite sind die Google Play Services eine Blackbox. Es ist klar, welche Daten hineinfließen und wie sie wieder herauskommen. Doch was dazwischen mit ihnen geschieht, ist nicht ersichtlich, da der Quellcode der Schnittstellen nicht einsehbar ist. Nicht alle funktionalen Eigenschaften der APIs sind über die Dokumentation nachvollziehbar und mussten dennoch nachgebaut werden, wie beispielsweise bei der Task API. Wenn man die Kontaktverfolgungs-API aufruft, werden Teile der Task API benutzt, um eine Antwort zurückzugeben. Oberflächlich war zwar einsehbar, welche Parameter die einzelnen Methoden bekommen und was sie zurückgeben. Wie aber das Zusammenwirken unter der Haube funktioniert, war nicht dokumentiert. Wir mussten also mit Reverse Engineering an die Services ran… 

Reverse Engineering beschreibt im Wesentlichen die Analyse eines bestehenden Systems. Sinn und Zweck ist, Rückschlüsse auf die Funktions-, Design- und Fertigungsprinzipien der identifizierten Systemkomponenten zu ziehen. Mit dem aus diesem Prozess erlangten Wissen über Einzelkomponenten lässt sich das System nachbilden. Der Prozess basiert auf Trial & Error. Man prüft das Verhalten der originalen API, indem man unterschiedliche Argumente übergibt und testet, was dabei herauskommt. Diesen Vorgang wiederholt man systematisch so lange, bis sich die Implementierung am Ende genauso verhält wie das Original. Dabei ist einiges an Kreativität und Durchhaltevermögen gefragt. 

Wie in der Originalvorlage musste auch bei der CoraLibre-App eine gewisse Kapselung der Daten stattfinden. Denn bei Begegnungsdaten mit anderen Menschen handelt es sich um vertrauliche und persönliche Daten, die es zu schützen gilt. Wenn die App die über Bluetooth gesammelten Codes der letzten zwei Wochen anfordert, wird der Nutzer durch die Contact Tracing API nach seiner expliziten Einwilligung gefragt. So wird verhindert, dass die App Codes ohne Zustimmung versendet. Die Einwilligung des Nutzers haben wir daher auch beim CoraLibre-Nachbau eingebunden. 

Google Play Service: Contact Tracing API 

Die offizielle CWA nutzt eine Contact Tracing API, die in Zusammenarbeit von Google und Apple entstanden ist. Google und Apple geben mit ihren Betriebssystemen einen gewissen Standard in der Mobile-Welt vor und bieten auch rund um mobile Entwicklung ganzheitliche Lösungen an. Mit dem Google/Apple Exposure Notification Framework (GAEN) stellen sie eine API bereit, die den Austausch von Zufallsschlüsseln über Bluetooth Low Energy ermöglicht. Das hat gleich mehrere Vorteile: 

1. Hätte jedes Land seine eigene Logik entwickelt, hätten die Apps mit hoher Wahrscheinlichkeit nicht untereinander funktioniert. Dadurch, dass sie nur die bereitgestellte API in ihre Kontaktverfolgungs-App einbinden mussten, reduzierte sich die Gefahr von Kompatibilitätsproblemen. 
2. Menschen vertrauen ihrem eigenen Gerät tendenziell eher als einer App, die von ihrer Regierung bereitgestellt wurde. Wenn ein bekanntes Tech-Unternehmen den Hauptteil der Implementierung vorgenommen hat und somit gewährleisten kann, dass die Daten dezentral, unabhängig und nicht nachverfolgbar vom Staat gespeichert werden, ist das deutlich vertrauenerweckender. 

Wie bei der CWA ist das Kernstück der CoraLibre-App die Contact Tracing API. Zunächst willigt die Nutzerin oder der Nutzer in die Aktivierung der Kontaktverfolgung ein. Die Google Play Services nehmen dabei technisch die Rolle der Vermittler zwischen den Geräten ein. Wenn man also anderen Menschen auf der Straße begegnet, passiert dabei der Austausch von Schlüsseln. Diese werden zur Kontaktverfolgung im Nachhinein benötigt.

Der heimliche Foreground-Service 

Contact Tracing Apps erfüllen nur ihren Zweck, wenn sie die Funktion haben, rund um die Uhr im Hintergrund mitzulaufen. Sobald die App inaktiv ist, geht die Gerätekommunikation verloren. Das war in der Vergangenheit der Hauptkritikpunkt an einigen Contact Tracing Apps anderer Länder. Denn was nutzt eine App, die immer geöffnet bleiben, und bei der das Smartphone durchgehend entsperrt bleiben muss? 

Normalerweise können Apps nicht im Hintergrund weiterlaufen. Solche Background-Services werden betriebssystemseitig stark eingeschränkt, um Ressourcen zu schonen. Denn Smartphones haben im Verhältnis dazu, was sie heutzutage leisten müssen, wenig Rechenkapazität. Die Google Play Services API hat für diesen Fall eine Lösung integriert, die einer App ermöglicht, als Background Service zu gelten. Dadurch bleibt die CWA energie- und ressourcensparend im Hintergrund aktiv und wird betriebssystemseitig nicht deaktiviert.

Wie etabliert man eine App als Foreground-Service?

Ist die App im Hintergrund aktiv, muss sie sowohl visuell für den Nutzer am Endgerät als auch für das Betriebssystem sichtbar bleiben. Das lässt sich mit einer dauerhaften Banner-Benachrichtigung realisieren, wie sie beispielsweise bei Google Maps während der Navigation zu finden ist. Solange die Benachrichtigung angezeigt wird, gilt die App als Foreground-Service und wird nicht vom System ausgeschaltet, sondern bleibt laufend aktiv.

Um CoraLibre ohne Googles vorgefertigte Lösung als Foreground-Service zu etablieren, haben wir den Prozess von Grund auf nachgebaut. Weicht man nur leicht von der Dokumentation ab, gilt die App als Background-Service mit geringerer Priorisierung und es kommt zu systemseitigen Problemen. Einerseits wird die App einfach ausgeschaltet. Andererseits werden auch Ressourcen, wie der Akkuverbrauch, gedrosselt. So wird beispielsweise die Verwendung von Bluetooth eingeschränkt. Nicht nur um dauerhaft aktiv zu sein, sondern auch für die Nutzung von Bluetooth war die Etablierung der CoraLibre-App als Foreground-Service zwingend notwendig. 

Schlüsselaustausch via Bluetooth Low Energy

Die Datenübertragung passiert via Bluetooth Low Energy mithilfe einer Broadcast-Funktion. Auf dem einfachsten Level fordert man zunächst Zugriff auf eine Bluetooth-Verbindung an, woraufhin die gewünschten Informationen gebroadcastet werden. Beim Broadcast-Modell schicken Geräte regelmäßig ein Signal nach außen und sammeln unspezifisch adressierte Daten von anderen Geräten. Bluetooth Low Energy ermöglicht eine stromsparende Umsetzung dieses Vorgangs: Die Daten werden mit niedriger Sendestärke übertragen, weil sie für Geräte in unmittelbarer Reichweite bestimmt sind. Bluetooth Low Energy ist hierbei das Kommunikationsmittel für die Übertragung der Daten, welches im Betriebssystem verankert ist. 

Im Kern unserer Arbeit an CoraLibre haben wir uns mit dem Schlüsselaustausch über Bluetooth beschäftigt. Das bedeutet, dass Smartphones via Bluetooth miteinander kommunizieren, während ein App-Algorithmus das Infektionsrisiko berechnet. Für den Aufbau dieses äußerst komplexen Protokolls, mussten wir vor allem die Dokumentation von Apple/Google nachvollziehen. Entscheidend hierbei war es, streng nach den Vorgaben des Protokolls vorzugehen, um den Prozess des Schlüsselaustauschs via Bluetooth exakt abzubilden, sodass die CoraLibre-App mit anderen Contact Tracing Apps kompatibel ist. Andernfalls hätten wir eine Insellösung programmiert, die genau die Nutzerinnen und Nutzer wieder ausschließt, denen wir eine Kontaktverfolgung mit der Alternative CoraLibre zugänglich machen wollten. Neben der Frage, wie die Schlüssel generiert werden, haben wir uns auch um die Art der Verifizierung und die sichere Speicherung der Daten gekümmert.

Welche Daten werden gesendet bzw. empfangen?

Das mit Abstand herausforderndste Gebiet des CoraLibre-Projekts begegnete uns bei der Übertragung der Daten. Welche Daten dürfen im Prozess gesendet bzw. empfangen werden? Wohin werden sie geschickt? Wie müssen sie verschlüsselt werden und braucht man bestimmte Daten überhaupt zur Kontaktverfolgung? Hier beginnt der Weg durch die Untiefen der Kryptografie. 

Um die Privatsphäre zu stärken, nutzt das Schlüsselschema Protokoll, ein Konzept namens Rolling Proximity Identifiers. Die Basis bildet der Temporary Exposure Key (TEK), der täglich neu generiert wird. Aus dem TEK und einer Tagesintervallnummer wird der Rolling Proximity Identifier Key (RPI) abgeleitet. Dieser Schlüssel identifiziert Sender im Umkreis und ermöglicht die Ermittlung der Kontaktdauer. Bei dem sogenannten Associated Encrypted Metadata Key (AEM) handelt es sich um verschlüsselte Metadaten, die den Benutzer nicht persönlich identifizieren. Die AEM-Daten sind mit den RPI-Daten verknüpft und Teil der Payload. 

Eine Payload, auch genannt Nutzdaten, sind transportierte Daten eines Datenpakets, die keine Steuer- oder Protokollinformationen enthalten. Diese versendeten Daten können unter anderem Sprache, Text, Zeichen, Bilder und Töne sein. Die aus RPI und AEM generierte Payload kann den Benutzer nicht persönlich identifizieren. Die Payload verändert sich in etwa alle 10 Minuten, damit ein Gerät nicht permanent die gleichen Daten versendet. Dadurch sind Aufenthaltsorte von Einzelpersonen nicht rückverfolgbar. 

Der Clou an der Sache: In dem Moment, wenn die Payload verschickt wird und andere Nutzer diese empfangen, kann niemand etwas mit den Daten anfangen. Die Verteilung der Schlüssel erfolgt über einen Server. Die Schlüssel werden nur im Erkrankungsfall und mit expliziter Einwilligung des Nutzers an den Server übertragen. Entsprechend kann der Server ausschließlich diese Schlüssel an alle Clients verteilen. Der Server weiß dabei nicht, welche Art Schlüssel er verschickt, weil die Berechnung der Kontakte lokal auf dem Handy erfolgt. Dadurch sind die Daten sind so gut verschlüsselt, dass keinerlei Rückschlüsse zur Identität eines Nutzers gezogen und auch keine Standortbewegungen aufgezeichnet werden können. Aufgrund dessen konnten wir die CWA-Server des RKI ohne Bedenken für das CoraLibre Projekt nutzen.

Weg der Payload vom CWA-Server an Gerät:
Der CWA-Server schickt die Schlüssel aller positiv getesteten Personen an das Endgerät. Dort wird ein Abgleich der Schlüssel in der Datenbank vorgenommen: Das Endgerät hat beispielsweise Payload 1, 5 und 8 via Bluetooth empfangen. Diese gesammelten Payloads werden mit den Schlüsseln des CWA-Servers abgeglichen. Nur wenn ein RPI in der Datenbank vorhanden ist, werden zugehörige Metadaten entschlüsselt. Auf Basis dessen wird rückverfolgt, ob man eine der positiv getesteten Personen getroffen hat. Das Ergebnis sehen die Nutzerinnen und Nutzer in der App.

Weg der Payload vom Gerät an CWA-Server:
Positiv getestete Personen teilen der CoraLibre-App das Testergebnis mit und laden dadurch bestimmte Daten auf den CWA-Server hoch. Daraufhin werden alle benachrichtigt, die diese Person getroffen, und entsprechend ihre Payload empfangen haben. Die CoraLibre-App lädt automatisch die Schlüssel der Erkrankten lokal herunter. Anhand der Payloads der letzten 14 Tage wird ermittelt, ob eine Risiko-Begegnung stattgefunden hat.

Upstream-Projekt am Kern  

CoraLibre ist eines der komplexesten und größten App-Projekte, an denen wir bis dahin gearbeitet hatten. Trotz der vielen Unbekannten haben wir die CWA Fork vollständig nachgebaut, um Menschen ohne Google Services die Kontaktverfolgung zugänglich zu machen. Dabei konnten wir unser technisches Know-how voll ausschöpfen: Indem nur eine einzelne Komponente entfernt wurde, haben wir einen nachhaltigen Upstream-Prozess geschaffen, der alle Updates des Originals erhält. Solange sich nichts an der Interaktion zwischen der CWA und den Google Services ändert, bleibt CoraLibre immer auf dem neusten Stand.

Das Besondere an diesem Projekt ist, dass der maßgebliche Anteil der Business Logic auf dem Smartphone stattfindet. Während bei den meisten App-Vorhaben mehr oder weniger intelligente Clients für Web-Services eingesetzt werden, ist es bei CoraLibre genau andersherum. Hier bilden die Server lediglich ein intelligentes Archiv, auf dem die Daten als Zwischenstation gelagert werden. 

Standard-Apps sind zum Großteil Frontend-Arbeit. Hier und da stellen Entwickler eine Verknüpfung zu Gerätefunktionen wie der Kamera her oder setzen einen Server auf. 

Noch nie war so viel Backend-Expertise für eines unserer App-Entwicklungsprojekte gefragt. Wir haben CoraLibre als Foreground-App etabliert. Beinahe jeder Entwicklungsschritt entsprach einer wohldurchdachten Sonderlösung, wie beispielsweise der Einsatz von Bluetooth Low Energy als Kommunikationsmittel für den Schlüsselaustausch. Die Google Play Services sind tief mit der Hardware des Smartphones verankert. Mit CoraLibre sind wir weit in der hardwarenahen Mobile-Entwicklung vorangeschritten und haben dabei viel Backend-Entwicklung betrieben. 

Je näher die Mobile-Entwicklung an der Hardware stattfindet, desto schwieriger wird die Überprüfung der Arbeit. Für diese letzte Hürde waren wir auf die Mithilfe unserer Community angewiesen, weil unsere Ressourcen als mittelständisches Unternehmen begrenzt sind. Wir können z.B. nicht die nötige Vielfalt an Android-Geräten bereitstellen. Daher haben wir nach Abschluss der Entwicklung einen Aufruf an die Community gestartet, um die Alphaversion der CoraLibre-App zu testen. Zu der geplanten Veröffentlichung auf dem F-Droid Store kam es nicht, da die Testphase nicht finalisiert wurde. Es hat sich gezeigt, dass Open-Source Projekte eine differenzierte Art von Projektmanagement erfordern. Obwohl CoraLibre bisher nicht vollständig abgeschlossen ist, haben wir aus technischer und organisatorischer Hinsicht unglaublich viel investiert und gelernt, was uns in anderen Projekten bereits sehr von Nutzen war.