Corona-Warn-App: Quellcode-Analyse eines beispiellosen Open-Source-Projektes

Inhaltsverzeichnis

Die von der Bundesregierung mit der Entwicklung der deutschen Coronavirus-Tracing-App beauftragten Unternehmen, allen voran Mitarbeiter von SAP und der Deutschen Telekom, haben vor wenigen Tagen den kompletten Quellcode aller Software-Komponenten der App und der dazugehörigen Server-Infrastruktur veröffentlicht.

Der Quellcode der Smartphone-Apps für Android und iOS ist beeindruckend aufgeräumt und enthält ersten, noch recht oberflächlichen Analysen zufolge keine offensichtlichen Hintertüren oder Sicherheitslücken. Die Apps sind im aktuellen Zustand noch nicht einsatzbereit, einer allgemeinen Veröffentlichung Mitte Juni scheint aber nichts im Wege zu stehen.

Unterbau der Corona-Warn-App

Die iOS-Version der Corona-Warn-App ist in Swift geschrieben und benutzt Apples UI-Framework UIKit zur Umsetzung der grafischen Elemente der Software, nicht etwa das neuere SwiftUI-Framework. Laut den Entwicklern verwendet man UIKit, weil es ausgereifter als die neuere Alternative ist, die Apple erst vergangenes Jahr vorgestellt hatte.

Die Android-Version ist in Kotlin verfasst und nutzt die eingebauten User-Interface-Funktionen der Sprache zusammen mit Googles Navigation Component.

Grundsätzlich scheint sich die Struktur beider Apps stark an etablierten Best Practices für iOS- und Android-Applikationen zu orientieren. Syntax und Namespace der beiden Programme halten sich weitestgehendes an die jeweiligen Design-Richtlinien von Apple und Google. Auch das Exposure Notification API der beiden Unternehmen scheint vorbildmäßig umgesetzt worden zu sein.

Alle Daten werden lokal auf dem Smartphone in einer SQLite-Datenbank gespeichert. Diese Datenbank wird mittels SQLCipher, einer auf Sicherheit optimierten SQLite-Bibliothek, lokal verschlüsselt. SQLCipher ist ein Open-Source-Projekt der Firma Zetetic und die eingesetzte Krypto-Technik sieht solide aus.

Die Netzwerkverbindung zum Server ist in beiden Apps mittels der Google-Technik Protocol Buffers (protobuf) umgesetzt, was durch die Apple/Google-API auch entsprechend vorgeschrieben wird. Der Code ist sehr minimal gehalten und macht augenscheinlich genau das, was er laut API machen soll und sonst nichts. Einige Beobachter, die sich diesen Quellcode angesehen haben, kommentieren die Tatsache, dass momentan noch arg viele Fehlerzustände einfach ignoriert werden – was allerdings daran liegen könnte, dass die App noch nicht fertig ist.

Nachholbedarf bei Code-Tests

Wohl der größte Kritikpunkt von unabhängigen Beobachtern ist die Tatsache, dass die Apps im aktuellen Zustand keine durchgehende Abdeckung mit automatisierten Tests aufweisen können. Vor allem der UI-Teil der iOS-App scheint da bisher etwas zu kurz gekommen zu sein.

Automatisierte Tests spielen eine wichtige Rolle bei der frühzeitigen Entdeckung von Sicherheitslücken und ungewolltem Verhalten einer App (zum Beispiel Hintertüren oder Information Leaks) und werden von vielen Software-Entwicklern und Sicherheitsforschern als essenziell angesehen. Open-Source-Code ist schließlich nur dann verlässlicher als eine proprietäre Code-Basis, wenn er auch ordentlich und flächendeckend getestet wurde, um Fehler auszumerzen.

Der momentane Mangel an Tests kann sicherlich ebenfalls damit begründet werden, dass die Apps noch nicht fertig sind. Hier spielt die beeindruckende Entwicklungsgeschwindigkeit der Apps vielleicht auch eine große Rolle. Der Code dieser Apps ist schließlich erst wenige Wochen alt. Vor der öffentlichen Bereitstellung der App an ein großes Publikum sollte dieses Manko aber unbedingt behoben und alle Teile beider Apps großzügig mit Tests abgedeckt sein.

Erschwerend kommt hinzu, dass man ganze Teile der Apps, die mit dem Apple/Google-Exposure-Notification-API reden, momentan gar nicht testen kann, da Entwickler sich erst von Apple oder Google whitelisten lassen müssen. Die Projektverantwortlichen sagen, dass sie momentan an Möglichkeiten arbeiten, damit unabhängige Entwickler einfacher entsprechende Berechtigungen erhalten können.

Anonymität der App-Nutzer

Unserer Analyse des Quellcodes der Android- und iOS-Varianten der Corona-Warn-App zufolge ist dieser weitestgehend minimal gehalten und ziemlich aufgeräumt. Beide Apps halten sich an aktuelle Standards und wurden augenscheinlich den Best Practices des entsprechenden Betriebssystems entsprechend programmiert. Offensichtliche Sicherheitslücken oder Hintertüren finden sich nicht; die Anonymität des App-Nutzers ist, wie es das Exposure Notification API vorschreibt, solange gewährleistet, bis er sich entscheidet, Exposure Keys auf den zentralen Server hochzuladen. Jedenfalls trifft das im Rahmen unserer begrenzten Analyse zu.

