Die Covid-19 Warn- und Tracing-Apps waren und sind heiß diskutiert. Die CWA war aufwändig und teuer, hat aber viel Lob bekommen. Die Luca-Tracing-App ist auch sehr teuer und hat vernichtende Kritik einstecken müssen (z.B. bei Logbuch Netzpolitik), weil Design und Implementierung fundamentale Fehler vorgeworfen wurden.
Der aktuell diskutierte nächste Schritt in der Pandemie sind Lockerungen für geimpfte (oder auch frisch getestete) Personen. Es stellt sich sofort die Frage, wie „geimpft sein“ nachzuweisen geht. Der klassische gelbe Papier-Impfpass ist recht anfällig für Fälschungen und auch eher unhandlich.
Eine Impfnachweis-App ist wohl in Arbeit (Bundesgesundheitsministerium). IBM ist beteiligt, ausgerollt werden soll sie laut Presseberichten vielleicht als Teil der CWA. Technische Details sind noch keine bekannt, irgendwas mit „Impfbescheinigungstoken (2D-Barcode) “
Zeit für eine Fingerübung: Welche Anforderungen und Abwägungen sind für mich bei so einer Impfnachweis-App relevant und wie würde ich eine Lösung angehen?
Ein Impfer oder Tester kann einen digital signierten Nachweis für eine erfolgte Impfung oder einen negativen Test ausstellen.
Dieser Nachweis muss durch einen Prüfer schnell und auch offline mit einem gängigen Endgerät gescannt und validiert werden können.
Zusätzlich muss online validiert werden können, ob der ausgestellte Nachweis eventuell widerrufen wurde oder sogar der Impfer/Tester komplett als unzuverlässig widerrufen wurde.
Bei dem Scan zur Validierung sind keine persönlichen Daten der Person auslesbar und sammelbar (Name, Geburtsdatum).
Stichprobenartig kann vom Prüfer validiert werden, dass der Nachweis zu einem zusätzlich vorgelegten amtlichen Ausweis passt, anhand von Name und Geburtsdatum.
Ein Prüfer (oder eine zusammenarbeitende Gruppe von Prüfern) kann Gruppen von Benutzern identifizieren, die vom selben Impfer/Tester einen Nachweis ausgestellt bekommen haben (anhand einer Impfer-ID o.ä).
Ein Prüfer (oder eine zusammenarbeitende Gruppe von Prüfern) kann wiederholte Scans des gleichen Nachweises beobachten, daher theoretisch daraus Bewegungsprofile (anhand einer Nachweis-ID o.ä.) erstellen.
Der Nachweis ist per Scan nicht eindeutig identifizierbar, Bewegungsprofile vermeiden.
Anders als bei der CWA haben die Benutzer_innen der Impfnachweis-App kein Interesse daran, die eigene Identität „sauber“ abzubilden. Es macht keinen Sinn, die CWA auf dem Smartphone des Mitbewohners mit zum Brötchen holen zu nehmen - denn dann bekommt jener eventuell eine Warnung zu einer Risikobegegnung, die er gar nicht selbst hatte. Er war ja schließlich gar nicht neben dem Infizierten in der Bäckerei.
Wenn mein Mitbewohner aber geimpft ist, und ich durch Vorzeigen seines Handys Einlass in die Bäckerei bekommen kann, ist es naheliegend, diese andere Identität vorzutäuschen. Anders als bei der Kontaktverfolgung der CWA kann die Impfnachweis-App also nicht anonymisiert funktionieren, sondern muss an irgendeiner Stelle mit einer „offiziellen“ Identität verknüpft sein, damit ein Prüfer sicherstellen kann, dass der vorgelegte Nachweis auch zur vorzeigenden Person gehört.
Gleichzeitig sind jedoch Datenschutz und Anonymität wünschenswert. Ein einzelner, oder sogar eine Vielzahl von kooperierenden Prüfern soll kein Bewegungsprofil von Benutzern erstellen können, oder eine Liste aller Gäste einer Einrichtung anfertigen können.
Diese Ziele stehen grundsätzlich im Widerspruch zueinander. Dieser Widerspruch kann nur abgemildert werden.
Für den Prüfer ist nur ein stichprobenartiger Abgleich der Identität vorgesehen. Bei diesem Abgleich fällt ein gewisser manueller Aufwand an: Der Prüfer muss den Benutzer auffordern, die persönlichen Daten in der App freizugeben und diese zum Abgleich mit dem signierten Nachweis auch abtippen. Dadurch wird die massenweise Erhebung aller geprüften persönlichen Daten zumindest ökonomisch unattraktiv. Wenn die Stichproben häufig genug stattfinden, wird gleichzeitig das Risiko, die Daten einer anderen Person vorzuzeigen, ebenso unattraktiv hoch.
Die Bildung von Profilen anhand der gescannten Nachweise wird dadurch erschwert, dass jeder Benutzer eine Vielzahl von Nachweisen erhält (Hunderte) und die App zufallsgesteuert dem Prüfer nur einen der Nachweise anzeigt. Somit wird jegliches Profil immer lückenhaft sein, selbst wenn z.B. ein Dienstleister alle Einlasskontrollen in einer ganzen Stadt durchführt und versucht, Bewegungsprofile zu erstellen.
Es gibt keine zentrale Datenhaltung. Der Nachweis ist das digitale Pendant zum gelben Impfpass. Bei Verlust (der Daten oder des Gerätes) muss der Benutzer einen neuen Nachweis vom Impfer/Prüfer erhalten. Eine persönliche Sicherheitskopie oder eine dezentrale Sicherheitskopie des Impfers von allen ausgestellten Nachweisen ist hier out of scope.
Sowohl Benutzer_innen als auch Prüfer können offline arbeiten. Für die Prüfung der Signatur des Nachweises ist keine Serververbindung notwendig. Eine Sperrliste von widerrufenen Nachweisen oder Impfern sollte bei jedem Prüfer in der App möglichst aktuell vorliegen, für die Validierung selbst ist aber keine bestehende Verbindung notwendig.
So könnte ein Design grob funktionieren:
Die mit [] gekennzeichneten Daten sind nicht technisch per QR-Code auslesbar, sondern nur visuell als Text. Alle anderen Informationen sind als QR-Code auslesbar.
Diese Schritte sind im Prozess zentral:
Impfer/Tester prüft einen aktuellen Ausweis und gibt Name, Vorname + Geburtsdatum (Daten 3. + 4.) in die App ein. Die App randomisiert eine Prüfkennung (2.), die leicht abzutippen ist, aber ausreichend Entropie hat, um als Salt zu dienen, z.B. "ab37p". Über persönliche Daten und Salt wird ein Hashwert (5.) generiert. Der Gültigkeitszeitraum Immunität (1.) wird je nach Vorgang (Test oder Impfung) vorbelegt. Der Prüfer signiert den Hash und die Immunitätsdaten mit seinem Private Key, der wiederum selbst von einer zentralen Stelle (Root CA) ausgestellt und unterschrieben wurde. Der Public Key wird ebenfalls in den Nachweis integriert, damit er bei einem Prüfung offline vorliegt.
Von diesem Nachweis werden vom Impfer/Tester (automatisiert) mehrere hundert Exemplare ausgestellt, immer mit anderen Prüfkennungen, und somit auch anderen Hash- und Signaturwerten (5. und 6.).
Alle Exemplare des Nachweises werden nun in die App des Benutzers übertragen.
Der Benutzer zeigt dem Prüfer die App vor, welche einen zufällig ausgewählten Nachweis als QR-Code anzeigt. Die Prüfer-App validiert, ob die Gültigkeit der Immunität heute zutrifft und ob die Signatur (6.) von Gültigkeit und Hash zum Public Key des Impfers/Testers (7.) passt. Außerdem prüft sie, ob der Public Key auch korrekt von der Root CA signiert wurde, es sich also um einen offiziellen Impfer/Tester handelt.
Damit ist sichergestellt, dass der vorgezeigte Nachweis heute gültig ist und von einem offiziellen Impfer/Tester ausgestellt wurde.
Die Prüfer-App gleicht anschließend ab, ob der Nachweis (identifiziert durch die Signatur 6.) oder sogar der Impfer/Prüfer (identifiziert durch dessen Public Key) als Fälschung oder unzuverlässig auf einer Sperrliste stehen. Diese Sperrliste wird regelmäßig vom Server der Root CA heruntergeladen.
Damit ist sichergestellt, dass der vorgezeigte Nachweis nicht inzwischen als ungültig erklärt wurde.
Die Prüfer-App löst in 5-10% der Validierungen eine Identitätsprüfung aus, um sicherzustellen, dass der Nachweis auch wirklich zum Benutzer gehört. Hierzu legt der Benutzer in der App einen vorher versteckten Bereich „Prüfdaten“ frei. Dieser zeigt die nicht im QR-Code enthaltenen Daten (2. + 3. +4.) in Textform an: Prüfkennung, Vorname/Nachname und Geburtsdatum. Der Prüfer tippt diese Informationen in die Prüfer-App ein und vergleicht sie mit einem offiziellen Ausweisdokument. Die Prüfer-App berechnet den Hash über die eingegebenen persönlichen Daten und vergleicht ihn mit dem eingescannten Hashwert aus dem Nachweis.
Damit ist sichergestellt, dass der vorgezeigte Nachweis auch wirklich zum offiziellen Ausweis und damit zur Person passt.
(Die Prüfkennung/Salt soll verhindern, dass in einer großen Menge erfasster Scans gezielt nach einer Person anhand des berechenbaren Hashwertes von Vorname/Nachname + Geburtsdatum gesucht werden kann. Durch die zufällige Prüfkennung wird dieser Hashwert unvorhersehbar und muss für jeden erfassten Scan einzeln nachberechnet werden.)
Mit grob recherchierten Algorithmen:
| Element | Typ | Größe |
|---|---|---|
| 1. Immunität ab/bis | 2x Unix timestamp | 64 bit = 8 bytes |
| 5. Hash | SHA3-256 | 256 bit = 32 bytes |
| 6. Signatur (Impfer) | ECDSA Signature | 72 bytes |
| 7. Public Key | ECDSA Public key | 256 bit = 32 bytes |
| 8. Signatur (Root) | ECDSA Signature | 72 bytes |
| Summe: | 1728 bit / 216 bytes |
Diese Datenmenge ist im Rahmen eines normalen QR-Codes.