Corona Warn App – Ein technischer Blick hinter die Kulissen

19.06.2020

Seit dieser Woche gibt es nur noch ein Thema in der Medienberichterstattung: Die Veröffentlichung der Corona Warn App und mit ihr die Offenlegung des gesamten von SAP und Telekom implementierten Quellcode der Anwendung.

Grund genug für uns, mal einen professionellen Entwickler-Blick hinter die Kulissen und damit in die technische Umsetzung zu werfen. Wir wollen uns in diesem Blogartikel folglich darauf konzentrieren, WIE die Anwendung im Wesentlichen technisch umgesetzt wurde (für die Beschreibung, WAS fachlich passiert, möchten wir auf die Vielzahl von bereits verfügbaren Quellen verweisen)1.

In der Technical Documentation fällt zunächst auf, dass mit TAM (Technical Architecture Modeling) eine eigene Notation genutzt wird, die auf UML basiert2. Nachfolgend ist hierzu ein Beispiel in Form der High-Level Architektur aufgeführt, welche einen schönen Überblick über die gesamte Systemlandschaft gibt und die wir uns deshalb nachfolgend etwas genauer anschauen.

High-level architecture overview
Abbildung 1: High-level architecture overview Quelle: https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md

Mobile Phone

Kern der Corona Warn App (CWA) ist das Exposure Notification Framework, welches in Zusammenarbeit von Google und Apple bereitgestellt wurde3. Dieses Framework nutzt die Bluetooth Low Energy Funktechnik, welche besonders energieeffizient ist und für die Kommunikation über kurze Distanzen (<10m) geeignet ist. Damit wird kontinuierlich eine eindeutige Kennung in Form einer ID (im Bild mit RPI bezeichnet)4 über einen Broadcast ausgesendet. Diese ID ist grundsätzlich für alle Geräte im Umkreis des jeweiligen Handys auslesbar5. Sämtliche IDs (die selbst generierten und die ausgelesenen IDs anderer Handys) werden verschlüsselt lokal auf dem Gerät gespeichert.

Das Exposure Notification Framework ist auch für die Berechnung eines Risk Score zuständig, der das Risiko für einen Corona-Kontakt ermittelt6. Wichtig ist hierbei, dass diese Risikoermittlung vollständig lokal auf dem jeweiligen Endgerät erfolgt und keine anderen Stellen/ Systeme darüber informiert werden.

Beispiel für die Anzeige des Risk Score
Abbildung 2: Beispiel für die Anzeige des Risk Score. Quelle: https://github.com/corona-warn-app/cwa-documentation/blob/master/images/ui_screens/ui_screens_android.png

Um dieses Framework herum sind alle weiteren Funktionalitäten der App gebaut:

  1. Exposure Tracing Management: Verwaltet die Nachverfolgungsfunktionen (Aktivierung, Deaktivierung, Status Check, Zugriff auf die technischen Services).
  2. Exposure Risk Level Calculation: Berechnet das individuelle Risiko für einen Corona-Kontakt.
  3. Diagnosis Key Submission: Übermittelt Daten zu einem positiven Coronatest (TAN + Diagnose Key) an das Backend.
  4. Test Result Access: Ermöglicht den Zugang zu den Corona-Testergebnissen. Dies wird entweder über das Einscannen eines QR-Codes oder die manuelle eines TANs ermöglicht.

Neben den nativen MobileOS Funktionen, die Android und iOS zur Verfügung stellt, werden noch die folgenden Frameworks eingesetzt7:

Android

  • Room als Abstraktionsschicht über SQLite.
  • SQLCipher zur Verschlüsselung der Room Datenbanken.

iOS

  • SQLCipher zur Verschlüsselung der Datenbanken.
  • swift-protobuf Protokoll-Puffer für den Datenaustausch und das Parsen von Daten.
  • fmdb Für den Zugang auf SQLite.
App-Architektur.
Abbildung 3: App-Architektur. Quelle: https://raw.githubusercontent.com/corona-warn-app/cwa-app-android/master/docs/images/Architecture_Overview_v1.svg.

Weiterhin kommuniziert die App im Wesentlichen mit zwei Backendsystemen via REST:

  1. mit einem Corona Warn App Server bzw. einem vorgeschalteten Content Delivery Network (CDN) und
  2. mit einem Verification Server.

