Kurzdokumentation der offiziellen Corona Warn App
Die Architektur der offiziellen Corona-Warn-App basiert auf der DP-3T Architektur. Jede App speichert gesendete und empfangene IDs nur lokal und überträgt nur im Falle eines positiven Tests und Einwilligung des Users auf einen Server. Die IDs werden von einem täglich wechselnden Temporary Exposure Key abgeleitet. Die App downloadet regelmäßig die auf dem Server gespeicherten Keys um lokal das Risiko des Users zu berechnen und ihn ggf. zu informieren.
Sobald ein Patient sich Testen lässt erhält er vom Arzt einen QR-Code, der vom Laboratory Information System ausgestellt wird. Dieser kann von der App gescannt werden, die daraus eine GUID ableitet (Schritt 1). Diese GUID wird gehasht an den Verification Server gesendet (Schritt 2), der einen Registration Token erstellt, diesen zusammen mit der GUID speichert (Schritt 3) und an die App schickt (Schritt 4). Diese fragt dann regelmäßig beim Server nach den Testergebnissen (Schritt 5), wobei der Registration Token als Verifikation dient. Der Verification Server erhält die Testergebnisse vom Laboratory Information System (Schritt 6 und 7) und schickt diese zurück an die App (Schritt 8). Im Falle eines positiven Tests kann der User sich entscheiden, seine gespeicherten Keys, die er über die letzten 14 Tage zum Erstellen von IDs benutzt hat, mit dem Server zu teilen. Dazu erfragt die App eine TAN vom Verification Server (Schritt 9). Dieser generiert die TAN und schickt sie zurück (Schritt 10 und 11). Die App schickt die TAN und die benutzten Keys an den Corona-Warn-App Server, welcher die TAN beim Verification Server verifiziert und die Keys speichert (Schritte 12 bis 16).
Sollte der User keinen QR-Code benutzten wollen oder das Testinstitut kann keinen ausstellen, werden die Testergebnisse wie bisher durch das Gesundheitsamt mitgeteilt, welches dabei auch eine teleTAN sendet. Diese kann vom User wie die GUID benutzt werden um einen Registration Token zu erhalten. Wenn der User seine Keys mit dem Server teilen will, verfährt er dann wie oben erklärt, beginnend bei Schritt 9.
Jede App sendet an zufällgen Zeitpunkten Dummy-Testergebnissanfragen und Dummy-Keyuploads, damit Angreifer nicht über eine Traffic-Analysis erfahren können, wer sich testen lassen hat und wer infiziert ist. Außerdem downloadet jede App einmal pro Stunde alle verfügbaren Keys über ein Content-Delivery-Network. Um das Netzwerk nicht zu überlasten wählt jede App in jedem Intervall einen zufälligen Zeitpunkt zum Download aus.
Die App wird nativ für Android und iOS entwickelt. Beide OS stellen ein Exposure Notification Interface bereit, welches die Schlüssel generiert und speichert. Auf empfangene Schlüssel werden davon gespeichert, sodass die App keinen Zugriff darauf hat. Desweiteren empfängt das Framework die Keys infizierter Personen vom Server und gleicht diese mit gesammelten Keys ab. Das Ergebnis hiervon, also alle gesammelten Keys, die mit Keys von positiv getesteten Personen übereinstimmen, werden an die App übertragen, die daraus das Risiko des Users berechnet. Der Prozess der Risikoberechnung ist für den User nicht sichtbar.
Sollte ein Kontakt eines Users positiv getestet werden wird dem User das Rsiko einer eigenen Infektion angezeigt. Das Risiko wird anhand von 4 Werten der Risikoklassen berechnet:
- Tage seit dem Kontakt
- Länge des Kontakts
- Stärke/ Schwäche des Signals
- Übertragungsrisiko: Der wert hierfür ist App-spezifisch und kann tagesspezifisch das Übertragungsrisiko, welches von den Gesundheitsämtern berechnet wird, angeben.
Die Wertebereiche der einzelnen Risikoklassen werden auf Werte von 0-8 gemapt und miteinander multipliziert. Das Ergebnis wird benutzt um das Gesamtrisiko einer Infektion anzugeben.
Für die Buildprozesse des Verification Servers können Maven und/oder Docker verwendet werden. Wenn man an der Entwicklung mitarbeiten will, wird Maven empfohlen, weshalb wir hier nur darauf eingehen werden. Wer Docker verwenden möchte findet ein Beschreibung dazu hier.
Für den Buildprozess mit Maven benötigt man Maven selbst und Open JDK 11 oder eine ähnliche, mit JDK 11 kompatible VM. In der Konsole kann man dann im Rootverzeichnis des Projektes das folgende ausführen, um den Server lokal zu starten.
mvn package
java -jar target/cwa-verification-server-0.0.1-SNAPSHOT.jar
Der Sourcecode selber ist in Java geschrieben und nutzt Spring Boot, mehr Informationen dazu hier.
Für den tatsächlichen Server selber werden desweiteren Postgres für die Datenbank und Zenko Cloudserver für die Cloud benötigt. Diese müssen nach der Installation an das Projekt angepasst werden, weitere Informationen dazu und zum Buildprozess hier.