Wie die Corona-Warn-App funktioniert

Am 16. Juni 2020 hat Deutschland die Corona-Warn-App veröffentlicht, seine offizielle App zur Kontaktnachverfolgung. Innerhalb von 24 Stunden wurde sie millionenfach heruntergeladen und war damit eine der am schnellsten angenommenen staatlichen Apps in der europäischen Geschichte.

Als Softwarehaus mit einem Bein im deutschen Markt haben wir die Entwicklung genau verfolgt — teils aus fachlicher Neugier, teils weil sie eine Fallstudie dafür ist, wie man eine datenschutzsensible App unter enormer öffentlicher Beobachtung ausliefert. Hier steht, was die App tut, wie sie unter der Haube funktioniert, und warum die Architekturentscheidungen zählen.

Was die Corona-Warn-App tut

Der Zweck ist einfach: Wenn Sie sich längere Zeit in der Nähe von jemandem aufgehalten haben, der später positiv auf SARS-CoV-2 getestet wird, warnt die App Sie, damit Sie sich testen und absondern können, bevor Sie unwissentlich andere anstecken.

Der schwierige Teil ist, das zu leisten, ohne eine zentrale Datenbank darüber aufzubauen, wer wen getroffen hat.

Die Architektur: dezentral von Anfang an

Deutschland hat zunächst ein zentrales Modell erwogen, bei dem Begegnungsdaten auf einen staatlichen Server geladen worden wären. Nach einer öffentlichen Debatte unter Beteiligung von Datenschutzforschern ist der Bund im April 2020 auf einen dezentralen Ansatz umgeschwenkt, aufbauend auf dem Exposure-Notification-Rahmen von Apple und Google. Diese Entscheidung ist das Wichtigste an der App.

Der Ablauf in einfachen Worten:

1. Ihr Telefon sendet Zufallskennungen aus. Über Bluetooth Low Energy verschickt die App kurzlebige, zufällig erzeugte Kennungen, die sich alle paar Minuten ändern. Sie enthalten keine personenbezogenen Daten.
2. Ihr Telefon merkt sich die Kennungen, die es hört. Telefone in der Nähe, auf denen die App läuft, speichern die Zufallskennungen der anderen lokal, zusammen mit Signalstärke und Dauer, für 14 Tage.
3. Ein positiver Test wird verifiziert. Wenn Sie positiv getestet werden, können Sie Ihr Ergebnis in der App teilen. Ein Prüfschritt — ein QR-Code aus dem Labor oder eine TAN von einer Hotline — stellt sicher, dass nur echte Ergebnisse hochgeladen werden.
4. Nur Ihre Schlüssel verlassen das Telefon. Die App lädt die Schlüssel hoch, aus denen Ihre jüngsten Zufallskennungen abgeleitet wurden. Kein Standort, keine Kontaktliste, kein Name.
5. Jedes Telefon prüft lokal. Jede App lädt regelmäßig die Liste veröffentlichter Schlüssel und gleicht sie mit den Kennungen ab, die sie aufgezeichnet hat. Der Abgleich passiert auf Ihrem Gerät, nicht auf einem Server.
6. Das Risiko wird auf Ihrem Gerät berechnet. Aus Nähe und Dauer schätzt die App Ihr Expositionsrisiko und zeigt eine Warnung, wenn es einen Schwellenwert überschreitet.

Der Server erfährt nie, wer wen getroffen hat. Genau darum geht es.

Warum quelloffen wichtig ist

SAP und die Deutsche Telekom haben die App im Auftrag des Bundes gebaut, und der vollständige Quellcode — mobile Apps, Backend, Verifikationsserver — wurde vor dem Start auf GitHub veröffentlicht.

Für Entwickler ist das bemerkenswert. Tausende Menschen haben den Code geprüft, Fehler gemeldet und Korrekturen eingereicht, bevor ihn die Öffentlichkeit überhaupt installiert hat. Für die Öffentlichkeit bedeutete es, dass die Datenschutzversprechen unabhängig überprüfbar waren, statt geglaubt werden zu müssen. Die Verbreitung einer freiwilligen App hängt am Vertrauen, und Quelloffenheit ist der glaubwürdigste Weg, es zu verdienen.

Grenzen, die man kennen sollte

Die App ist kein Allheilmittel.

• Bluetooth ist ein Näherungswert, keine Messung. Signalstärke durch eine Wand oder eine Tasche ist ungenau, also gibt es sowohl falsch positive als auch falsch negative Treffer.
• Sie braucht Verbreitung. Der Nutzen wächst mit dem Quadrat der Nutzerzahl; eine Warnung kommt nur, wenn beide Personen die App verwenden.
• Testergebnisse müssen angebunden sein. Ein positives Ergebnis hilft nur, wenn Labor oder Teststelle es mit einem verifizierten QR-Code in die App bringen können — und das erfordert Integrationsarbeit auf Laborseite. Wir erwarten, dass das ein großes Thema wird, sobald mehr getestet wird.

Was Softwareteams daraus lernen können

Drei Lehren, die wir in unsere eigenen Projekte mitnehmen:

1. Datenschutz ist eine Architekturentscheidung, kein Richtliniendokument. Das dezentrale Modell macht Missbrauch technisch unmöglich, statt ihn bloß zu verbieten.
2. Transparenz schlägt Marketing. Den Code zu veröffentlichen hat mehr für die Verbreitung getan, als es eine Kampagne gekonnt hätte.
3. An der Integration entscheidet sich Public-Health-Software. Die App ist nur so nützlich wie die Datenstrecken, die sie speisen.

Auf den letzten Punkt kommen wir zurück. Bei Daleenda schauen wir uns bereits an, was es braucht, damit Teststellen sich in dieses Ökosystem einklinken — und die Antwort lautet, dass die Werkzeuge dafür kaum existieren.