Wie die Backendsystemlandschaft genau aussieht? Wir geben Ihnen einen tiefergehenden Eindruck:

Technischer Überblick über die Backend Infrastruktur der Corona Warn App

Es gibt einige Komponenten, die sich durch die gesamte Backend Landschaft ziehen. Zunächst ist die gesamte Umgebung in der Open Telekom Cloud (OTC) gehostet und läuft auf einem Kubernetes Cluster und dem OpenShift Stack. Es gibt vier verschiedene Umgebungen (DEV, INT, WRU, PROD), für die es jeweils ein separates OTC Unterprojekt gibt. Pro Umgebung gibt es zwei separate OpenShift Stacks – einen für die Backend Services und einen für die PaaS Services – mit jeweils eigenem Namespace.

Corona Warn App Server und CDN

Der Corona Warn App Server hat im Wesentlichen zwei Aufgaben, die jeweils in einem eigenen Service gekapselt wurden (siehe hierzu auch Abbildung 4):

  1. Submission Service: TAN und Diagnose Key von den Mobile Clients entgegennehmen, die TAN vom Verification Server prüfen lassen und die Daten dann abspeichern.
  2. Distribution Service: Das Bereitstellen von Daten für die Mobile Clients in Form von zwei Dateitypen:
    1. Diagnose Keys von Nutzern die positiv getestet wurden,
    2. Konfigurationsdaten, die es ermöglichen den Risk Score zu berechnen und die App zu konfigurieren.
Corona Warn App Server Architektur
Abbildung 4: Corona Warn App Server Architektur. Quelle: https://github.com/corona-warn-app/cwa-server/raw/master/docs/images/v4.png

Beide Services laufen jeweils in einem eigenen Docker Container und greifen auf eine Postgres Datenbank zu. Der Distribution Service läuft 1x pro Stunde als Cronjob. Der Distribution Service sendet die Dateien dabei an einen S3 konformen Object Store auf Basis von Zenko8. Diese Daten werden dann von einem Content Delivery Network (CDN) ausgelesen, um die Daten für die Mobile Clients möglichst performant zur Verfügung zu stellen9.

Der Submission Service läuft (kontinuierlich) als Webservice und kommuniziert hierbei auch via REST mit dem Verification Server. Wie der im Detail aussieht, schauen wir uns im nächsten Absatz genauer an.

Verification Server

Der Verification Server hat zwei Aufgaben:

  1. Prüfen, ob ein Nutzer positiv getestet wurde und diese Information dann anderen Systemkomponenten zur Verfügung stellen.
  2. Informationen über den Status von Testergebnissen bereitstellen.

Um dies zu ermöglichen, kommuniziert diese Komponente mit drei Systemen via REST:

  1. Corona Warn App Server (siehe vorheriger Abschnitt)
  2. Test Result Server: Stellt Informationen zu den Labor-/Testergebnissen bereit.
  3. Portal Server: Stellt Anfragen zur Generierung von teleTANs10.
Verification Server
Abbildung 5: Verification Server. Quelle: https://github.com/corona-warn-app/cwa-verification-server/raw/master/docs/architecture_overview.svg

Nach außen werden via SWAGGER fünf Endpoints angeboten:

SWAGGER UI
Abbildung 6: SWAGGER UI. Quelle: https://github.com/corona-warn-app/cwa-verification-server

Intern werden die REST Calls dann über entsprechende Services verarbeitet, wie z.B. einen TanService, einen AppSessionService oder einen TestResultServerService. Im Gegensatz zu dem im vorherigen Abschnitt beschriebenen Corona-Warn-App Server laufen diese Services jedoch nicht in separaten Docker Containern sondern sind lediglich in einzelne Klassen gekapselt.

Weiterhin wird technisch für die Implementierung im Wesentlichen Spring Boot, PostgreSQL, H2 und Liquibase genutzt.

Übergreifende Konzepte der Corona Warn App

