Wer baut den besten Impfausweis?
tl;dr
Der Bund hat unter Hochdruck ein Konsortium aus IBM und ubirch damit beauftragt, eine Lösung für digitale Impfnachweise zu entwickeln. Mit dieser Entscheidung setzt man auf eine Lösung, die Impfzertifikate auf mehreren Blockchains verankert, personenbezogene und korrelierbare Daten beim Überprüfen offenlegt und zur Identitätsprüfung weitere analoge Merkmale benötigt.
Wir diskutieren im Folgenden, warum man nicht besser dem international laufenden Standardisierungsverfahren folgt und mit auf Self Sovereign Identities (SSI) basierten Verifiable Credentials (VC) einen Ansatz wählt, der sowohl aus Effizienz-, Datenschutz- und Interoperabilitätsgründen für den internationalen Einsatz deutlich besser geeignet wäre.
––––
Seit dem 9. März 2021 ist klar: Die 2.7 Mio. schwere Ausschreibung des Bundes über die Entwicklung eines datenschutzkonformen, digital auswertbaren und fälschungssicheren Impfnachweises geht an ein Konsortium aus dem Kölner Startup Ubirch und dem Software-Konzern IBM. Innerhalb von 12 Wochen sollen sie (auf Grundlage ihrer bisherigen Entwicklungen) einen Impfnachweis entwickeln, der es Personen ermöglicht, ihren Immunitätsstatus z.B. in Flugzeugen oder an Theaterkassen nachzuweisen.
Im folgenden analysieren, bewerten und kritisieren wir diesen Ansatz. Wir beschäftigen uns seit Anfang 2021 mit digitalen Impfzertifikaten gemäß internationaler interoperabler Standards im dezentralen Umfeld, verfolgen aufmerksam alle Aktivitäten der internationalen Initiativen und entwickeln angesichts der Vielfalt der weltweit zum Einsatz kommenden Impfzertifikate derzeit quelloffen einen “universal verifier”, der in der Lage sein soll, alle Varianten solcher Zertifikate zu verifizieren. Inspiriert wurde dieser Artikel von folgendem Tweet:
Wir möchten vorwegschicken, dass wir uns zwar mit ubirch’s Protokoll auf Quellcode-Ebene auseinandergesetzt haben, aber mangels direkter Erfahrung mit dem Code einige technische Details im folgenden möglicherweise nicht zu 100% korrekt darstellen. Wir behaupten, dass diese Fehler für die generelle Bewertung des Ansatzes aber zu vernachlässigen sind und beheben sie nach konstruktiven Hinweise gerne nachträglich.
1. Analyse
Wie sich den heute dazu erschienenen Artikeln und Tweets entnehmen lässt, beruht die Sicherheit von ubirchs Lösung auf einer Verankerung der Hashes von Impfzertifikaten auf mehreren Blockchains. Persönliche Informationen sind von diesen öffentlich sichtbaren Hash-Ankern nicht ableitbar. Im Detail ist die Verankerung ein wenig komplizierter, denn würde man tatsächlich jeden einzelnen Hash eines Zertifikats auf eine lineare Blockchain schreiben, stieße man unweigerlich an die Leistungsgrenzen von dezentralen Ledgern.
Daher nutzt ubirch ein Rollup-Prinzip, das auch in Level 2-Netzwerken oder in zugangsfreien dezentralen Dateisystemen wie IPFS genutzt wird. Nodes sammeln über einen längeren Zeitraum Zertifikatshashes, ordnen sie gemäß ihrer empfangenen Reihenfolge zu einer Baumstruktur und bilden daraus einen durch Hashlinks verbundenen Merkle-Tree, dessen Root-Knoten auf der Chain verankert wird. Man kann nun lediglich durch Kenntnis eines Zertifikats, seiner Eltern-Hashes im Merkle-Tree und der Ankertransaktion des Root-Hashes beweisen, dass das Zertifikat zu einem bestimmten Zeitpunkt verfügbar war und seither nicht verändert wurde.
Diese Komplexität hat ubirch ursprünglich nicht für Impfnachweise entwickelt, sondern um massenweise IoT-Events auf Blockchains zu verankern. Daher ist ihre Implementierung primär auf Skalierbarkeit ausgelegt und wird quelloffen in Scala zur Verfügung gestellt. Ubirch stellt Clients in Go, C++ , Java und Python ebenfalls quelloffen zur Verfügung.
Interessant ist die Auswahl von Blockchains, auf die ubirch Ankertransaktionen schreibt:
- Ethereum (Netzwerk unbekannt)
- Ethereum Classic: ein seit 2016 existierender Ethereum-Fork, der mittlerweile nahezu keine praktische Relevanz mehr hat und nicht update-fähig ist
- IOTA Mainnet: ein durch die IOTA Foundation entwickeltes DAG-Protokoll (“Tangle”), das kostenlose geldwerte Transaktionen zulässt, indem es den PoW zu den Clients verschiebt, die dafür zwei vorhergehende Transaktionen (“Tips”) wählen müssen. Bis heute ist IOTA’s Konsens mangels intrinsischer Inzentivierung auf einen zentral betriebenen Coordinator angewiesen, der bereits seit 2017 (!) durch einen kurz bevorstehenden (!!) “Coordicide” obsolet gemacht werden soll. Das aktuelle Vorhaben “GoShimmer” ist auf dem besten Wege dahin, aber es ist nicht klar, ob sich ein uninzentivierter dezentraler Konsens überhaupt in der höchst aversiven Welt der Kryptoprotokolle stabilisieren lässt.
- GovDigital: ein von der gleichnamigen “Genossenschaft zur Integration innovativer IT-Lösungen der digitalen Daseinsvorsorge im öffentlichen Sektor” betriebenes zugangsbeschränktes aber lesefreies Ethereum PoA-Netzwerk (Geth), mit Validatoren aus dem staatlichen / institutionellen Umfeld und fragwürdiger Dezentralität.
- Bloxberg: ein von internationalen Forschungsinstitutionen (z.B. KIT, FIT, TH Köln u.v.a.) aufgesetztes und betriebenes, zugangsbeschränktes Ethereum PoA-Netzwerk mit einem simplen Faucet-System.
Use Cases
Eine einfache Erläuterung des Funktionsprinzips findet Ihr auch hier im Original.
Die persönlichen und medizinischen Informationen, die zur Erzeugung und Verifikation des Zertifikats notwendig sind, werden während der Ausstellung des Zertifikats kodiert, aber unverschlüsselt in einen QR-Code verpackt und dieser dem Patienten mit der Bitte um sichere Verwahrung mitgegeben, z.B. auf Papier, per Email oder einer dafür geeigneten, proprietären Software-Wallet (die vermutlich IBM liefern soll).
Der Hash wird mittels oben genanntem Verfahren mit vielen anderen Hashes zu einem Merkle-Root kondensiert und dieser auf Blockchains verankert. Ein Prüfer kann einen QR-Code scannen, die Klartext-Informationen entnehmen, daraus erneut einen Hash erzeugen und einen ubirch “Filter-Node” beauftragen, ihn mit Hilfe anderer Hashes des entsprechenden Merkle-Trees aufzulösen. Heraus kommt eine Blockchain-Transaktion, die gewissermaßen den Hash der Impf-Informationen des Patienten enthält. So will ubirch sicherstellen, dass die präsentierte Information exakt der entspricht, die zu einem bestimmten Zeitpunkt von einer bestimmten Person (dem “Arzt”) über den Präsentierer getroffen wurde.
Demo
Man kann die Informationen leicht anhand der öffentlichen zugänglichen Demonstratoren extrahieren und auf Blockchains nachverfolgen: Hier ist ein QR-Code, der auf govdigital veröffentlicht wurde:
Wer ihn scannt, erhält folgendes Resultat vom QR-Typ “URL”:
https://ubirch.de/v#f=Mustermann;g=Felix;b=19680812;p=T01000322;i=3CF75K8D0L;d=202008261430;t=PCR;r=n;s=2feffc151cb726bb9ed7Wer die URL besucht, sieht folgendes:
Ubirch selbst bietet eine Visualisierung der hinterlegten Anker an:
und verlinkt auf die einzelnen Chain-Explorer, in denen man die Ankertransaktion sehen kann:
2. Bewertung
Man muss sich zunächst vor Augen führen, wozu ein Impfnachweis in der Praxis dienen soll; zwei Anwendungsfälle stechen dabei heraus. Im einfachsten Fall möchte man an der “Tür” eines Theaters, einer Bar oder eines Einkaufszentrums sicherstellen, dass die Eintretenden eine vergleichsweise geringe Infektionsgefahr für andere darstellen.
Man kann diesen Case zweifach ausgestalten: Man kann z.B. ausschließlich geimpften Personen den Zutritt gewähren (was effektiv zur Debatte einer Impfpflicht führt, in die wir hier nicht einsteigen möchten), um sicherzustellen, dass selbst wenn eine davon infektiös ist, sich alle anderen nicht anstecken können und von der Veranstaltung selbst keinerlei Gefahr ausgeht, zum Superspreading-Event zu werden. Andererseits kann man Geimpfte und (potenziell) nicht Geimpfte räumlich so stark mischen, dass eine maximale räumliche Distanz zu potenziell ansteckenden Personen gewahrt wird.
Der typische Anwendungsfall ist allerdings der internationale Reiseverkehr: Seit Jahrzehnten erlauben z.B. manche Länder die Einreise nur unter Vorlage einer gültigen Gelbfieberimpfung. Fluggesellschaften können daher durchaus darauf bestehen, dass Fluggäste einen aktuellen Testnachweis oder eben einen Impfnachweis erbringen, bevor sie den Passagier transportieren.
Die Fälschungssicherheit eines Impfpasses mag manchem zunächst als überzogene Anforderung erscheinen, tatsächlich sind Fälle bekannt, in denen sich Reisende illegal Testausweise erschlichen haben und deren Aussteller dafür auch hart bestraft wurden. Der Schwarzmarktpreis eines gefälschten Testergebnisses lag laut diesen Quellen zwischen 150 und 300€.
Die ubirch-Lösung entspricht in ihrer Handhabung etwa dem Verfahren, das in China oder Israel (“Green Pass”) zum Einsatz kommt: Der Nachweisführende präsentiert eine Ankerinformation und persönliche Merkmale, der Verifizierer schlägt das entsprechende Zertifikat nach, prüft dessen Echtheit und gleicht ein analoges Merkmal (z.B. den Namen einer Person) vor Ort ab. Unter Gesichtspunkten des Datenschutzes ist ubirch vermutlich vielen anderen Lösungen weit voraus, da die Impfnachweise selbst in keinem zentralen Register stehen, sondern vom Nachweisführer selbst beigebracht werden.
3. Kritik
Wer ist eigentlich berechtigt, solche Impfzertifikate auszustellen? Einfache (naive) Antworten: das BMG, Hausärzte, Bundeswehrsoldaten im Impfzentrum oder Vertrauensstellen der Krankenkassen. Transportiert man diese Antworten ins Digitale, wird es aber plötzlich sehr kompliziert: Wer verhindert, dass ich als Programmierer kein Zertifikat über mich selbst ausstelle, und es mit Hilfe der für Verifizierer offen zugänglichen Nodes auf eine Blockchain schreibe?
Es gibt für diese Frage einige sehr gute Antworten, die Ihr weiter unten findet. Im Rahmen der ubirch-Lösung ist sie aber primitiv: Irgendjemand muss den schreibenden Zugang für die Zertifikatshashes beschränken. Anders formuliert und sehr stark vereinfacht: Eine Hausarztpraxis muss sich bei ubirch “anmelden”, damit sie Zertifikate für ihre Patienten ausstellen und verankern kann. Die Kooperation mit IBM soll in Deutschland dafür sorgen, dass dieser Prozess reibungslos in den Praxis- / Impfzentrumsalltag integriert wird. Hier ein Zitat von der ubirch-Website:
Der Digitale Impfnachweis wird vor Ort im Impfzentrum oder beim Hausarzt erstellt. Die erforderlichen personenbezogenen und Impfdaten können direkt aus dem vor Ort genutzten System übernommen werden. Dafür gibt es bereits Integrationen wie beispielsweise in Excel, weitere sind möglich. Alternativ werden die Daten über ein schlankes WebInterface bzw. eine App erfasst. Durch eine weitestgehende Automatisierung bleibt der Aufwand minimal und lässt sich leicht in den Impfprozess integrieren.
Um die Systeme von Hausärzten dazu zu autorisieren, solche Zertifikate mit Hilfe von ubirch-Nodes auf Blokchains zu verankern, bedarf es eines großen organisatorischen Integrationsaufwands: Arztpraxen müssen sich gegen IBM / ubirch authentifizieren (wer die Debatte um den KBV-seitigen Heilberufsausweis verfolgt weiß, wie viel Sprengstoff dieses Thema birgt) und unterliegen nun allen Gefahren, die eine zentrale Autorisierung mit sich bringt: verlorene Schlüssel, betrügerische Absichten, Mehrfachverwendung von Schlüsselmaterial, Kompromittierung der Schlüsselkarten, technische Komplikationen usw.
Nachweisführung und Identifikation
Wer am Fluggate seinen ubirch-Impfnachweis vorlegt, präsentiert vorrangig ein (digitales) Stück Papier, dessen Inhalt der Verifizierer auf einer Blockchain nachschlagen und damit ziemlich sicher sein kann, dass die Informationen auf dem Papier korrekt sind und zu welchem Zeitpunkt sie ausgestellt wurden. Diese Information alleine würde keinesfalls genügen, um eine Impfung der Person zu bescheinigen, weil sie sehr einfach kopierbar ist. Daher muss der Nachweisende zusätzlich persönlich identifizierbare Informationen vorlegen, die Bestandteil des Zertifikatshashes sind. Im aktuellen ubirch-Fall sind dies (es werden die Anwendungsfälle “Corona-Test” und “Corona-Impfung” behandelt)
- der volle Name
- das vollständige Geburtsdatum
- Eine persönliche Identifikationsnummer (z.B. Reisepass oder Patienten-ID)
- Eine Identifikationsnummer des Tests bzw. Impfnachweisdokuments
- Ein Testdatum bzw. die Impfdaten
- Die Testmethode bzw. der verwendete Impfstoff
- das Testergebnis (positiv / negativ)
Sobald ein Verifizierer sich vergewissert hat, dass er dem Zertifikat selbst trauen kann, vergleicht er nun diese Informationen mit weiteren Merkmalen des Nachweisführers, z.B. dessen Personalausweis.
Ich hoffe, jemand hat die Glocken gerade klingeln gehört: Es stecken zwar keinerlei private Informationen im Ankerzertifikat, aber jeder Verifizierer erhält an dieser Stelle Zugriff auf eine Menge persönliche und medizinische Informationen, die für den eigentlichen Nachweis einer Immunisierung völlig überflüssig sind. Da dieser Abgleich manuell stattfindet, ist er fehleranfällig und wenn man ihn digitalisiert führt er zu einer maximalen Korrelierbarkeit personenbezogener Daten.
Das ist im internationalen Flugverkehr sicherlich noch hinnehmbar, aber für lokale Usecases ein maximales Datenschutzdesaster: Warum sollte Dieter Hallervordens Schlossparktheater (das Ihr bitte sofort besucht, sobald Ihr Eure zweite Impfung im Arm habt!) oder die Monkey-Bar Eure Versichertennummer oder Euren Geburtstag erfahren, wenn Ihr einfach nur nachweisen müsst, dass Ihr geimpft seid?
Sicherheit der Nachweisführung
Richtig Spaß macht ein Impfnachweis, der monatelang auf einem Zettel zusammen mit dem Personalausweis durch jede Bar getragen wird, nicht. Daher arbeitet die IOTA Foundation zusammen mit einem der namhaftesten Hersteller von fälschungssicheren Smartcards (Zebra) an einem Impfausweis auf einer Plastikkarte, die sowohl die gedruckten Informationen des Zertifikats und den entsprechenden QR-Code, eine über NFC zugängliche digitale Version des Zertifikats und als zusätzliches Sicherheitsmerkmal (“Evidence”) das Passbild des Trägers enthält.
Davon abgesehen, dass der Druck einer solchen Karte nicht billig und auf planetarem Scale auch kaum durchführbar ist, stellt sich die Frage, ob der impfende Arzt auch ein Foto des Patienten schießen soll oder ob man es durch Korrelation mit den Versichertendaten (Stichwort: ePA / eGK) beziehen kann und wer diese Schnittstelle in sicherer Form bereitstellen könnte oder, viel einfacher: Wer die dafür notwendigen Zebra-Drucker betreibt und finanziert.
Wer braucht eine Blockchain, wenn er 5 benutzen kann?
Wirklich absurd wird es, wenn man die Onchain-Speicherung der Impfnachweise betrachtet. Der einzige denkbare Grund, warum man den Nachweis (bis zu) 5x auf irgendwelchen ominösen PoA-Chains verankert ist, dass eine dieser Blockchains oder der Zugang für Verifier zu ihnen “ausfällt” oder der beschränkte Zugang zu ihnen kompromittiert wird und es einem Angreifer gelingt, Transaktionen zu schreiben, die er nicht schreiben können sollte.
Das ist genau der Grund, warum jeder, der das Thema Blockchain wirklich ernst nimmt, verstehen sollte, dass permissioned Blockchains außerhalb eines industriellen bzw. notariellen Einsatzes (z.B. in ubirch’s ursprünglichem Usecase der Maschinentransaktionen oder im POAnetwork) keinerlei Vorteile gegenüber replizierten Datenbanken haben.
Blockchains ermöglichen es dank ihres verteilten Konsensmodells, dass einander völlig unbekannte Teilnehmer, die sich nicht nur nicht vertrauen, sondern sogar gegenteilige Interessen vertreten, miteinander auf einer vertrauensvollen (bzw. vertrauenslosen, je nach Betrachtung) Grundlagentechnologie miteinander Transaktionen austauschen können — ein Konzept, das als “Coopetition” bekannt ist und das Ethereum Mainnet zu einer außerordentlich gut funktionierenden, bis heute nicht kompromittierten Plattform des maschinellen Vertrauen gemacht hat, die tagtäglich Milliardenwerte absichert und verschiebt.
Die Stabilität dieser Netzwerke wird intrinsisch inzentiviert: Dadurch sind sie ab einer gewissen Größe (z.B. durch die Verteilung von PoW-Minern oder der Verteilung von PoS-Stakes im Eth2-Netzwerk) absolut unkomprimittierbar und unabschaltbar; fällt ein Node aus, kann man sich jederzeit mit einem anderen verbinden.
Eines der größten Missverständnisse von klassischen Unternehmen, die Blockchain-Technologie für sich entdecken ist, dass man ein “dediziertes” Blockchain-Netzwerk aufsetzen und mit Passwörtern nur bestimmten Teilnehmern zur Verfügung stellen kann. Man verschiebt damit nämlich den grundsätzlichen Sicherheitsgedanken, dass Teilnehmer ihre Berechtigungen durch transparente Smart Contracts gewährt bekommen, an die Vordertür der Validator-Nodes und verliert alle Mechanismen, die onchain zur Absicherung und Vergabe dieser Berechtigungen vorhanden sind, wie Multisignatur-Wallets, DAOs oder tokenbasierte Rechte-Vergabe.
Doch die viel relevantere Frage ist: Muss man überhaupt Impfzertifikate auf eine Blockchain schreiben, damit sie sicher sind?
Nein.
4. Die bessere Alternative: Verifiable Covid Credentials
Stell Dir vor, die ganze Welt einigt sich gerade auf eine Lösung, aber ein deutsches Startup hat eine “bessere” Idee.
Die Herausforderung, einen sicheren digitalen und maximal interoperablen Impfnachweis herzustellen, der auch auf globaler Ebene für alle möglichen denkbaren Einsatzszenarien funktioniert, und ihn binnen weniger Monate zu realisieren ist so groß, dass viele kluge Köpfe sich seit längerer Zeit damit beschäftigen. Sie versuchen, zu einem globalen Konsens über Formate und Interaktionen auf Grundlage dafür geeigneter Technologie-Stacks und -Standards zu gelangen. Für Implementierer innerhalb der Europäischen Union setzt ein Papier der Europäischen Kommission vom 27. Januar 2021 die Richtlinien, nach denen ein Impfnachweis idealerweise gestaltet werden sollte:
Initiativen
Ehrlich: Wie viele Unternehmen, glaubt Ihr, arbeiten weltweit an dem Problem der “nachweisbaren, unfälschbaren, interoperablen, datensparsamen Impfzertifikate”? Wir haben nicht gezählt, aber hier sind ein paar der größten Initiativen, die viele Partnerunternehmen hinter sich vereinen oder auf Grundlage staatlicher Vorgaben längst an global einsetzbaren Lösungen arbeiten:
- Good Health Pass Collaborative (gegründet im Februar 2021)
eine technologisch agnostische unabhängige “Dachorganisation”, die primär die Kommunikation zwischen Herstellern koordinieren möchte und der auch ubirch angehört. - Linux Foundation Public Health Covid Credentials Initiative (Q2/2020)
arbeitet primär im nordamerikanischen / britischen politischen Umfeld und vereint Initiativen zur schematischen und technischen Ausgestaltung eines SSI/DID/VC-Prozesses
- Vaccination Credential Initiative (Dez 2020)
Microsoft, Salesforce, Oracle u.a., arbeiten an einem Credential-Standard auf Grundlage der sog. FHIR4/HL7 kompatiblen SMART Health Cards (Microsoft) - CanImmunize
Kanadische Initiative zur Definition eines auf medizinischen Formaten basierenden Impfdokuments - IATA Travel Pass
eine von Fluggesellschaften getriebene Initiative, einen digitalen “Travel Pass” zu entwickeln, um den internationalen Flugverkehr wieder öffnen zu können
Eine weit darüber hinaus gehende, außerordentlich erschöpfende Liste vieler Unternehmen, die bereits Lösungen hierfür vorgestellt haben, die in einigen kleineren oder größeren Ländern (Indien!) bereits im Einsatz oder der Erprobung sind, hat der kanadische Startup-Gründer und Canimmunize-Supporter David Janes in einem detaillierten Google Document zusammengetragen.
Self Sovereign Identity & Verifiable Credentials
Seit 2014 tragen unterschiedlichste Unternehmen unter dem Dach der Decentralized Identity Foundation (DIF) Spezifikationen, Implementierungen und Standards zusammen, die nicht weniger als der Revolution der Frage nachgehen: Was ist eigentlich eine digitale Identität und wie weist man sich damit gegenüber digitalen Systemen aus? Im Kern funktioniert es wie folgt:
- Eine Identität ist eine Sammlung von Schlüsselpaaren, die vollständig unter der Kontrolle einer Entität (Mensch oder Maschine) sind.
- Technisch wird diese Identität durch einen global eindeutigen Dezentralen Identifizierer (DID) repräsentiert, z.B. did:ethr:0x90f8bf6a479f320ead074411a4b0e7944ea8c9c1
- Mit Hilfe von sogenannten Resolvern lassen sich DIDs zu DID Dokumenten auflösen, die das gerade aktuelle, öffentliche Schlüsselmaterial, das eine DID benutzt zugänglich macht. Es gibt vielfältige zentrale und dezentrale Verfahren, darunter auch Blockchain-basierte, wie ein Resolver die vom Controller hinterlegten Schlüssel seiner DID zu einem DID Dokument auflösen kann. Eine naive ist die Verankerung von Changesets als Events auf der Ethereum-Blockchain, komplexere wie das chain-agnostische Sidetree nutzen dafür Merkle Tree-Verfahren, um mit Hilfe von DLTs viele Changesets in einer nachweisbaren Ordnung zu speichern. Firmen wie Jolocom arbeiten z.B. an einer vollständig Peer-basierten Identität, die ihre selbstsignierten Changesets als lokal verifizierbares Eventlog (KERI) auf Anfrage mit Resolvern teilt.
- Ein DID-Dokument enthält keinerlei personenbezogene oder sonstige Profilinformationen wie E-Mail-Adressen oder URLs. Es enthält stattdessen lediglich die aktuelle Liste an Public Keys, deren Verwendungszwecke und Referenzen auf Registrierungs-Dienste, auf denen man mit der DID zusammenhängende Informationen abrufen kann. Dennoch gibt es Anbieter, die eine DID mit einem “gewohnten” sozialen Profil anreichern, wenn man das möchte. 3Box war dafür ein großartiges Beispiel, befindet sich aber derzeit in einer großen strategischen Transformation.
- Die privaten Schlüssel hinter der DID müssen vom Inhaber sicher aufbewahrt werden. Hierfür gibt es zahllose Wallets (z.B. Jolocom, lissi, trinsic, connect.me), die mehr oder weniger nutzerfreundlich unter Zuhilfenahme von Secure Elements, Passphrases, Mnemonics oder biometrischen Verfahren ein grundlegendes hohes Sicherheitsniveau herstellen
- Der Controller einer DID kann seine privaten Schlüssel nutzen, um Daten für verschiedene Anwendungsfälle zu signieren
- Der wichtigste Anwendungsfall ist die Ausstellung von “Verifiable Credentials” (VC). Das sind Statements (“Claims”), die eine Identität über eine andere trifft und die kryptografisch von einem “Verifier” überprüfbar sind. Das klassische Beispiel für VCs ist ein “Universitätsabschluss”, den eine Universität über einen Alumni ausstellt und ihm diesen an eine Credential-Wallet überträgt.
- Verifiable Credentials sind in sich geschlossene, maschinenles- und kryptografisch überprüfbare Dateien, die theoretisch in jedem beliebigen System aufbewahrt werden können. Der “Träger” eines Credentials wird als “Holder” bezeichnet und wird zum “Prover”, sobald er von einem “Verifier” darum gebeten wird, ein Credential, das bestimmten Kriterien genügt (“hat Universitätsabschluss”) zu präsentieren
- Die Claims innerhalb der VCs (“subjects”) werden üblicherweise in klar schematisierten JSON-LD Datenstrukturen abgelegt, sodass ein Verifizierer ohne Kenntnis der ursprünglichen Claim-Absicht eine Vorstellung von der Semantik der Felder innerhalb des Claims erhalten kann.
- Es existieren bereits in der Praxis sog. zero knowledge-Verfahren, die es einem Holder erlauben, einem Verifier nur bestimmte, oder sogar funktional abgeleitete Aspekte eines Credentials zu präsentieren, ohne dass der Herausgeber diese Kombination oder Variation bei der Erstellung des Credentials vorausgesehen oder individuell signiert hätte.
Immunization Credentials
Um ein global akzeptiertes “Covid Credential” für Tests oder Impfungen herauszugeben, muss sich die Community darauf einigen, welche Informationen für einen Impfnachweis überhaupt relevant sind. Das oben genannte Papier der europäischen Kommission gibt dafür eine gute Vorlage, aber auch Spezifikationen innerhalb des FHIR/HL7-Konsortiums (getrieben von Microsoft) oder der global anerkannten “Semantic Web” Initiative schema.org sind auf einem guten Weg, einen akzeptablen Standard für medizinische Informationen innerhalb von Credentials zu entwickeln, der mit Medizinsystemen generell kompatibel sind. Selbst wenn es mehrere solcher Standards gibt, ist ein Verifier entweder durch Auflösung der referenzierten JSON-LD Schemata oder durch Auflösung eines referenzierten Credential Schemas die Semantik eines Claims innerhalb eines Credentials zu verstehen.
Der Prozess, nach dem Credentials zwischen Issuer und Holder bzw. zwischen Prover und Verifier ausgetauscht werden, ist grundsätzlich spezifiziert und referenzimplementiert (Jolocom, Hyperledger Aries). Der Standard, nach dem alle Parteien gegenseitig verschlüsselt Informationen miteinander austauschen, ist ebenfalls spezifiziert (DIDComm 2.0, Jolocom), aber noch längst nicht von allen Parteien interoperabel umgesetzt.
Wann ist der Arzt eine Ärztin?
Verifiable Credentials werden durch einen autorisierten Issuer (“Arzt”) herausgegeben, der dafür zunächst nicht notwendigerweise bei einer zentralen Stelle “angemeldet” sein muss. Die Erstellung von Credentials kann gemäß Spezifikation offline geschehen, wird von vielen kommerziellen Anbietern aber gerne kostenpflichtig angeboten. Jemand, der sich für einen Arzt hält, kann daher völlig unbeschränkt Impfzertifikate an beliebige Personen ausstellen, die niemals auf irgendeiner öffentlich sichtbaren Blockchain landen. Wer ein solches Credential präsentiert bekommt und die DIDs von Patient und Arzt resolven kann (dafür benötigt er ggf. lesenden Zugang zu einer öffentlichen Blockchain, auf dem die DIDs von Arzt und Patient verankert sind), kann jederzeit verifizieren, dass der Inhalt des Credentials kryptographisch der Wahrheit entspricht.
Das eigentliche Problem ist aber auch hier die Frage “ist der Arzt wirklich ein Arzt?”. Sie lässt sich im SSI-Szenario auf zwei Arten beantworten:
- Es existiert eine zentrale Registratur, die DIDs (oder Delegate-Keys) von Ärzten aufnimmt, die von übergeordneten Stellen (“WHO”, “BMG”, “KBV”) kontrolliert werden. Diese Registratur kann als Smart Contract oder DAO auf einer Blockchain implementiert sein, um maximales Vertrauen und Transparenz über die Issuer aufzubauen, sie kann aber —eine Analogie zu den “permissioned” Blockchains — auch mit einer hochverfügbaren Datenbank mit starker Zugangssicherheit implementiert werden.
- Es gibt nur einige wenige “Root”-Akteure (WHO, BMG, KBV), deren DIDs in einer (de)zentralen Registratur als solche ausgezeichnet werden. Ihre Anzahl ist so gering (weltweit wenige 1000), dass sie ohne weiteres auf einer öffentlichen Blockchain abgelegt werden können. Diese Akteure signieren zeitlich begrenzte “Arzt”-Credentials, die sie an Ärzte ausstellen und in einer öffentlich zugänglichen Credential Registry hinterlegen. Diese Registry sollte zwar aus Skalierungs- und Stabilitätsgründen dezentral angelegt sein und Schreibzugriffe nur von Root-Akteuren akzeptieren, muss aber keinesfalls auf Blockchains basieren — hierfür eignen sich dezentrale Filesysteme wie IPFS oder Sia ganz hervorragend. Ein Verifier, der einen Impfnachweis validieren möchte, prüft zunächst die Signatur des Arztes, sucht danach die DID des Arztes auf der dezentralen Credential Registry und prüft, ob ein dort hinterlegtes “Arzt-Credential” von einem der global beglaubigten Root-Akteure ausgestellt wurde. Dieses Verfahren erinnert an die “Chains of Trust”, die z.B. Browser nutzen, um SSL-Zertifikate zu überprüfen. Tatsächlich eignen sich auch herkömmliche X.509-Zertifikate zur Ausstellung von Credentials und DIDs, sind aber in Zeiten von kurvenbasierter Kryptographie (insb. Secp256k1 und EdDSA) eher unüblich.
Vorteile von Credential-basierten Lösungen gegenüber Chain-verankerten Zertifikaten
Der immense Vorteil eines Credential-basierten Impfnachweises ist die dezentrale Datenhaltung beim Patienten und die Verschiebung des Trust-Verhältnisses von einem chain-basierten Anker hin zu einer lokal verifizierbaren Signatur. Es gibt absolut keine Notwendigkeit, das Zertifikat selbst auf eine (oder 5!) Blockchain zu schreiben, weil die Credentials kryptografisch gegen Manipulation geschützt sind.
Weiterhin besteht keinerlei Notwendigkeit, Nodes zu betreiben, die Impftransaktionen zu einem nachweisbaren Merkle-Tree Root zusammenführen oder auflösen. Damit entfällt auch die Notwendigkeit von zentraler Infrastruktur, die ubirchs Lösung voraussetzt, um den Hash eines vorgelegten Impfnachweises auf der Chain finden zu können.
Die Informationen des Impfzertifikats können, wenn man etwas mehr Energie in die Implementierung und Herausgeber-Logik investiert, vom Patienten selektiv präsentiert werden. Für den Besuch in einer Bar genügt es, wenn der Prover nur die Signaturen über den Impfnachweis übermittelt (zuzüglich einer Wegwerf-Signatur, um damit gleich auch die Luca-App überflüssig zu machen, aber das ist wieder ein anderes Thema)
Es gibt eine überwältigende Menge an “Smart Wallets”, die hervorragend dafür geeignet sind, sowohl private Schlüssel der DIDs als auch die Credentials zu speichern, zu validieren und zu präsentieren. Hier ist eine Auswahl aus mehr als 150: Jolocom, Lissi, Connect.me, Trinsic und Civic.
SSI/DID-Technologien werden von Europa im Rahmen des EBSI und der ESSIF unterstützt und gefördert. In Deutschland arbeitet die Bundesdruckerei an eIDAS-konformen SSI-Lösungen, die auch beim deutschen Personalausweis zum Einsatz kommen werden. Es gibt vom Bund geförderte Initiativen wie IDUnion, die dedizierte dezentrale Identitäts-Netzwerke aufbauen und vorantreiben. Als Followup des “Schaufensters Sichere Digitale Identitäten” gehen 4 Projektkonsortien ab April in eine Prototyping-Phase über, in der sie im Feld gut verwendbare SSI-Lösungen für verschiedenste Anwendungsszenarien umsetzen.
Abwägung
Wenn also SSI- und Credential-basierte Verfahren so offensichtlich besser für Impfnachweise geeignet sind und international für den Einsatz vorbereitet werden als chain-basierte Zertifikatsanker, warum hat sich der Bund bei seiner Ausschreibung dagegen entschieden?
Man muss es klar sagen: SSI-Technologie ist trotz ihrer Historie und ihres revolutionären Anspruchs, digitale Identität vollständig zu liberalisieren, ebenfalls ein hochexperimenteller Ansatz. Ihr nachhaltiger Erfolg wird sich erst in einigen Jahren in der Breite einstellen, unter anderem auch untermauert durch eine eIDAS-kompatible Identität, die an den Personalausweis gekoppelt ist.
Wenn man die Wahl zwischen zwei hochexperimentellen Technologieansätzen für einen Anwendungsfall hat und eine Menge Budget, um sie umzusetzen, warum entscheidet man sich dann nicht für den, der in vielen Bereichen des öffentlichen und privaten Lebens Einzug halten wird, sondern für eine Insellösung, die zwar ein grundsätzliches Problem löst, danach aber nur in industriellen Nischen Relevanz hat?
Fazit
Vor dem Hintergrund der mit Hochdruck vorangetriebenen selbstsouveränen Identitäten ist es unlogisch, für Impfzertifikate auf eine Lösung zu setzen, die
- sich an keinen semantischen Standard hält,
- jedem Verifier eine unnötige Menge an privaten Informationen offenlegt,
- Daten unnötigerweise auf (obskuren) Blockchains verankert,
- auf proprietäre Lösungen zur Arztidentifikation angewiesen ist,
- sich an keine Regeln internationaler Interoperabilität hält und
- zur Überprüfung der Identität des Nachweisenden weitere analoge Merkmale zwingend voraussetzt
Warum sich der Bund im Rahmen einer 2,7 Mio. Euro starken, intransparenten Ausschreibung für dieses Konsortium entschieden hat, wird bis zur Darlegung der Entscheidungskriterien ein Rätsel bleiben. Sich für eine Lösung zu entscheiden, die im Feld, z.B. am Flughafen FFM und im Freistaat Bayern bereits vertestet wurde, liegt nahe. Das bedeutet aber nicht, dass sie interoperabel oder international anschlussfähig ist.
Uns bleibt nur zu sagen: Was auch immer Ihr für Impfzertifikate bauen wollt, wir werden versuchen, sie alle zu verifizieren! Toi toi toi.
Wer mitmachen möchte, unser Repo (sehr viele weiterführende tiefe Links im Readme!) und das dazugehörige NPM-Package findet Ihr hier:
