Nomen est omen. Im Kern macht die Corona-Warn-App (kurz CWA) genau das, was der Name sagt: Sie warnt. Wie funktionieren solche Lösungen? Vereinfacht erkennen die Smartphones der Nutzerinnen und Nutzer Begegnungen untereinander und zeichnen sie auf. Sollte später jemand positiv auf Corona getestet werden, teilt er oder sie diese Information über die App. Frühere Kontakte werden über diese „Risikobegegnungen“ informiert sowie aufgefordert, sich zu isolieren und sich ebenfalls testen zu lassen. Die Warnungen sollen dabei helfen, Infektionsketten zu unterbrechen. Anders als der Name „App“ suggeriert, ist neben den Apps selbst auch noch ein Backend für den Informationsaustausch im Spiel.
Je nach Implementierung wäre bei einer solchen Software im Extremfall das Anfertigen von Bewegungsprofilen oder das Ausspähen von Gesundheitsdaten möglich. Der Chaos Computer Club hat entsprechende Systeme daher bereits früh als Risikotechnologie eingestuft und Prüfsteine formuliert, die er als Mindestmaß für solche Anwendungen sieht [CCC20]. In der Diskussion kristallisierte sich für die Umsetzung in Deutschland (wie auch in den meisten anderen europäischen Ländern) ein sogenannter dezentraler Ansatz heraus [Tag20], bei dem (anonyme) Kontaktinformationen nur auf den Endgeräten der Benutzer abgelegt werden, und nicht an einer zentralen Stelle – eine wichtige Forderung in den Prüfsteinen des CCC.
Neben dieser entscheidenden Vorgabe waren die Implementierung nativer Apps für Android und iOS und der Betrieb des Backends in Rechenzentren deutscher Provider innerhalb Deutschlands technische Rahmenbedingungen der Bundesregierung für das beauftragte Projekt-Team von SAP und Telekom. Auch das von Apple und Google entwickelten Exposure Notification Framework [GAEN20] war gesetzt. Hierbei handelt es sich um ein System, das als Teil der jeweiligen Smartphone-Betriebssysteme der beiden großen Hersteller den Austausch von Zufallsschlüsseln über Bluetooth Low Energy (BLE) ermöglicht. Es stellt das Rückgrat für das Erkennen der Begegnungen dar.
Im April 2020 legten die Entwicklungsteams los. Und zwar, für eine deutsche Vergabe aus öffentlicher Hand mehr als ungewöhnlich, in Public Repositories auf GitHub [Git]. Abbildung 1 zeigt die Homepage des Open-Source-Projekts der Corona-Warn-App.
Tabelle 1 stellt wichtige Architekturziele der Corona-Warn-App vor. Die Reihenfolge gibt eine grobe Orientierung bezüglich ihrer Wichtigkeit. Wie sieht die Lösung aus?
Abb. 1: Die Homepage der Corona-Warn-App-Projekts
Tabelle 1: Wichtige Architekturziele der Corona-Warn-App
Überblick über das Gesamtsystem
Abbildung 2 zeigt einen informellen Architekturüberblick der Gesamtlösung. Die Apps auf den Smartphones kommunizieren untereinander mit Bluetooth (BLE) und zusätzlich in Client-Server-Manier mit einem in Java realisierten Backend auf der Open Telekom Cloud. Die App-Nutzer erhalten Informationen über mögliche Begegnungen mit infizierten Personen. Sie verifizieren eigene Testergebnisse und warnen so freiwillig andere. Die Verifikations-Hotline unterstützt App-Nutzer bei der Freischaltung positiver Testergebnisse („teleTAN“). Gesundheitsämter und Testlabore liefern anonymisierte Testergebnisse an das System. Das Robert Koch-Institut (kurz RKI) stellt Inhalte („Content“) für die App zur Verfügung und bestimmt Parameter für die Messung der Kontakte („Risiko-Ermittlung“). Darüber hinaus empfängt das RKI Auswertungen, etwa aus der freiwilligen Datenspende. Der Austausch mit dezentralen Anwendungen anderer Länder ermöglicht die grenzüberschreitende Ermittlung von Begegnungen.
Abb. 2: Informeller Überblick über das Corona-Warn-App-System ([SiZö21], Stand 04/2021)
Zentrale Lösungsansätze
Mit welchen Lösungsansätzen erreicht die CWA die Ziele aus Tabelle 1? Die Implementierung nativer Apps für Android-Geräte und iPhones und die Verwendung des Exposure Notification Frameworks von Google und Apple garantiert die Unterstützung der gängigsten Smartphones (mehr als 90 Prozent aller Geräte), was für eine effektive Warnfunktionalität mitentscheidend ist. Weiterhin sind digitale Abläufe zur Risikowarnung einer „manuellen“ Kontaktverfolgung durch die Gesundheitsämter naturgemäß überlegen. Der dezentrale Ansatz unterstützt einen hohen Datenschutz. Die Speicherung der (anonymen) Kontaktdaten in Form von Zufallsschlüsseln erfolgt lokal beim App-Nutzer. Und nach dem Prinzip der Datensparsamkeit werden nur die minimal notwendigen Informationen erhoben und verarbeitet. Durch die transparente Entwicklung als Open Source – neben den Quelltexten sind auch Konzepte und Anforderungen (User Journey, Epics, …) auf GitHub einsehbar – ist die Implementierung durch Dritte überprüfbar. Um das Vertrauen der Nutzerinnen und Nutzer zu erhöhen, erfolgt das Teilen von Daten durch die App – insbesondere die Informationen über einen positiven Test – erst nach expliziter Zustimmung. Native Apps für iOS und Android, verteilt über die jeweiligen Stores, stellen eine niedrige Hürde für viele App-Nutzer dar. Die Oberflächen sind übersichtlich gestaltet, die Bedienung simpel. Die Entwicklungsteams haben auf einen geringen Ressourcen-Verbrauch der Apps (Akku, Netzwerk) geachtet, damit Nutzer sie nicht sofort wieder deinstallieren.
Microservices als Architekturstil
Der dezentrale Ansatz sorgt neben der Vertraulichkeit zusätzlich für ein robustes Gesamtsystem. Denn das wichtige Erfassen der Begegnungen durch die Apps kann ohne Verbindung zum serverseitigen Backend auf der Cloud erfolgen. Darüber hinaus sehen wir in Abbildung 2 die Zerlegung des Backends in unabhängige, separat skalierbare Teile mit jeweils eigener Datenhaltung nach Microservices-Manier. Diese Backend-Anteile sind durchgängig in Java mit Spring Boot realisiert. Diese Entscheidung spielt für die Lösung aber eine untergeordnete Rolle. Orchestriert wird das Ganze in Kubernetes, für die Datenbanken kommt PostgreSQL zum Einsatz. Der CWA-Server verteilt die von den Apps zu lesenden Daten über ein Content Delivery Network. Bei vielen positiven Testergebnissen muss da einiges bewegt werden. Denn wegen des dezentralen Ansatzes geschieht der Abgleich eines jeden positiven Testergebnisses (genauer: der damit verbundenen Schlüssel) auf allen Endgeräten. Die Corona-Warn-App wurde in kurzer Zeit entwickelt und stand bereits im Juni 2020 zum Download bereit. Das legt die Befürchtung nahe, dass die Software mit der heißen Nadel gestrickt wurde und Änderbarkeit sowie Erweiterbarkeit hintenanstehen mussten. Tatsächlich lassen sich aber auch für die Wartbarkeit Lösungsansätze identifizieren. Die Entwicklung als Open Source ermöglicht hier Einblicke und wirkt sich selbst positiv auf die Quelltext-Qualität aus. Die Verwendung verbreiteter Standardund Open-Source-Bibliotheken reduziert Entwicklungsaufwände und erleichtert Neuen im Team sowie interessierten Außenstehenden den Einstieg. Die Umsetzung des Backends in separate Server ermöglicht ein kollisionsarmes Hinzufügen weiterer Funktionalität durch neue Vertikalen, wie beispielsweise im März 2021 mit der Datenspende (siehe Data Donation Server in Abbildung 2) geschehen. Tatsächlich haben Updates und neue Features nach anfänglicher Stagnation deutlich zugenommen. Neben dem lokalen Kontakt-Tagebuch und der Anzeige ausgewählter Kennzahlen zum Infektionsgeschehen kamen die Event-Registrierung, das Einchecken mit QR-Code und die Erkennung sogenannter Cluster hinzu. Schnelltestergebnisse (neben PCR) wurden ebenso integriert wie die Anzeige des digitalen Impfnachweises.
Fazit
Die Corona-Warn-App erfüllt ihren Zweck. Aber ist sie ein Erfolg? Die Bewertung ist schwierig. Das RKI und das CWA-Projekt veröffentlichen zwar regelmäßig Statistiken, etwa zu den Download-Zahlen der App oder den eingespielten und geteilten Testergebnissen (Kennzahlen siehe z. B. [CWA]). Aussagen über die Anzahl der von der App ausgesprochenen Warnungen (rote vs. grüne Kacheln, siehe Abbildung 3) sind aufgrund des datenschutzfreundlichen Ansatzes nicht verlässlich möglich. Noch weniger gilt das für unterbrochene Infektionsketten (für eine Schätzung des RKI siehe [Hei21]). Ein häufiger Kritikpunkt sind die hohen Entwicklungsund Betriebskosten (laut Bundesregierung in den Jahren 2020 und 2021 in Summe ca. 130 Millionen Euro [BR22]).
Gleichwohl rechtfertigt die Strahlkraft des Projekts meiner Meinung nach ein Porträt in dieser Reihe. Das Vertrauen und die Akzeptanz in der Bevölkerung waren entscheidende Faktoren. Die transparente Entwicklung als Open Source – für eine von öffentlicher Seite in Deutschland beauftragte Software in dieser Größenordnung bisher einmalig – und die vorbildliche Umsetzung des Datenschutzes dienen hoffentlich als Modell für die Zukunft.
Abb. 3: Die Corona-Warn-App mit einer „grünen Kachel“ und einem positiven PCR- Test
Weitere Informationen
[BR22]
Antwort der Bundesregierung, Drucksache 20/431, Januar 2022, siehe:
https://www.bundestag.de/presse/hib/kurzmeldungen-877736
[CCC20]
Chaos Computer Club, 10 Prüfsteine für die Beurteilung von Contact Tracing-Apps, April 2020, siehe:
https://www.ccc.de/de/updates/2020/contact-tracing-requirements
[CWA]
Corona-Warn-App (CWA): Kennzahlen, siehe:
https://www.coronawarn.app/de/analysis/
[GAEN20]
Google, Apple: Exposure Notification Bluetooth Specification, April 2020
[Git]
Die Corona-Warn-App auf GitHub, siehe:
https://github.com/corona-warn-app
Hei21]
Heise-News vom 14.06.2021: RKI-Schätzung: Corona-Warn-App hat über 100.000 Infektionsketten unterbrochen, siehe:
https://www.heise.de/news/RKI-Schaetzung-Warn-App-hat-mehr-als-100-000-Infektionsketten-unterbrochen-6070747.html
[SiZö21]
F. Sippach, St. Zörner, So gehen Architektur-Reviews! Die deutsche Corona-Warn-App unter der Lupe, Vortrag auf der OOP 2021
[Tag20]
Beitrag Tagesschau vom 26.04.2020: „Bundesregierung setzt bei Corona-App auf dezentrale Datenspeicherung“, Video (2 min), siehe:
https://www.tagesschau.de/multimedia/video/video-693083.html
