Corona-Tracing per App: SAP legt erste Version des Corona-Warn-Servers vor

Inhaltsverzeichnis

Mitarbeiter von SAP haben in Zusammenarbeit mit der Deutschen Telekom und freiwilligen Open-Source-Entwicklern die erste Version des Server-Backends für die deutsche Corona-Warn-App auf GitHub veröffentlicht. Die Software empfängt Exposure-Notification-Berichte von den bisher noch nicht veröffentlichten Android- und iOS-Apps und erzeugt Diagnosis Keys für diese Berichte, die dann wiederum von allen Mobil-Apps für die letzten 14 Tage abgerufen werden können.

Außerdem regelt der Server mittels verschiedener, justierbarer Parameter die lokale Risiko-Einschätzung, mit der die Smartphone-Apps entscheiden, ob sie einen Nutzer über einen potenziell gefährlichen Kontakt informieren.

Solider Start fürs Open-Source-Projekt

Die Server-Software ist in Java geschrieben und wird mit Apache Maven verwaltet. Die sehr minimal gehaltenen Daten werden in einer Postgres-Datenbank und mit Hilfe des Object-Storage-Frameworks MinIO gespeichert. Auf einem Server installiert wird das Corona-Warn-Backend als Docker-Image.

Der bisher verfügbare Quellcode sieht nach einer ersten, oberflächlichen Analyse solide und gut strukturiert aus. Mit Docker, Maven und Postgres haben die Entwickler gebräuchliche Open-Source-Werkzeuge für die Entwicklung ihrer Infrastruktur gewählt. Auch die Wahl von Java ist mit dem Blick auf das Ökosystem der SAP-Entwickler und der Tatsache, dass ein großer Teil der Entwicklung eine Android-App mit einschließt, nachvollziehbar. Erste öffentliche Einschätzungen des Quellcodes von Software-Entwicklern auf Twitter und Meinungen in nicht-öffentlichen Mailinglisten fallen verhalten positiv aus. Bisher sind keine offensichtlichen Probleme mit sicherheitsrelevanten Aspekten des Codes zu Tage getreten. Die Offenlegung des Quellcodes orientiert sich weitestgehend an Best Practices im Open-Source-Bereich.

Justierungsmöglichkeiten für Gesundheitsbehörden

Einer der bisher interessantesten Aspekte des Server-Codes ist der Mechanismus, mit dem Gesundheitsbehörden – im deutschen Einsatz der App voraussichtlich das Robert-Koch-Institut (RKI) – die Gefährdungsparameter justieren können, mit deren Hilfe die App entscheidet, wann Nutzer über einen möglichen gefährlichen Kontakt informiert werden.

Dieser Aspekt wurde in den ersten Veröffentlichungen von Apple und Google zu ihrem API nicht eingehend beleuchtet und erst in den vergangenen Tagen genau dokumentiert. Wie präzise diese Parameter das wirkliche Übertragungsmuster des Virus abbilden können, wird eine entscheidende Rolle dabei spielen, ob eine solche Warn-App in der Realität von praktischem Nutzen ist. Das SAP-Server-Backend definiert für die Justierung dieser Parameter eine YAML-Datei, die vier von Apple und Google festgelegte Werte enthält: Transmission, Duration, Days Since Last Exposure und Attenuation.

Transmission ist das Risiko der Übertragung der Krankheit und wird in der Smartphone-App festgelegt – vermutlich auf Grund der Daten, die der meldende SARS-CoV-2-positive Patient vom RKI oder dem Arzt mit seinem Testergebnis erhält. Dieses Risiko bildet ab, in welchem Stadium der Krankheit der Patient ist und wie sein individueller Krankheitsverlauf aussieht. Duration ist die Länge des Bluetooth-Kontakts des Handys eines positiv getesteten Nutzers mit einem anderen Gerät. Days Since Last Exposure ist die Zeit, die vergangen ist, seit das Handy des Patienten zum letzten Mal Bluetooth-Kontakt mit dem Handy der Person hatte, die gewarnt werden soll. Attenuation beschreibt die Empfangsstärke des Bluetooth-Signals (in dBm) beim Kontakt zwischen den beiden Geräten. Je stärker das Signal, desto näher waren sich die Personen vermutlich. Dieser Wert wird für jede einzelne Kontaktsituation immer gemittelt, um die in der Realität unausweichlichen starken Schwankungen beim Empfang von Bluetooth-Signalen in geschlossenen Räumen möglichst auszugleichen.

• Details zur Funktionsweise der Smartphone-Apps finden Sie im Artikel Corona-Tracking: Wie Contact-Tracing-Apps funktionieren, was davon zu halten ist.

Bis auf das Transmission-Risiko, das mit dem Diagnosis Key auf dem Server gespeichert wird, werden diese Werte lokal auf dem Smartphone verwaltet. Die Gesundheitsbehörde kann mit Hilfe der YAML-Konfigurationsdatei auf dem Server diese Faktoren unterschiedlich werten. Die Smartphone-Apps rufen die Werte dann über das API des Servers ab. Auf Grundlage dieser Konfigurationsparameter werden die von der Smartphone-App gespeicherten Werte dann lokal zu einem globalen Exposure Risk multipliziert. Dieser Exposure-Risk-Wert wird von der Smartphone-App dazu verwendet zu entscheiden, ob der Nutzer der App wegen dem Kontakt mit dem entsprechenden Diagnosis Key gewarnt wird.

Open-Source-Status des Projekts mit Bezug auf die Google Play Services

Neben dem Server-Code der Corona-Warn-App wird momentan ein weiterer Aspekt des Projektes angeregt diskutiert: Die Tatsache, dass Google bei seiner Umsetzung des Exposure-Notification-API die Google Play Services nutzt. Das führt dazu, dass Android-Nutzer die, aus welchem Grund auch immer, die Play Services nicht installiert haben, die Corona-Warn-App nicht verwenden können.

Das betrifft zwar nur einen relativ kleinen Teil der in Deutschland im Umlauf befindlichen Android-Geräte, stört aber trotzdem einige Android-Puristen. Ein wichtigerer Nebenaspekt dieses Umstandes ist, dass diese Umsetzung des Exposure Noitification API nicht komplett Open Source ist, da die Play Services nicht unter einer Open-Source-Lizenz stehen und nicht Teil des Android Open Source Projects (AOSP) sind. Zwar hat Google durchblicken lassen, das Exposure Notification API später in die Kernkomponenten von Android (mutmaßlich unter Open-Source-Lizenz) integrieren zu wollen, aber es gibt keinen konkreten Zeitplan, wann das passieren soll.

Die SAP-Entwickler haben bestätigt, dass sie sich dieses Problems bewusst sind und zu Protokoll gegeben, dass es ihnen wichtig ist, dass die komplette Corona-Warn-App mit allen ihren Aspekten als Open-Source-Code zur Verfügung steht. Sie betonen aber auch, dass sie keinen Einfluss darauf haben, wie Google seinen Teil der Exposure Notification API implementiert. (fab)