rC3: Wie die Corona-Warn-App vor Hackerattacken geschützt wird

Thomas Klingbeil, leitender Entwickler bei SAP, hat auf dem remote Chaos Communication Congress (rC3) Einblicke in die Backend-Architektur der Corona-Warn-App (CWA) gegeben. Sie besteht im Kern aus einem CWA-Server mit den Diagnoseschlüsseln, einem Verifikationsserver sowie einem weiteren Server für die Übermittlung der Testergebnisse aus dem Labor.

Die App und die dahinterstehende Infrastruktur ist generell auf Datensparsamkeit ausgelegt und beachtet mit einem breiten Einsatz von Verschlüsselungsverfahren und dem Austausch von Hashwerten den Stand der Technik in der IT-Sicherheit. Beim Nachverfolgen von Kontakten via Bluetooth weiß der zuständige Server zwar etwa, von welchem Mobiltelefon die Daten kommen, kann aber keine Rückschlüsse auf den Nutzer des Gerätes ziehen.

Eine besonders kritische Datenübermittlung erfolgt, wenn der Nutzer sich dafür entschiedet, ein positives Testergebnis zu teilen. Auch dabei wird zwar nur eine Sammlung pseudonymer Krypto-Schlüssel übertragen. Daraus herauszulesen, wer der betroffene Nutzer ist, gestaltet sich daher schwierig. Trotzdem haben die Entwicklerfirmen, zu denen neben SAP die Deutsche Telekom gehört, auch auf dieser Ebene gegen einen unbefugten Datenzugriff und eine potenziell mögliche Auswertung der Informationen vorgebaut.

Sichere Verbindungen alleine reichen nicht

Ein gut gerüsteter Angreifer könne theoretisch den über die im Hintergrund aufgebaute Infrastruktur laufenden Netzwerkverkehr mitschneiden, konstatierte Klingbeil in seinem Vortrag. Es würden zwar nur sichere Verbindungen genutzt, sodass allein die Größen der versandten Datenpakete, nicht aber deren Inhalt erkennbar seien. Auch damit wäre aber etwa nachvollziehbar, ob ein Test stattgefunden habe und eine TAN-Abfrage erfolge.

Der Endpunkt und somit der getestete Nutzer blieben zwar zunächst unklar, führte der Programmierer aus. Aus den erkennbaren Bytemengen könnte ein Hacker aber etwa auch darauf schließen, dass es spezifische Größen gebe für spezielle Anfragen. Ferner sei prinzipiell erkennbar, wenn für einen TAN-Upload der zuständige CWA-Server kontaktiert werde. Klar sei denn auch, dass ein Nutzer positiv sein müsse, wenn Diagnoseschlüssel übermittelt würden. Im Worst-Case-Szenario könnte es zudem möglich sein, diesen Schlüssel mit einer IP-Adresse zu verknüpfen und den dahinterstehenden Anwender zu ermitteln.

"Wir müssen daher plausible deniability einfügen", verwies Klingbeil auf das Modell der "glaubhaften Abstreitbarkeit". Dabei kommen Methoden zum Einsatz, mit denen vertrauliche Daten oder deren Ursprung verborgen werden sollen. Bei der CWA handelt es sich dabei um störendes Rauschen, das in den Datenverkehr eingebaut wird: Die App simuliert laut dem Insider teils den entsprechenden Traffic im Backend und sendet bewusst falsche beziehungsweise nichtssagende Informationen an ein "Playbook", das als "Dummy" fungiere.

Im Rahmen dieses automatisierten Verfahrens könnten ermittelbare Anfragen durch ein reales Ereignis ausgelöst werden, erläuterte Klingbeil. Genauso wahrscheinlich sei aber, dass es sich um ein "Fake" handle. Selbst wenn ein Test negativ ausfalle, frage die Attrappe-Anwendung Diagnoseschlüssel ab und der TAN-Einsatz erfolge ebenfalls. So lasse sich nicht mehr herausfinden, "wenn wirklich jemand warnt".

Herausfiltern von falschen Paketen

Ein spezielles Feld im Header informiere die Backend-Server zugleich darüber, dass sie die gefälschten Pakete nicht in die einschlägigen Datenbanken einpflegen, sich sonst aber wie immer verhalten und antworten sollten. Der zusätzliche Verkehr verursache für die Nutzer keine erhöhten Kosten, da die Mobilfunkbetreiber das von der CWA verursachte Volumen generell nicht auf das persönliche Kontingent anrechneten ("Zero Rating"). Metadaten würden zudem von einen Vermittlungsserver entfernt.

Die CWA-Architektur verfügt auch über eine Schnittstelle in Form eines "EU Federation Service", um nationale Schlüssel fürs "Contact Tracing" hochladen und ausländische aus Mitgliedsstaaten mit interoperablen Architekturen anfragen zu können. Über einen Callback-Mechanismus werden die zuständigen Server dabei über den Upload neuer Keys informiert. Auch wenn Schlüssel aus anderen EU-Ländern so letztlich wie nationale behandelt würden, sei eine sogenannte Replay-Attacke und das damit verknüpfte Übermitteln vorab aufgezeichneter Daten zum Austricksen von Authentifizierungsverfahren nicht möglich, stellte Klingbeil klar. Die Informationen würden dafür zunächst zwei Stunden lang mit einem Embargo versehen und dürften erst danach verwendet werden.

Den Appell aus dem Chaos Computer Club (CCC), die CWA mit einer Option zur dezentralen Cluster-Erfassung etwa über den CrowdNotifier anzureichern, wollte der SAP-Innovationsexperte nicht kommentieren. Dies sei außerhalb seines Bereichs, da das Bundesgesundheitsministerium über neue Funktionen entscheide. Maschinenlernen werde derzeit nicht eingesetzt, um das Infektionsrisiko zu ermitteln. Kritik aus der Hackergemeinde, dass die Interaktion mit der Community bei dem Open-Source-Projekt über das Entwicklerportal Github oft langsam erfolge, werde er ins Team einbringen.

(pbe)