Nachdem wir einen Blick in die drei wichtigsten Komponenten geworfen haben, möchten wir abschließend noch einen kurzen Überblick über einige übergreifende Konzepte geben.

  • Security/Verschlüsselung: Im Wesentlichen wird TLS, Hashing mit SHA-256, OpenID und Virtual Private Cloud Peering eingesetzt. Weiterhin wird ein Denial of Service Protection am Telekom Backbone eingesetzt.
  • Datenbanken: Wie schon beschrieben wird im Wesentlichen PostgresSQL version 11.5 mit entsprechend verschlüsselten Datenbanken gesetzt.
  • Tracing/ Logging/ Monitoring: Die Anwendung wird 24/7 vom der Telekom Cyber Defence Center überwacht. Für das Logging wird unter anderem Graylog eingesetzt.
  • Last: Zur Verteilung der Last werden entsprechende Load Balancer verwendet, die IP whitelisting und IP masking verwenden. Die Anwendung ist dafür ausgelegt 720 Millionen Requests am Tag zu verarbeiten, was etwa 8.500 Sessions pro Sekunde entspricht und einen Traffic in Höhe von ~42 TerraByte am Tag generieren würde.

Unser Fazit zur Corona App: Nachvollziehbarkeit ist Weg zum Vertrauen der Nutzer

„Softwaretechnologie kämpft seit jeher um das Vertrauen ihrer Benutzer. Oft ist intransparent, was die Software im Code tut außer das, was sie soll. Insbesondere, wenn es um den Schutz von persönlichen Daten geht. Der eingeschlagene Weg der Corona Warn App, vollständig auf OpenSource zu setzen ist diesbezüglich vorbildlich und der einzig mögliche Weg, das Vertrauen der Menschen zurückzugewinnen. Der gesamte Entwicklungsprozess war durchgängig transparent und für jeden Bürger nachvollziehbar und überprüfbar. Das macht Mut für die Zukunft, damit noch mehr öffentliche oder systemrelevante Projekte OpenSource gehen. Insbesondere, wenn sie mit Steuergeldern finanziert werden,“ sagt doubleSlash Geschäftsführer Konrad Krafft.

Der veröffentlichte Quellcode und die zugehörige Dokumentation zur Corona Warn App ermöglichen im Wesentlichen eine gute Nachvollziehbarkeit der implementierten Anwendung. Für das von Google/ Android bereitgestellte Exposure Notification Framework wurde zwar eine detaillierte Dokumentation veröffentlicht, der Quellcode selbst ist jedoch nicht offen einsehbar, was schade ist. Darüber hinaus wird mit Hilfe von State of the Art Technologien eine robuste, sichere Anwendung entwickelt, bei der sehr viel Wert auf Datenschutz gelegt wurde.


1 Beispielsweise https://www.bundesregierung.de/breg-de/themen/corona-warn-app

2 Die Definition eines eigene Modellierungsstandards ist im Übrigen ein Vorgehen, dass wir häufig bei großen OEMs sehen.

3 Die App ist als Android und iOS Variante verfügbar => daher diese beiden Firmen.

4 RPI steht für Rolling Proximity Identifier.

5 Um ein unerwünschtes Tracking, z.B. von Bewegungsdaten zu verhindern, wird diese Kennung alle 15 Sekunden erneuert. Diese Kennung wiederum wird aus einem sogenannten Temporary Exposure Key abgeleitet, der alle 24h erneuert wird.

6 Wer im Detail nachlesen möchte, wie dieser Risk Score berechnet wird, kann dies hier nachlesen.

7 Die nachfolgende Liste ist lediglich ein Auszug. Nähere Informationen können hier und hier nachgelesen werden.

8 Die Postgres DB und der Object Store laufen auch jeweils in eigenen Containern.

9 CDNs sind darauf spezialisiert statischen Content auf viele regionale Knoten zu verteilen und dort zu cachen, was dazu führt, dass Konsumenten dieses Contents schnell und kostenoptimiert bedient werden können.

10 Der teleTAN wird vom Nutzer via Hotline (also telefonisch) angefragt und stellt fachlich eine Alternative zum QR-Code dar.

 

Zurück zur Übersicht

Ein Kommentar zur “Corona Warn App – Ein technischer Blick hinter die Kulissen

  1. Interessefrage: Die Warn-App bekommt die RPIs aller Kontakte eines Tages – aber nicht deren Uhrzeiten? Die Warn-App ruft diese Liste nur einmal vom ENF ab, kann also nicht durch viele Abrufe die Uhrzeiten selbst bestimmen?

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*