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.