Mit der ID-Wallet kannst Du alles und jeder sein, außer Du musst Dich ausweisen.
Kurz vor der Bundestagswahl stellte das Bundeskanzler*innen-Amt die App “ID-Wallet” vor. Eine Smartphone-App, die es ermöglicht, sich gegenüber Dritten zu identifizieren. Leider können Nutzer*innen aber nicht überprüfen, gegenüber wem sie sich identifizieren. Dieser Umstand ermöglicht unterschiedliche Szenarien des Identitäts- und Datendiebstahls.
Im folgenden Text sparen wir uns die Verweise darauf, warum die Blockchain-Technologie grundsätzlich eine schlechte Wahl für das hier gestellte Problem ist und wollen uns stattdessen auf eine konkrete Sicherheitsschwankung in der Implementierung beziehen.
Die ID-Wallet App der Digital Enabling GmbH ermöglicht es Nutzer*innen, die Daten ihres Personalausweises über die schon lange existierende, aber leider noch immer nicht etablierte Ausweisapp 2 in einen Distributed Ledger zu importieren. Sobald das passiert ist, können Nutzer*innen QR-Codes scannen und über die App die eigene Identität anderen freigeben. Wem? Jeder Person, die fähig ist, einen QR-Code passend zur Implementierung des veralteten DIDComm 1 Protokolls zu generieren.
Dabei stehen grundsätzlich zwei Verfahren zur Verfügung.
1. Die direkte Verbindung
Alice will Bob identifizieren. Dazu präsentiert sie ihm einen QR-Code. Dieser verweist zu einer Serveradresse, von der Bob einen “Present Proof Request” abruft. Bob wird von seinem Smartphone gefragt, ob “Alice” seine Ausweisdaten sehen darf. Da Bob Alice kennt, stimmt er dieser Abfrage zu. Alice erhält die Ausweisdaten von Bob samt verifizierbaren Signaturen an ihren Server übermittelt.
Dieses Verfahren soll beispielsweise dazu dienen, sich mithilfe eines ausgedruckten QR-Codes an einer Rezeption gegenüber einem Hotel oder auf der Straße gegenüber einer Polizistin zu identifizieren. Das kam wohl zwischenzeitlich tatsächlich testweise zum Einsatz.
Was aber, wenn die Hackerin Mallory einfach den QR-Code an der Hotel-Rezeption austauscht und dieser nun einfach auf ihren eigenen Server verweist, statt auf den Server des Hotels? Dann kann Mallory sich gegenüber Bob als Alice und gegenüber Alice als Bob ausgeben. Am Ende besitzt Mallory den verifizierten Datensatz von Bob und weder Alice noch Bob haben davon etwas mitbekommen. Geheimdienste lieben diesen Trick.
2. Herstellen einer Vertrauensbeziehung
Bei diesem Verfahren scannt der User einen QR-Code — in der Regel von einer Website — und bekommt daraufhin — ähnlich wie bei der direkten Übermittlung — eine Anfrage, ob er sich mit Alice verbinden möchte. Er kann dabei genau wie bei der direkten Verbindung nicht nachprüfen, ob er sich gerade wirklich mit Alice verbunden hat oder mit der Hackerin Mallory.
Sollte er sich mit der Hackerin Mallory verbunden haben, könnte diese nun über ein Gateway Credential-Proof-Anfragen als Alice an Bob schicken und nach seiner Zustimmung in der App Bobs signierte Ausweisdaten erhalten.
Zusammenfassung
Es ist für Bob absolut nicht nachvollziehbar, wem er da gerade seine verifizierten Daten gegeben hat. Hier sollte man auch bedenken: den “Digitalen Ausweis zeigen” ist nur bedingt mit dem Vorzeigen des Ausweises in der offline-Welt vergleichbar. Wenn ich meine Daten mit Signaturen der Bundesdruckerei dran online weitergebe, dann sind das nachweisbar richtige Daten. Diese bleiben auch langfristig nachweisbar korrekt. Das bedeutet, möchte die Hackerin Mallory diese Daten einmal verkaufen, kann sie ihren Freund*innen in der Underground Economy jederzeit beweisen, dass die Ausweisdaten die sie von Nutzer*innen abgefangen hat, echt sind. Für Missbrauch bieten sich diese verifizierten Daten dann natürlich hervorragend an.
Gerade falls es durch ein solches Protokoll zur Normalisierung des Prozesses “Online Ausweis zeigen” kommen sollte, wäre es nur eine Frage der Zeit, bis solcher Missbrauch in der Realität auftreten würden und dadurch unberechtigte Datenbanken mit echten Nutzer*innen Daten geschaffen würden. Die Kontrolle über diese Daten ist dann unwiederbringlich verloren.
Im DIDCOM v1 Protokoll wurde bisher das Problem von MitM-Attacken nicht ausreichend berücksichtigt, was der SSI-Community scheinbar bekannt ist und wofür es auch noch keine Lösung im Standard gibt.
Dieses Problem könnte man beheben, indem sich Entitäten, die Zugriff auf Ausweise erhalten wollen — ähnlich wie schon beim Prinzip der Ausweisapp 2 — vorher verifizieren und diese Verifikation dann für die Nutzer*innen nachprüfbar zu machen. Dabei wäre es wünschenswert, unterschiedliche Vertrauensniveaus — je nachdem, welche Art von Daten abgefragt werden soll — anzubieten.
In der analogen Welt ist es völlig normal, dass man sich von einer Polizistin, die nach dem Ausweis fragt, erstmal ihren Polizeidienstausweis zeigen lässt. Dem Bundeskanzler*innen-Amt scheint das aber ein unbekannter Prozess zu sein oder sie hielten ihn in der digitalen Welt einfach für nicht relevant.
Ja, das ist mal wieder keine krasse Sicherheitslücke, sondern einfach ein Defizit im Protokoll. Also dem Konzept, wie sich Leute vorgestellt haben, wie Identifizierungen im digitalen Raum funktionieren sollten.
Wir haben dieses Problem bei der direkten Verbindung genau so verifizieren können. Für den Proof of Concept beim Modell “Herstellen einer Vertrauensbeziehung” fehlt uns leider momentan die Zeit sowie der Zugang zur App und ihrer Infrastruktur, um das abschließend zu beweisen. Wir sind Stand jetzt — nach diversen Einschüchterungsversuchen in unserem Umfeld durch die esatus AG (die stehen hinter der Digital Enabling GmbH) und das Bundeskanzler*innen-Amt — aber auch eigentlich nicht mehr sehr motiviert, daran weiterzuarbeiten und gemeinsam Lösungen zu finden.
Da das Bundeskanzler*innen-Amt sich ja nun zusammen mit der esatus AG erst mal einige Wochen genommen hat, um die drängendsten Sicherheits- und Infrastrukturdefizite anzugehen, wäre es vermutlich ratsam, wenn diese sich noch ein paar weitere Monate gönnen würden, um die grundlegenden Probleme des Protokolls zu verstehen und zu beheben.
Die Digitale Identitätsinfrastruktur eines Staates ist kein nebenbei-Projekt für einen Digitalisierungs-Hackathon. Innerhalb des letzten Jahrzehnts haben wir in Deutschland viel Wissen angesammelt, wie ein solches System sicher und nachhaltig funktionieren kann. Leider ist dieses Wissen momentan nicht an der Stelle, an der es wirklich benötigt wird. Es ist nicht in der Verwaltung. Wir raten von agilen Ansätzen im Kontext von Digitalen Identitäten ab, auch wenn diese anscheinend gerade wieder einmal sehr im Trend liegen.
Denn #FailFastFailOften bedeutet in diesem Kontext, dass dabei Daten abfließen und Identitäten abgegriffen werden, über die dann geschädigte Nutzer*innen keine Kontrolle zurück erhalten können. Wenn eine solche Lösung erneut in Produktion gehen soll, muss dringend nach etablierten und anerkannten Standards der IT-Security (wie Secure by Design und Secure by Default) agiert werden. Und auch eine gesetzliche Grundlage für digitale Ausweise muss geschaffen werden, denn diese fehlt derzeit übrigens auch noch.
Des Weiteren sollte das Bundeskanzler*innen-Amt diese Zeit dringend nutzen, um noch mal darüber nachzudenken, wie es mit der Zivilgesellschaft als auch der Sicherheitsforscher*innen Community umgehen will, dann bald hoffentlich nicht mehr unter CDU-Führung. Oder um es noch ein letztes Mal mit den Worten eures digitalen Referatsleiters im Bundeskanzler*innen-Amt zu sagen:
Hier findet ihr unseren zugehörigen Code zum selber nachvollziehen.
Dies war eine gemeinsame Recherche von fluepke und mir, Lilith Wittmann. Wir möchten uns bedanken bei all den Menschen die uns dabei unterstützt haben. Insbesondere bei HonkHase für die Qualitätssicherung der Aussagen in diesem Artikel.
Die zivilgesellschaftliche Arbeit von fluepke und mir kannst Du auf Patreon unterstützen.
Update 05.10.: Die Tweets von Tobias Plate wurden zwischenzeitlich gelöscht und deshalb durch Screenshots ersetzt.
