Wer baut den besten Impfausweis?

Stefan Adolf
Mar 10 · 18 min read

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.

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.

ubirch event log ecosystem (Quelle: github, Stand 09.03.2021)
  • 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.

Quelle: ubirch (Stand 9.3.2021)

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:

Quelle: govdigital (Stand: 09.03.2021)
https://ubirch.de/v#f=Mustermann;g=Felix;b=19680812;p=T01000322;i=3CF75K8D0L;d=202008261430;t=PCR;r=n;s=2feffc151cb726bb9ed7
Quelle: ubirch (Stand 09.03.2021)
Visualisierung der Chain-Verankerung (Quelle: ubirch, Stand 09.03.2021)
Ankertransaktion auf govdigital (Ethereum PoA) Stand: 09.03.2021

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.

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?

Quelle: ubirch (Stand 09.03.2021)

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)

  • 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)

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.

Quelle: Youtube

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.

4. Die bessere Alternative: Verifiable Covid Credentials

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:

  • 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
  • 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

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:

  • 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
Quelle: W3C
  • 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.

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.

  • 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.

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?

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

  • 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

t14g

The future runs faster than the present.

t14g

The future runs faster than the present. t14g is run by the fine people working at Turbine Kreuzberg.

Stefan Adolf

Written by

Developer Ambassador for Turbine Kreuzberg & señor fullstack developer: Symfony, node, Mongo, Solidity, Gatsby, React. Lives to code — dies for Rock’n’Roll 🎸.

t14g

The future runs faster than the present. t14g is run by the fine people working at Turbine Kreuzberg.