Blockchain + SSI = ID?

Der aktuelle Trend proklamiert Self-Sovereign-Identities (SSI) auf Blockchains / Distributed Ledger Technologies (DLT) für alle Bundesbürger, ja zukünftig sogar für alle EU-Bürger. Bei Lilith Wittmann gab es bereits einen Artikel zur desolaten Unsicherheit der “ID Wallet” auf Basis von Blockchain (https://lilithwittmann.medium.com/mit-der-id-wallet-kannst-du-alles-und-jeder-sein-au%C3%9Fer-du-musst-dich-ausweisen-829293739fa0) und im Chaos Radio Nr. 272 (https://chaosradio.de/cr272-id-wallet) wurden die Hintergründe dazu bereits angerissen. Auf Grund des hohen Interesses daran möchte ich hier darauf eingehen, was Blockchains und SSI sind, wo sie herkommen, was mal die Idee dahinter war und warum das alles für nationale und hoheitliche IDs (= “IDs für Alle”) eher widersprüchlich und ungeeignet ist.

!Update 1 am Ende des Artikels, Stand: 28.10.2021 18:00, 1.1!

https://medium.com/@sbmeunier/when-do-you-need-blockchain-decision-models-a5c40e7c9ba1

Dieser Artikel ist auf Deutsch. / The following article is mainly intended for German audience to understand some facts behind SSI and Blockchain in context of national IDs in Europe. Feel free to use DeepL or similar to translate. If there is a higher demand for an (updated) English version I might add that later.

1. Blockchains und DLTs

“Blockchains” sind den meisten Lesern durch die Berichterstattung rund um die Kryptowährung Bitcoin bereits ein Begriff. Allerdings sind Blockchains nicht so neu oder hoch-innovativ, wie gern suggeriert wird, sondern schon eher länger bekannte Mechanismen, die lediglich “neu angestrichen” wurden.

1.1. Geschichte: Das ewige Logfile

Blockchains sind Ketten aus Datenblöcken. Diese Datenblöcke sind jeweils nach einem bestimmten Format aufgebaut, welches die verwendete Blockchain Technologie definiert. Die Verkettung funktioniert so, dass über jeden Datenblock eine kryptographische Prüfsumme (“Hash”, https://de.wikipedia.org/wiki/Hashfunktion) gebildet wird. Der Hash des Vorgängerblocks wird dabei im Datenstrom des nächsten Blocks mit eingetragen und folglich in dessen Hash mit abgedeckt.

Als Verfeinerung können die Datenblöcke dazu auch fortlaufende Blocknummern und Zeitstempel sowie eine Markierung des erstellenden Systems enthalten. Der allererste Block bekommt mangels eines Vorgängers dabei z.B. die Nummer 0 und enthält als Hash des Vorgängerblocks ebenso eine 0-Sequenz.

Druckt man diese Hashes der Blöcke täglich zu Redaktionsschluss in überregionale Tageszeitungen, die sich im Bibliotheksbestand vieler Bibliotheken befinden, so erreicht man eine Nachweismöglichkeit aller an diesem Tag stattgefundenen Transaktionen. Diese Vorgehensweise basiert auf Mathematik der 1950er Jahre und war tatsächlich wichtig für Revisionssicherheit und Nachweis der Unverändertheit (Integrität) von z.B. Geschäftsbüchern von Unternehmen.

Donald Knuth verweist hierfür z.B. auf ein Memo aus dem Jahre 1953 für die erste Hashfunktion: https://en.wikipedia.org/wiki/Hash_function#History

Mit dem Ziel, die Hashes als sog. Hash-Bäume für damalige Signaturverfahren besser organisieren zu können, erfand der Mathematiker Ralph Merkle im Jahre 1979 den nach ihm benannten “Merkle-Tree” (https://de.wikipedia.org/wiki/Hash-Baum).

Ewiges Logfile nannte man in den 1990ern dann eine Weiterentwicklung dieses Vorgehens mit den neu entstandenen Möglichkeiten des Internets. Im Unterschied zu den Tageszeitungen zog man für die Archivierung der Hashes damals IT-Dienstleister bzw. deren Verbände (z.B. eco e.V.) heran. Die gespeicherten Hashes konnten nun 24x7 eingesehen und für Prüfungen herangezogen werden. Auch das Duplizieren des Datenbestandes war durch simples regelmäßiges kopieren bzw. “herunter laden” möglich geworden. Das ewige Logfile wurde damals von Kollegen realisiert und hier dokumentiert http://altlasten.lutz.donnerhacke.de/mitarb/lutz/logfile/idee.html.

Mit Bitcoin wurde großflächig die automatische Verteilung dieses ewigen Logfiles auf alle teilnehmenden System auf Basis einer verteilten Hashtabelle (https://de.wikipedia.org/wiki/Verteilte_Hashtabelle) eingeführt. Auch dieses Verfahren ist der geneigten IT- Öffentlichkeit spätestens seit dem 06.09.2000 mit eDonkey2000 bekannt. Die Implementierung der verteilten Hashtabelle ist es auch, die den Konsensmechanismus vorgibt. Ein Konsens wird benötigt, wenn Teile des sog. “Overlay” Netzwerks zwischendurch nicht in Kontakt standen, z.B. durch einen Net-Split, also einer zwischenzeitlichen Nicht-Erreichbarkeit einzelner Teilnehmer oder Teilnehmergruppen untereinander. Sobald sich die Teilnetze als Ganzes wieder sehen, muss nach klar definierten Regeln entschieden werden, wessen inzwischen ermittelter Zustand über die Anderen gewinnt.

Zusätzlich wurden für den Einsatz als sogenannte “Kryptowährung” Mechanismen implementiert, die es erschwerten, allzu einfach neue Blöcke berechnen zu können. Da man eine Motivation brauchte, damit Leute eine verteilte Infrastruktur aufbauen, begann man, Beträge der Kryptowährung für den Gewinner des Rennens unter den schnellsten Computern, die den nächsten Block ermitteln, zu vergeben. Das sogenannte “Mining” wurde zu einer Haupteinnahmequelle des dadurch nahezu an ein “Ponzi Scheme” bzw. Schneeballsystem erinnernden Bitcoin Hypes. Je früher ein “Miner” dabei ist, desto höher sind zunächst die als Motivation ausgeschütteten Belohnungen je erzeugtem Block in der Blockchain. Und desto länger kann er an den Transaktionsgebühren verdienen. Gleichzeitig steigt der Schwierigkeitsgrad des Minings kontinuierlich an, um eine Inflation der Währung zu beschränken. Das ist so gewollt, gibt aber früheren Minern systembedingt einen enormen Vorteil. (https://www.capital.de/geld-versicherungen/bitcoin-ein-gefaehrliches-schneeballsystem) Wie leicht oder schwer neue Blöcke berechnet und hinzugefügt werden konnten, funktioniert z.B. bei Bitcoin und Ethereum über das “Proof-of-Work” Verfahren, einem Mechanismus aus den 1990er Jahren, der ursprünglich von eMail Servern zur Spam-Bekämpfung verwendet wurde: https://de.wikipedia.org/wiki/Hashcash

Die “Blockchain” war geboren: als ewiges Logfile auf verteilter Hashtabelle.

Weiterentwicklungen, ausgehend von Blockchains, werden häufig unter dem Begriff Distributed Ledger Technologies zusammengefasst, die jedoch nicht notwendiger Weise Datenblöcke mit Proof-of-Work und Transaktionsdaten berechnen und verteilen, sondern je nach Ausprägung nur Schlüssel der Teilnehmer und davon abgeleitete IDs sowie Meta-Daten dazu enthalten und unterschiedliche andere Konzepte wie z.B. Proof-of-Stake, Proof-of-Authority (“Certificate Authority auf Blockchain”) oder Abwandlungen davon verwenden.

1.2. Motivation

In seiner ganz ursprünglichen Form dienten ewige Logfiles als Beweismittel für die korrekte Buchführung, z.B. bei Wettbüros, Notaren, börsennotierten Unternehmen, Revisionssicherheit von Banken, Dokumentenarchiven, Inventuren, etc. pp. Sie wurden überall da eingesetzt, wo ein kontinuierlicher Strom von Informationen zu erfassen und zu vermerken ist und ggf. später für eine mehr oder minder breite Öffentlichkeit beweisbar, manipulationssicher und verfügbar (Wiederbeschaffbarkeit nach Bränden und Naturkatastrophen) vorgehalten werden musste. Im Zweifel konnte dies auch einer Nachweispflicht bei späteren Gerichtsverfahren dienen, ob eine Information korrekt erfasst worden ist oder nicht.

Mit der Weiterentwicklung in Richtung Kryptowährungen und Payment-Verfahren gewannen immer mehr Bestandteile der Kassenbuchführung an Bedeutung. Daher auch der Begriff “Ledger” für das Hauptbuch. Unter anderem wurde es nun wichtig, Zahlungsströme einerseits so anonym und sicher wie möglich, andererseits aber auch beweiskräftig abzubilden, um späteren Streit über nicht korrekt bezahlte Aufträge zu vermeiden. Hinzu kam auch die Möglichkeit “Unterkonten”, d.h. von der Hauptadresse nach festem Muster abgeleitete Unteradressen zu verwenden, in denen z.B. das “Wechselgeld” (Restbestand des vorher für die Transaktion verwendeten Kontos) zu speichern.

Weil mit den eingangs erwähnten Hash-Funktionen auch das Risiko einer Hash-Kollision einhergeht und man für eine korrekte Buchführung “absolut” sicher über die verwalteten Werte sein muss, wurden auch modifizierte Signaturverfahren für das Bestätigen und somit für das Auslösen einer Transaktion eingeführt. Während ein klassisches Signaturverfahren über einen Eintrag in einem Datenblock einer Blockchain selbst einen Hash von der zu unterschreibenden Information bildet und mit einem Public-Key Crypto-System die Signatur erzeugt - und somit die Information an sich nicht enthalten ist - geht man hier einen anderen Weg. Der Hash birgt das Risiko der Kollision, wenn man als Eingangswert nur relativ kurze und einfache reelle Zahlwerte wie z.B. 156,73 als FIAT Geldbetrag oder 0,00024 in Bruchteilen einer Kryptowährung hat. Sog. Zero-Knowledge-Proof (zkp) Verfahren wie z.B. in Zcash https://z.cash/technology/zksnarks/ verheiraten dabei ein Public-Key Crypto-System mit Ideen aus dem sehr jungen Gebiet der homomorphen Verschlüsselung (https://de.wikipedia.org/wiki/Homomorphe_Verschl%C3%BCsselung), um einerseits den verwendeten Schlüssel geheim zu halten, aber insbesondere die damit bestätige Information nicht offen zu legen und der Gegenseite gleichzeitig zu erlauben, eine behauptete Information gegen die Signatur prüfen zu können. Andere Vertreter sind z.B. CL-Signaturen https://de.wikipedia.org/wiki/Camenisch-Lysyanskaya-Signaturverfahren, die relativ klassisch bekannte Eigenschaften des RSA Verfahrens für ähnliche Sicherheitsaussagen nutzen und z.B. auch bei Direct Anonymous Attestation zum Einsatz kommen.

Die Datenblöcke der Blockchains bestehen zum überwiegenden Teil aus eben jenen Signaturen der Transaktionen. Eine Transaktion wird dann gültig, wenn sie es in den nächsten Block eines Miners geschafft hat und damit Teil der Blockchain geworden ist.

2. Self-Sovereign-Identities

Bei der SSI steht historisch betrachtet als Quellautorität der einzelne Mensch im Mittelpunkt. Was erstmal schön klingt, funktioniert leider so nicht immer und überall.

Es handelt sich nicht um ganz konkrete mathematische Algorithmen oder eine einheitliche, klar definierte technische Spezifikation. SSIs basieren im Ursprung auf dem gesellschaftspolitischen Gedanken der Quellautorität.

Die Zielstellung von SSIs ist es, ein ID-System bzw. zueinander interoperable ID-Systeme zu schaffen, welche die singuläre Kontrolle einer übergeordneten Macht verhindern. D.h., kein Konzern und kein Staat soll eine ID unbrauchbar machen können. Gleichzeitig müssen aber auch alle Teilnehmer dem Verfahren vertrauen können. Und schlussendlich braucht es Dinge wie Revokation und Sperrlisten, um eine ID auf Nutzerwunsch hin zu invalidieren. Nur rudimentär betrachtet werden dabei Konzepte wie die Datensparsamkeit und sog. Sektortrennung in Bezug auf Datenspuren, die Nutzer mit Ihrer ID weltweit hinterlassen.

SSIs waren seit 2012 in der Diskussion und laut den Urhebern wurden Wikipedia Artikel zum Thema damals noch gelöscht. Ab 2017 gewann das Konzept aber an Aufmerksamkeit. Offenbar war auch ein gewisser Zeitgeist am Aufschwung beteiligt.

2.1. Geschichte und Herkunft der Idee

Als Grundlage der Self-Sovereign-Identities findet man eine Loseblatt-Sammlung von Ideen, Blog Posts und Artikeln, die das Konzept seit Anfang 2012 vom US republikanischen Libertarismus geprägten Grundgedanken ausgehend schrittweise entwickeln. Besonders sticht dabei Devon Loffreto auf der Website moxytongue.com (“charakterstarke Zunge”) hervor, auf den sich Blockchain-Advokat Christopher Allen auf lifewithalacrity.com bezieht. Dabei wird vielfach eine “identity crisis” seit Anfang der 2010er Jahre angeführt. Im Wesentlichen lässt sich dies darauf zurückführen, dass die USA kein ID-System haben und lediglich über die gern gefälschten Führerscheinkarten ohne jedwede Online-Funktion als Alltags-ID verfügen. Unter Kenntnis der Sozialversicherungsnummer und dem Namen einer Zielperson ist zudem Identitätsdiebstahl denkbar einfach.

Auffällig aus europäischer Sicht ist der ultra-libertäre “weak state” Ansatz, so wie er das US-typische Verständnis der Demokratie widerspiegelt. Denn nicht der Staat gibt hierbei dem Bürger seine Identität, sondern der Bürger gibt dem Staat seine Identität. Für Fragen der richtigen Zuordnung von Versorgungsleistungen zu Individuen scheint dies keinen gangbaren Weg darzustellen. Dafür bräuchte es Ergänzungen, die die SSI wiederum ad absurdum führen würden. Denn dann muss der Staat eine Art Verrechnungskonto führen, das eng mit den Identitäten der Beitragszahler und Leistungsempfänger verknüpft ist. Auch im globalen Reiseverkehr ist eine SSI nicht ausreichend, da die Länder sich zwar wechselseitig vertrauen können, aber nicht mit bis zu mehreren Milliarden Individuen zumeist fremder Hoheitsgebiete umgehen können, ohne einen Vertrauensanker zu haben. Dafür braucht es auch hier eine “Source Authority” und das ist auch heute schon das jeweilige Herkunftsland, beste Beispiele hierfür sind der Reisepass und der internationale Führerschein.

Latent problematisch wird der Ansatz, wenn man den starken USA-zentrischen Gedankengang in 2021 weiterverfolgt mit einer im Wesentlichen auf “America first!” ausgelegten Interpretation bis hin zu einer vom Nationalismus angehauchten suggerierten Überlegenheit als “… differentiating THE UNITED STATES OF AMERICA from every other Nation on Earth”. Generell treten in der Diskussion häufig Formulierungen in der Art “we, the people of the United States of America” auf mit Bezügen zum fünften Verfassungszusatz der USA von 1791. Dabei wird immer die “source authority” (also die Quellenautorität) im Sinne einer “human centric” Identität und der Autorität des Bürgers ÜBER dem Staat betont. Zumindest in Deutschland würde man derartige Forderungen wohl relativ schnell in das Lager der “Reichsbürger” einsortieren. Die Ideen fußen jedoch zumindest in Teilen auf verwandten Konstrukten.

Felix von Leitner (fefe) hat bereits in seinem Vortrag zum Sinn und Unsinn von Blockchains (https://ptrace.fefe.de/Blockchain/#0) den Zusammenhang mit den Crypto-Libertären “Cypherpunks” dargestellt.

Christopher Allen greift das Konzept in 2016 auf und formuliert basierend auf der Blockchain als Technologiebasis erste Prinzipien für eine Self-Sovereign Identity. Er versucht diese mit anderen Technologien wie OIDC, FIDO, etc. in Kontext zu setzen. Ab dem 22. “Internet Identity Workshop” (IIW, https://internetidentityworkshop.com/) im Computer History Museum in Mountain-View, Kalifornien, wird das Konzept einer breiteren technisch fokussierten Öffentlichkeit präsentiert und findet mit dem Freiheitsgedanken weitere Anhänger. Es bleibt zu diesem Zeitpunkt mehr ein politisches Manifest als eine technische Spezifikation.

Leider hatte er bei der Einordnung nicht die seit spätestens 2005 laufenden Entwicklungen der UN mit der ICAO und dem Doc 9303 für Reisepässe auf dem Schirm. Es fehlen z.B. Extended Access Control, die Existenz von Country Signer CAs (CSCA), um elektronisches cross-country Vertrauen zu etablieren und die ICAO Master-List als etablierter Brückenkopf der UN zwischen ca. 200 Ländern. Auch findet die europäische Entwicklung des eIDAS Token keinerlei Berücksichtigung. Denn viele seiner formulierten Prinzipien sind hier schon enthalten.

Es entsteht der Eindruck, dass auch der IIW ein USA-zentrisches Event ist, ohne annähernden Blick in die anderen großen Volkswirtschaften rund um den Globus.

Der Internet Identity Workshop hatte ursprünglich tatsächlich “Internet”-Identitäten im Fokus, d.h. Logins in sozialen Netzen, Foren, Online Shops, Spieleplattformen, mobile App stores, usw. Häufig fällt in diesem Kontext der Begriff “GAFAM(I)” für Google, Apple, Facebook, Amazon, Microsoft, IBM. Dem Self-Sovereign Identity Konzept steht jedwede übergeordnete Macht entgegen, so auch Konzerne die nach Belieben (“terms of service violation”) Identitäten sperren und effektiv vernichten können (siehe z.B. die Sperrung von Trumps Twitter Account). Die Nutzer sind dann aus allen Teilen der Online-Welt ausgesperrt, in denen Sie z.B. eine Microsoft Passport Identität verwendet haben. Ähnliches gilt für Google und Facebook Accounts. Aus diesem Blickwinkel kann eine selbst-souveräne Identität rein für den Online-Raum einen Sinn ergeben. Dabei muss diese nicht - wie von Christopher Allen postuliert - zwangsläufig von einer Blockchain abhängig sein. In der Zwischenzeit sind jedoch, motiviert durch den Bitcoin-Hype, reihenweise Förderprojekte aus dem Boden geschossen und Investoren kaufen gefühlt alles, wo “Blockchain” dran steht und diverse Ministerien fördern alles, was Blockchain enthält mit Forschungsgeldern in Millionenhöhe. Sogar Blockchain Eistee hat seinen Börsenkurs damit um fast 500% angehoben.

Dabei liefert nicht die Blockchain die ID, sondern diese wird dort nur dezentral verwaltet. Das Versprechen der Blockchain ist eine Libertär motivierte Ideologie, deren Urheber versuchen über die Brücke einer technischen Lösung für das Problem der Identität in das gesellschaftliche Gefüge durchzuschlagen.

Insofern verwundert es nicht, dass beim ID2020 Summit der United Nations auch hier der Hype übersprang und im Resumee leichte Fantasien entstanden, dass man nun den ganzen Globus mit Self-Sovereign Identities beglücken könne. Angefangen bei Flüchtlingen, über alle Länder im Einflussbereich und kultureller Nachbarschaft der USA bis hin zu extrem offensivem Missionieren bei allen EU-Staaten, der weltweiten Wirtschaft, Lobby-Gruppen und Verbänden. So beobachten wir nun Bestrebungen der Länder, Self-Sovereign Identities auf Blockchain-Basis als Staat heraus zu geben. Dies widerspricht direkt der ursprünglichen Motivation der SSI und sollte überhaupt nicht erst so genannt werden.

Evernym, Inc. hat beim W3C den Versuch unternommen, einen “Decentralized IDentifier” (DID) Standard zu entwickeln. Aktuell steht das gesamte Vorhaben von allen großen Parteien in der Kritik, da der Standard klaffende Lücken aufweist, elementare Datenschutzkonzepte wie die Identifizierung der “Gegenseite” (“relying party check”, also wer will meine Identität eigentlich haben?) fehlen und sich allein in der Entwurfsphase mit Stand vom 22.10.2021 insgesamt sagenhafte 114 zueinander inkompatible Substandards heraus gebildet haben. https://w3c.github.io/did-spec-registries/

Die Tatsache, dass die SSI Community diesen elementaren ersten Schritt zu einer datenschutzfreundlichen ID Lösung als “won’t fix” eingestuft hat, kann man öffentlich einsehen: https://github.com/decentralized-identity/didcomm-messaging/issues/41

Man kann es auch anders formulieren: Da braucht man dann auch keinen Standard mehr.

2.2. Prinzipien

Je nachdem, wessen Marketingwebseite man aufruft, bekommt man mal 6, mal 10, mal 12 oder andere Anzahlen von Prinzipien der SSI zur Kenntnis. Dabei hat auch jeder seine etwas eigene Ansicht und am Ende ist es stark von der Definition abhängig, was im Detail genau präsentiert wird. Ich möchte hier die ursprüngliche Definition von Christopher Allen aufgreifen.

  1. Existenz — Nutzer sollen eine unabhängige “Ich”-erkennende und somit selbstbewusste Identität haben. - Das ist soweit selbstverständlich und sinnstiftend.
  2. Kontrolle — Nutzer sollen die Kontrolle über Ihre Identität selbstbestimmt ausüben können. Prominent hervorgehoben werden sichere, gut verstandene Algorithmen. - Auch das ist sinnvoll.
  3. Zugriff — Nutzer sollen den Zugriff auf Ihre eigenen Daten haben. Keine versteckten Daten, keine “Kontrolleure”, Proxies, Intermediäre.- Beschrieben wird hier eine Art “Selbstauskunft” wie bei der deutschen eID.
  4. Transparenz — ID-Systeme und die Algorithmen sollen frei, offen, möglichst unabhängig von einer konkreten Architektur und transparent dokumentiert sein. Dazu verwaltet und aktuell. - Das trifft den Kern der Krypto-Agilität im eIDAS Token / eID.
  5. Persistenz — Identitäten sollen möglichst lange (“für immer”) leben, mindestens doch so lange wie die Nutzerin dies wünscht. Dabei soll die Identität auch mit Krypto-Agilität und dem Recht auf Vergessen vereinbar sein. - Auch dies eine sehr gute Basis und entspricht dem eIDAS Token.
  6. Portabilität — Identitäten sollen nicht von einer einzelnen dritten Partei abhängig sein, Regimes können sich ändern, Nutzer ziehen in andere Rechtsgebiete (z.B. EU versus nicht-EU Staaten). - Absolut tolle Sache, dafür gibt es die UN ICAO 9303 Master-List zwischen allen UN-Ländern und cross-country Vertrauen, damit so ein Umzug und die gegenseitige Anerkennung der Identität möglich ist, solange die Nutzerin dies wünscht und dies sinnvoll erscheint.
  7. Interoperabilität — Identitäten sollen so umfangreich nutzbar sein wie möglich. - Auch das ist ganz wichtig. Ich betone seit Jahren, dass wir nicht nur eine EU-weite sondern eher ein global gedachte Lösung brauchen. Glücklicher Weise konnten wir vor 16 Jahren mit dem Experiment elektronischer Reisepass gute Erfahrungen sammeln, die sich mit dem EU digital certificate (Covid Impfpass) bestätigen ließen. Rund 200 Länder verstehen sich. Und der eIDAS Token setzt wie die ISO18013–5 Führerscheine auf dieselbe Basis auf.
  8. Zustimmung — Nutzer müssen der Verwendung Ihrer Identität vorher zustimmen. Und es soll “gut verstanden” sein, dafür müssen Nutzer wissen wem ggü. sie ihre Identität offen legen. - Leider wurde das im W3C DID Standard ganz bewusst ignoriert. UN ICAO 9303 und der eIDAS Token kennen dafür die sog. Terminal Authentication, in deren Rahmen auch von Menschen lesbare, authentifizierte Klartext Daten übermittelt werden, die dem Nutzer eindeutig und zuverlässig mitteilen, mit wem er spricht.
  9. Minimalisierung — gemeint ist die Datensparsamkeit und die gezielte Offenlegung einzelner Attribute (Vorname, Nachname aber kein Geburtsname und z.B. nur Altersverifikation aber kein Geburtsdatum). - Auch das ist in BSI TR-03110 / ANSSI eIDAS Token seit 12 Jahren definierter Standard.
  10. Schutz — Die Rechte der Nutzer sollen geschützt werden. Bei Konflikten sollen z.B. Selbstbestimmungsrechte und Menschenrechte über den Zwecken des ID-Systems stehen. Weder Zensur noch Ausübung von Macht darf Nutzer in die Enge treiben. ID-Systeme sollen dezentral organisiert sein. - Er spricht mir aus der Seele, ja so wurde eIDAS Token auch gebaut.

2.3. Zero-Knowledge-Proof

Da in Diskussionen häufig die weiter oben erwähnten ZK/zkp Verfahren als besonders datenschutzfreundlich und als Vorteil ggü. bestehenden eID Verfahren angepriesen werden, möchte ich in einer kurzen Überlegung dediziert darauf eingehen:

Wenn ich beweisen will, dass ich “Christian Kahlo” bin und dabei aber anonym bleiben möchte, dann ist etwas prinzipiell falsch. Ähnliches gilt für meine Adresse. Es ergibt keinen Sinn die eigene Identität beweisen und gleichzeitig anonym bleiben zu wollen. Anonymität ist die Abwesenheit von Identität. 1 != 0. Anders verhielte es sich, wenn ich die Mitgliedschaft als Bürger im Schengen-Raum beweisen, meine konkrete Nationalität aber geheim halten möchte.

Ein weiteres Beispiel ist das Geburtsdatum. An der Stelle sind aber ZK Verfahren nur wichtig, um SSI auf Blockchain datenschutzfreundlich zu gestalten. Ein eIDAS Token braucht an der Stelle kein ZK Proof dafür, um das Problem zu lösen. Homomorphe Verschlüsselung ist z.Z. auch noch mehr pre-alpha Theorie als aktiv gelebte und gute durchdrungene Praxis.

Weiterhin verstößt aktuell so gut wie jedes ZK Verfahren gegen die SSI-Prinzipien Nr. 2, da der Aspekt der “sicheren und gut verstanden” Algorithmen nicht erfüllt ist, sowie Nr. 4, da einige Verfahren abhängig sind von der konkreten ID-System Architektur und Krypto-Agilität hier noch nicht berücksichtigt ist.

Es ist nachvollziehbar, dass die älteren Zertifikats-basierten Lösungen, wie sie aktuell z.B. noch in Österreich, Belgien, Estland, Finnland und Deutschland unter bestimmten Bedingungen (“Signaturkarte”) zum Einsatz kommen dem zuwiderlaufen, da das Zertifikat im Zweifel immer alle Angaben über den ID-Inhaber enthält und diese bei Übermittlung unkontrolliert preisgegeben werden. Daher sollten Zertifikats-basierte Lösungen auch abgeschafft oder zumindest voll-pseudonymisiert werden, d.h. ohne vollständige Personendaten im Klartext. Oder wie in Tschechien mit der “mojeID” vorgelebt durch FIDO(2) ersetzt werden. Der eIDAS Token wäre natürlich auch eine gute Alternative.

2.4. Anwendungsfälle

SSIs sind eine tolle Sache. Das Prinzip sollten wir unbedingt beherzigen und verteidigen. Und das machen wir zumindest in Deutschland schon seit 2009.

SSIs auf Blockchain mögen eine Lösung im Konflikt mit GAFAMI sein. Dann allerdings auch alleinig beschränkt auf das Internet und nicht-regulierte (Banken, Versicherer, Anwälte, Steuerberater, Notare, …) sowie nicht-staatliche (z.B. eGovernment, gesetzliche Krankenversicherungen, Kommune, Land, Rente, Arbeitsamt, …) Anwendungsfälle. Übrig bleiben damit Anwendungsfälle im privatwirtschaftlichen Kontext, dann aber auch ohne Vermischung mit einer hoheitlichen Identität. D.h. wenn es völlig ausreichend ist, als “Mickey Mouse 123” bekannt zu sein und wenn ich das bleiben möchte, dann ist SSI machbar. Sobald jemand sagt “Ich will wissen ob und DASS Du Christian Kahlo bist!” ist SSI aus dem Rennen. Denn ab diesem Moment muss ich die Source Authority auf das Land umdefinieren, in dem ich lebe und gemeldet bin. Dem SSI Ansatz folgend könnte ich sonst auch behaupten, “Angela Merkel” zu sein und wir erleben das gängige und leider sehr weit verbreitete Identitätsdiebstahl-Szenario der USA.

Gern wird hier das Web-of-Trust (WoT) als Alternative angepriesen, z.B. auf Basis von PGP. (https://de.wikipedia.org/wiki/Web_of_Trust). Tatsächlich steckt ein Teil der Web-of-Trust Bewegung auch hinter SSI. Allerdings ist das WoT in der Vergangenheit aus strukturellen Gründen gescheitert, da nicht sichergestellt werden kann, dass alle Teilnehmer tatsächlich regelkonform die korrekte Identität des Gegenübers prüfen. Bei Papierdokumenten wäre dazu auch eine aktuelle Dokumentenprüfungsausbildung eine dringende Grundvoraussetzung.

Bei den einheitlichen Regeln und wie man diese nachvollziehbar vermerkt und hinterher eine Vertrauenskette aufbauen kann, so dass nicht evtl. auch eine größere Gruppe gemogelt hat, fängt es leider an.

Bei der Durchsuchung der Apothekenräume in einem Betrugsfall zum digitalen Impfpass wurden auch Kryptowährungen sichergestellt. Das Modell der Ausstellung des digitalen Covid Zertifikats auf Basis der Prüfung von Papierunterlagen ist ein gutes Beispiel für ein Web-of-Trust und seine Schwächen.

Die CACert Organisation bemüht sich, dieses Konzept zu verbessern und zu strukturieren und z.B. auch Online Lehrgänge und Prüfungen zum Thema sowie eine Schiedsstelle zur Verfügung zu stellen.

Lösungen wie der eIDAS Token / die eID sollten unter dem Aspekt Ihrer SSI-Erfüllung in den Vordergrund gehoben werden. Zumal es hier mit dem ICAO Doc 9303 ein global standardisiertes Verfahren unter den UN gibt, das bereits ca. 200 Ländern den Anschluss ermöglicht hat. Die Infrastruktur könnte den Geist der SSI Prinzipien aufnehmen und ggf. dahin weiterentwickelt werden. Blockchain-basierte Lösungen und Forderungen aus dem politischen Manifest sind in der Mehrzahl der Länder, insbesondere derer mit mindestens sozialer Marktwirtschaft, ganz einfach nicht realistisch umsetzbar. Man kann schon SSI einführen — aber entweder ist es dann keine SSI oder obsolete-by-design.

3. Die ID als eID im nationalen / hoheitlichen Kontext

Gerade in den EU Ländern gibt es eine Jahrzehnte lange Historie von ID Systemen, in einigen Fällen auch eID, wie seit 1999 die Sähköinen Henkilökortti in Finnland (https://en.wikipedia.org/wiki/Finnish_identity_card). Eine gute Übersicht zur Gesamtlage liefert der Wikipedia Artikel zu den nationalen ID Karten im europäischen Wirtschaftsraum (https://en.wikipedia.org/wiki/National_identity_cards_in_the_European_Economic_Area). Besonders hervorzuheben sind hierbei auch die gemeinsamen Standardisierungsbemühungen in der EU seit 2006 und 2019 jeweils unter Berücksichtigung des technischen Fortschritts, z.B. flächendeckende Verbreitung von NFC / ISO14443 RFID.

3.1. Geschichte

Als der neue Ausweis 2010 in Deutschland eingeführt wurde, unterschied man zwischen dem bereits existierenden “französischen Modell” und dem “deutschen Modell”. Bei dem französischen Modell waren es eher berühmte Hersteller wie Gemplus/Gemalto oder Thales, die viele Länder mit entsprechenden Lösungen belieferten. Für die damalige Zeit ab Ende der 90er war das akzeptabel. Diese Lösungen waren zertifikatsbasiert und die Probleme der fehlenden “selektiven Offenlegung”, Krypto-Agilität, schlechte Wartbarkeit und Invalidierung der Identität mit Zertifikatsablauf wurden erkannt und ab 2009 im Prototypentest und 2010 mit der Einführung der eID auf Basis der europäischen eIDAS Token Norm adressiert. Das französische ANSSI macht nun seit Jahren aktiv mit und Frankreich wird ab 2022 auch den eIDAS Token einführen.

Wie unter den SSI Prinzipien bereits dargestellt, erfüllt der eIDAS Token alle Konzepte der SSI. Mit einer politischen Angleichung, europäische Länder sind keine IT-Monopolisten, auch nicht von diesen gesteuert und sie sind keine “weak states”. Daher ist es durchaus Ihre Aufgabe und Ihr gutes Recht und auch eine Pflicht, jeden Bürger auf seinen Wunsch hin mit einer Identität zu versorgen. Idealerweise mit einer die in ganz Europa funktioniert und die EU ist da nicht kleinlich, sondern spricht gern mit Nachbarstaaten, um insbesondere den individuellen Grenzverkehr der EU-Bürger und der Nachbarn (meistens Familien, Freunde, Kollegen) zu vereinfachen. Viele nicht EU-Länder auf dem geographischen Gebiet sind zumindest eingebunden und es gibt keinen “Maulkorb”, dass man nicht miteinander reden dürfte. Meiner Erfahrung nach wünschen sich z.B. Beitrittskandidaten ganz explizit Lösungen von denen Sie sich erhoffen, damit direkt eIDAS-kompatibel zu sein.

Ich denke die EU hat hier, wenn vielleicht auch unbemerkt für andere, vor vielen Jahren schon ganz viel positive Bewegung in die richtige Richtung erzeugt. Danke EU an dieser Stelle. Bitte überdenkt das mit der Blockchain.

3.2. Problem der Zertifikate

Wie oben schon erwähnt, sind Zertifikate die Steinzeitlösung für eID. Wir haben vor vielen, vielen Jahren damit mal begonnen. Wir wissen, dass Zertifikate alle Informationen des Inhabers auf einen Schlag offenlegen, Zertifikate laufen ab, sind nicht Krypto-agil, Schlüssel werden schwach (siehe Estland) und müssen zeitaufwändig und kostspielig ausgetauscht werden. Für EU Staaten kleiner als München mag das akzeptabel sein, aber einwohnerstarke Länder — gerade auch außerhalb der EU, teilen unsere Schmerzen, wenn es darum geht ein ID-System komplett wegwerfen und neu ausrollen zu müssen. Deswegen ist uns “gut abgehangene” Kryptographie auch sehr wichtig. Blockchain-Lösungen sind weder gut abgehangen, noch sind sie Krypto-agil.

Wir müssen daher von den Zertifikaten weg, aber Blockchain ist nicht die Lösung.

3.3. Anforderungen an eID seit eIDAS Token (2009)

Mit der Einführung der eID wurden grundlegende Prinzipien nicht nur technisch, sondern auch juristisch festgelegt. Wer die eID auslesen will, sollte zumindest eine Dienstbeschreibung, einen Datenverwendungsnachweis und eine Datenschutzerklärung vorweisen können.

“Datenstaubsauger” und Phisher sind nicht erwünscht. Immerhin handelt es sich um echte Personendaten realer Menschen. Das wird allzu gerne vergessen und auf den Datenschutz als “Verhinderer” von Geschäftsprozessen geschimpft. Der große SSI-Blockchain-Hype rührt auch daher, dass Leute sich DSGVO-freie Prozesse wünschen, um wieder viel einfacher mit den Daten der Nutzer arbeiten zu können.

Einfache Faustregel: Wenn das Geschäftsmodell am Datenschutz scheitert, war das Geschäftsmodell falsch. Und das Geschäftsmodell widerspricht SSI Prinzip Nr. 10. Nicht der Bürger ist das Produkt, sondern der Anbieter liefert das Produkt.

Gern werden seitdem auch Verfahren auf Basis der Signaturkarte (qualifizierte elektronische Signatur, QES) oder elektronische Gesundheitskarte (eGK) und Heilberufsausweis (HBA) verwendet, weil diese regelfrei benutzbar sind. Ein Grund mehr, auch die eGK (eine rein-deutsche Sonderlösung) neu zu denken. Und der HBA ist ein Berufsausweis, eine andere Baustelle aber nicht weniger überdenkenswert seitdem wir “modular enhanced role authentication” (mERA) durch unsere EU-Nachbarn kennen. mERA erlaubt die dynamische Erweiterung des ID-Systems um zusätzliche Attribute durch sog. “Attribut Provider”. Z.B. könnte eine Krankenkasse die Krankenversicherungsnummer als Attribut in die Smart eID schreiben und diese dann vom Versicherten später beim Arzt vorgelegt werden. Ähnliches gilt auch für die Führerscheinnummer und Informationen über Fahrzeugklassen und Ablaufdaten. Oder bei regulierten Berufen wie den Ärzten könnte die Rolle “Arzt für Allgemeinmedizin” als Attribut hinzugefügt werden.

3.4. Weiterentwicklung Smart eID

Die “Smart eID” und deren Vorbereitung habe ich seit vielen Jahren mit begleitet und beeinflusst. Sie ist nicht nur ein “Ausweis auf Galaxy S20”, sondern auch die “eID auf bring-your-own-device”. Denn der Smart eID ist es egal, ob es das Dienst-S20 oder das private S20 ist. Technisch funktionieren sogar noch mehr Geräte, wie z.B. ab Samsung S7 bis S22, die Galaxy Watch S4 (trage ich selbst mit Ausweis) und Wearables. Wichtig ist hierbei die Unabhängigkeit von einem konkreten Gerät. Der Gesetzgeber hat im Dialog mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) entschieden “Du darfst viele Smart eIDs haben” und Du kannst jede einzeln sperren. Und verlierst Du mal das Original, kannst Du mit Deinen Smart eIDs weiter arbeiten. Und die Smart eID ist updatefähig. Kommen neue Funktionen hinzu, kann man sie einfach vom Sofa aus neu installieren. In der BSI TR 03159–2 “Mobile Identities” befindet sich auch schon die Idee einer eID in Kombination mit FIDO: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03159/tr-03159.html

Der Hintergrund ist, dass FIDO in seiner technischen Infrastruktur vollständig und inhärent self-sovereign angelegt ist. Wir haben uns überlegt, wie man Personendaten sinnstiftend in FIDO einbringt.

Ich habe übrigens einen Ring mit NXP Chip am rechten Ringfinger, der genau diese Prinzipien mit meinen Personendaten abbildet. :-) Und darüber hinaus sogar Payment enthält.

3.5. Einklang mit SSI-Prinzipien

Die ID nach eIDAS kann sowohl auf dem “Level of Authentication” (LoA) substanziell als auch hoch genutzt werden. Basis ist immer die eigentliche Karte, die man vom Bürgeramt erhält. Damit kann man dann seine eigenen abgeleiteten Identitäten nach dem bring-your-own-device Konzept ablegen. Sicher erfordert das an einigen Stellen noch viel Arbeit mit den Hardware Herstellern, aber die Erkenntnis setzt ein und es geht kontinuierlich vorwärts. Auch wird das Konzept des eIDAS Token immer besser von den anderen Engineers verstanden und begrüßt. Im Rahmen dessen bin ich mir sehr sicher, dass wir eine zukunftsfähige und bessere Lösung als “SSI-on-Blockchain” haben werden. Einen Konflikt mit SSI gab es nie. Man könnte fast denken, SSI sei von den Design-Prinzipien des eIDAS Tokens inspiriert und mit einem US-Politmanifest unterlegt worden, um dort Unterstützer zu gewinnen.

4. Fazit

Im Ursprung sollte die Aufgabe der SSI sein, Identitäten für Jedermann für “so gut wie alle” Geschäftsprozesse bereitzustellen. Weltweit eindeutig, möglichst langlebig und vor allem interoperabel. Das erfordert eine saubere Standardisierung und sorgfältige Berücksichtigung von Datenschutzaspekten und Krypto-Agilität. Denn je langlebiger und großflächiger ein System angelegt wird, desto intensiver muss man Technologiefolgenabschätzungen durchführen und versuchen, soweit es geht in die Zukunft zu schauen, welche Probleme dabei auf lange Sicht ggf. entstehen können.

Das Anlegen einer SSI durch den Bürger ist kein kontinuierlicher Strom von Informationen wie unter 1.2. dargestellt und ist somit per se kein Anwendungsfall für eine Blockchain oder eine distributed ledger Technologie. Der Vorgang ist pro Gerät in aller Regel einmalig und eine langlebige ID sollte auch offline, in Abwesenheit von Blockchains, funktionieren können. Bei einem großflächigeren Netz- und / oder Stromausfall wie z.B. zur Flutkatastrophe 2021 oder bei überregionalen Stromausfällen ist eine Blockchain ID weitgehend nutzlos. Eine ICAO MasterList oder zumindest die hoheitliche Country-Signer CA der Region, in der ich gerade bin, wird man hingegen immer noch mit einem Inselsystem verwenden können. Eine Verwendung z.B. im KRITIS Kontext (https://de.wikipedia.org/wiki/Kritische_Infrastrukturen) würde sich also auch verbieten und ist dem Vernehmen von Projektpartnern nach folgerichtig auch nicht vorgesehen.

Es wäre jetzt die Aufgabe erfahrener Normierungsgremien, erst einmal eine konsequente und technisch hinterlegte Abbildung von SSIs zu schaffen. Dann kann man darauf aufsetzen, um konkrete Implementierungen zu entwickeln. Das Konzept der Kassenbuchführung bzw. des Hauptbuches (“Ledger”) ist vermutlich auch der Grund, warum die Fintech und Banking-Szene von Blockchain IDs so begeistert ist. Ein Kassenhauptbuch über alle Bürger kommt aber auch einem Zensus gleich. Gerade IBM mit seinem Engagement in Hyperledger weckt dabei böse Erinnerungen an den ersten Einsatz großer und sehr umfassender Datenstrukturen in der Anfangszeit der IT.

SSIs adressieren zunächst US-amerikanische Probleme (“identity crisis”) mit typisch US-amerikanischen Lösungsstrategien. Die tatsächliche und vor allem sinnstiftende Anwendbarkeit in anderen Ländern ist mindestens fraglich. Spätestens wenn außerhalb der USA mit “Proof-of-Authority” argumentiert wird, sind übliche Public-Key-Infrastrukturen schlanker, schneller und eindeutiger: klare Struktur, keine Konsensfindung nötig, keine übergeordneten verteilten Datensätze aller Teilnehmer in Blockchains / DLTs.

4.1. Grundsätzliche kryptographische Probleme

Zumindest das “Ökosystem digitale Identitäten” in Deutschland verletzt mit Anlauf eine Reihe der SSI Prinzipien und dürfte sich daher nicht einmal “SSI” nennen. Dabei ist unerheblich, welche (ID) Wallet zum Einsatz kommt oder welches der Förderprojekte die Infrastruktur stellt. Durch den Konsens auf ein defektes Setup und fehlende Korrektur der defekten Standards werden die meisten SSI Prinzipien missachtet. Der Versuch, mit dem Ausweis eine “Basis-ID” zu erzeugen, indem ein signierter Datensatz (quasi ein “Zertifikat” oder ID-Token) von der zentralen Autorität generiert wird und ihn dann in einen distributed ledger zu schreiben, läuft der Grundidee der SSI ebenso zu wieder.

Dazu kommt, dass Deutschland wie die meisten EU Länder kein “weak state” ist und tatsächlich von der Geburt an für jeden Bürger beginnt, im Laufe des Lebens adäquate Identitäten auszustellen (Geburtsurkunde, (Kinder-)Ausweis und (Kinder-)Reisepass, Sterbeurkunde). Die meisten EU Staaten handhaben dies ebenso. Da die EU Länder in aller Regel eine Sozialversorgung anstreben, werden überall Gesundheitsversorgung, Renten, Grundsicherung und Arbeitslosengelder angeboten. Zwar in unterschiedlicher Höhe, aber die Konzepte existieren. Damit diese Verfahren in einem Staatenkonstrukt funktionieren, dass je nach rechenweise 1,5–2,0 so groß ist wie die USA und Anrainerstaaten und Beitrittskanditen in Ihrer Entwicklung begleitet, ist die überall gut eingeübte staatliche Bestätigung des Wunsches der Eltern “unser Kind heißt Klaus Meier” und damit der ersten Identität des neuen EU Bürgers der sinnstiftende und bis dato richtige Weg.

Das bedeutet, dass sowohl zkp Signaturen weder Vorteile besitzen noch sinnvoll eingesetzt werden können. Proprietäre Hash-Verfahren wie z.B. bei IOTA befriedigen evtl. die Neugier der Entwickler, lösen aber nicht die Probleme im Umgang mit einer halben Milliarde Menschen. US-amerikanische Traditionen nach dem Vorbild “Wir bringen die Demokratie in die ganze Welt” sollte man mit Vorsicht begegnen, wenn zentrale Firmensitze und Rechenzentren unweit der US Nachrichtendienste stehen. Denn eine langlebige (SSI Prinzip Nr. 5) globale Blockchain ID birgt das Risiko, jedem Erdenbürger eine unique ID zu zuweisen, die jeder Nachrichtendienst super in Datenbanken und Diagrammen zur eigenen Informationsbefriedigung zusammenführen kann, selbst wenn diese ID pseudonym ist. Es entstehen also langfristig nachvollziehbare Datenspuren eines jeden Nutzers. 5-Eyes zeigt uns, dass Sie die Resultate nicht mit uns teilen wollen. Eine Disparität steht im Raum.

Alle bisher postulierten Verfahren in Deutschland erzwingen eine reine Software Implementierung. Das ist insofern nachteilig, da Secure Elements nicht verwendet werden können, somit auch keine Wearables und auch die Hardware Keystores der großen mobil-Plattformen nicht die notwendigen proprietären Algorithmen anbieten. Damit bieten die Verfahren tatsächlich ALLE Optionen, auf den wohlbekannten Angriffswegen Identitäten zu stehlen. Blockchain hin oder her, die Blockchain merkt davon nichts und die Blockchain kann das auch nicht verhindern. Die Blockchain verbessert hier exakt nichts.

4.2. Sinnhaftigkeit

Lange Rede, kurzer Sinn: Eine Sinnhaftigkeit der Blockchain-SSI Bestrebungen ist nach langem Nachdenken unter Kenntnis der naturwissenschaftlichen Grundlagen, politischen Argumente, Historie und Notwendigkeiten für die Menschheit NICHT GEGEBEN.

Seit der Erfindung der Public-Key Crypto-Systeme Ende der 1970er und damit Public-Key-Infrastrukturen, (pseudonymen) Zertifikaten, Zertifikats-Hierarchien (Document Signer CAs), Key Agreements, etc. sind Blockchains für die Ausstellung einer “ID” mathematisch obsolet.

5. Updates zum Inhalt

5.1 Update 28.10.2021: Antwort des BMI zur IFG Anfrage “ID Wallet”

Die Antwort auf die IFG Anfrage an das Bundesministerium des Innern betreffend “ID Wallet” zu Prüfung und Freigabe wurde heute veröffentlicht. Darin enthalten auch die Berichte des BSI an das BMI.

Zum Autor

Christian Kahlo, CISSP, ISACA Member, Chief Security Architect

Ursprünglich aus der Welt der Kernphysik und zur Jahrtausendwende in der IT-Security gelandet. Ab 1998 auf CCC Kongressen und Camps präsent und erster Kontakt mit dem Identity Ökosystem auf der “Identrus System Deployment Conference” in Frankfurt/Main, 2001 mit “Integration of Identrus signature cards in electronic business transaction systems”. Seit Anfang 2009 Mitglied der BSI Arbeitsgruppen zu eID / eIDAS & Ausweis Infrastruktur und schreibt daher auch mit an den Technischen Richtlinien des BSI und in der Folge z.B. zusammen mit Peter Gutman auch an TLS https://mailarchive.ietf.org/arch/browse/tls/?q=Christian%20Kahlo. Seit 2014 dabei, eID auf Secure Elements, USIMs, hybrid IDs & Wearables zu bringen (“Smart eID”). In 2015 Teil der adesso geworden und entwickelt mit über 20 Jahren Praxiserfahrung in der IT-Sicherheit, angewandter Kryptographie und ID-Systeme teilweise auch noch selbst mit.

Ich danke allen Reviewern herzlichst für das wertvolle Feedback und die eingesandten Korrekturen und insbesondere bei HonkHase (https://twitter.com/HonkHase) für die Qualitätssicherung der Aussagen in diesem Artikel.

--

--

Chief Security Architect, CISSP, ISACA, IT-Security 1998+, eID & eIDAS, FIDO(2) & WebAuthn, real world cryptography & secure elements, born&living in EU: EN/DE

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christian Kahlo

Christian Kahlo

Chief Security Architect, CISSP, ISACA, IT-Security 1998+, eID & eIDAS, FIDO(2) & WebAuthn, real world cryptography & secure elements, born&living in EU: EN/DE