Es ist natürlich nicht auszuschließen, dass andere Beobachter – und vor allem professionelle Sicherheitsforscher – Sicherheitslücken oder gar schwerwiegende Implementierungsfehler im Code der Apps entdecken. Der bisherige Umgang der Entwickler mit Verbesserungsvorschlägen und Kritik an ihren Code deutet allerdings darauf hin, dass sie mit solchen Problemen offen umgehen und sie so schnell wie möglich beheben würden.

Besonders der lokalen Speicherung der App-Daten kommt bei der Wahrung der Nutzer-Anonymität eine besondere Gewichtung zu. Da bisher nicht vorgesehen ist, dass die freiwillige Nutzung der Corona-Warn-App durch speziell dafür zugeschnittene Gesetze geregelt wird, muss verhindert werden, dass staatliche Stellen Zugriff auf diese Daten erhalten. Denkbar wäre etwa, dass im Zuge einer kriminaltechnischen Ermittlung eines SARS-CoV-2-Vebreitungsevents Ermittler auf die Idee kommen, die App-Daten eines Anwesenden zu untersuchen. So könnte die freiwillige Nutzung einer solchen Hilfs-App gegebenfalls dazu führen, dass sich diese Person selbst belastet. Bisher gibt es allerdings keine Hinweise darauf, dass die lokale Verschlüsselung dieser Daten angreifbar ist.

Infrastruktur

Auch die Infrastruktur hinter den Apps ist nicht frei von Angriffsmöglichkeiten. Das gewählte TAN-Verfahren für die Bestätigung positiver Testergebnisse in der App könnte dazu genutzt werden, den Nutzer zu deanonymisieren. Dazu müsste nach unserem aktuellen Kenntnisstand allerdings der zentrale Verification Server der App mit einer Instanz zusammenarbeiten, die ein positives Testergebnis einem Nutzer zuordnen kann. Da das in der Regel ein Gesundheitsamt oder ein unabhängiges Labor beziehungsweise eine Arztpraxis ist, ließe sich ein solcher Angriff wohl nur flächendeckend mithilfe von Regierungsorganen auf Bundesebene durchführen.

So etwas bliebe wohl kaum unentdeckt und ist angesichts der Tatsache, dass Bundesorgane bereits im Rahmen des Infektionsschutzgesetzes (IfSG) Zugriff auf entsprechende Daten haben, eher eine Sorge rein theoretischer Natur. Zwar gibt es Verfahren, diesen Angriffsvektor zu vermeiden, die Entwickler haben sich aber wohl aus Gründen der Interoperabilität für das TAN-Verfahren entschieden. Wenn man bedenkt, dass die Software hier wahrscheinlich mit den unterschiedlichsten, nicht standardisierten Gegenstellen bei Gesundheitsämtern und Laboren sprechen muss, ist das eine nachvollziehbare Entscheidung.

Vorläufiges Fazit

Die SAP-Entwickler haben mit Unterstützung der Telekom und unter Bezugnahme auf Verbesserungsvorschläge unzähliger unabhängiger Helfer eine beeindruckende Leistung vorgelegt. Nicht nur haben sie es geschafft, eine komplizierte App und deren Server-Infrastruktur für zwei Betriebssysteme im Rekordtempo bereitzustellen, das Ganze passiert auch noch unter Beachtung gängiger Best Practices der App-Entwicklung und für die Veröffentlichung von Open-Source-Code. Bei dem Corona-Warn-App-Projekt handelt es sich um das erste Mal in der Geschichte der Bundesrepublik, dass so etwas im Auftrag der Regierung so schnell und in solchem Ausmaß gelingt. Wenn Sicherheitsforscher, Datenschutz-Experten und unabhängige Entwickler bis zur Veröffentlichung der Apps keine gravierenden Probleme mit dem Quellcode finden, gibt es erst mal keinen Grund, dass irgendjemand der deutschen Umsetzung des COVID-19-Contact-Tracing-Konzeptes gegenüber Misstrauen hegen muss.

Ob die Apps trotzdem noch rechtzeitig kommen und ob Bluetooth-Tracing überhaupt dafür geeignet ist, die Verbreitung von SARS-CoV-2 einzudämmen oder gar zu stoppen, ist hingegen völlig unsicher. Es ist gänzlich ungeklärt, wie groß die Verbreitung dieser Apps in der Bevölkerung sein muss, damit bei aktuell konstant sinkenden Fallzahlen von unter 400 Neuinfektionen am Tag überhaupt irgendwelche potenziell gefährlichen Kontakt-Events aufgezeichnet werden können.

Die Hoffnung der App-Befürworter ist, dass die Technik die oft heraufbeschworene zweite Verbreitungswelle des Virus abfangen kann. Allerdings gibt es momentan keine handfesten Hinweise darauf, dass eine zweite Welle zu erwarten ist. Und ob Apples und Googles Bluetooth-Tracing-API überhaupt dazu geeignet ist, die Verbreitung des Virus aussagekräftig einzuschränken, werden wir wohl erst wissen, wenn wir uns mitten in der hypothetischen zweiten Welle befinden und falls die App auch wirklich eine signifikante Verbreitung in der Bevölkerung erreicht.

Das sind sehr viele Mutmaßungen, die wahr werden müssen, bevor wir begründete Schlüsse darüber ziehen können, ob sich die beispiellose Entwicklungsarbeit an der Corona-Warn-App der Regierung gelohnt hat. Aber immerhin gibt es erst einmal keine Einwände dagegen, sich die App zu installieren, wenn man das denn will. (fab)