Verhaltensbasierte Identität

DynamischeEntropie für dezentrale Schlüssel

Die digitale Identität steht am Scheideweg: Traditionelle Login-Methoden mit Benutzernamen und Passwörtern sind unsicher und umständlich, während zentralisierte Identitätsdienste zunehmend Bedenken hinsichtlich Datenschutz und Kontrolle aufwerfen. Verhaltensbasierte Identitätssysteme versprechen hier einen innovativen Ansatz. Statt sich auf statische Merkmale oder zentral gespeicherte Daten zu verlassen, nutzen sie die einzigartigen Verhaltensmuster eines Benutzers – etwa Mausbewegungen, Tippgeschwindigkeiten oder Wortwahl – um kontinuierlich eine digitale Identität zu formen. Diese ständig im Hintergrund erhobenen Verhaltensdaten können in Echtzeit dynamische Entropie liefern, also echte Zufälligkeit, die für kryptografische Verfahren essenziell istopensource.com. Aus dieser lokal gewonnenen Entropie generiert das System kryptografische Schlüssel, welche der Nutzer selbst verwaltet.

Der Clou: Solche Schlüssel lassen sich anonym in einem Blockchain-Netzwerk registrieren oder prüfen, zum Beispiel in Form einer dezentralen Identität auf Ethereum oder Hyperledger Indy. Dadurch können Benutzer ihre Identität verifizieren, Zugriff kontrollieren (etwa als Login-Ersatz oder Türschlüssel) oder sogar Tokens erzeugen – ohne dabei persönliche Daten preiszugeben. Dieses Konzept verbindet spannende Technologien aus verschiedenen Bereichen: Behavioral Biometrics, Entropy Harvesting, WebAuthn, Decentralized Identifiers (DIDs), Zero-Knowledge Proofs, MPC/Threshold-Kryptografie und klassische Hardware-Token.

In diesem Beitrag geben wir einen Überblick über die relevanten Technologien und Grundlagen, skizzieren die Architektur eines solchen hybriden Systems und analysieren Sicherheits- sowie Datenschutzaspekte. Wir vergleichen zudem bestehende Lösungen – von Worldcoin bis zkLogin – und arbeiten die Alleinstellungsmerkmale unseres verhaltensbasierten Ansatzes heraus. Abschließend diskutieren wir realistische Anwendungsfälle (z. B. in Web3-Identitäten, Offline-Zugriffsrechten, Krypto-Wallets) sowie die Herausforderungen und offenen Fragen, die es auf dem Weg zu einer praktischen Umsetzung zu lösen gilt.

Verwandte Technologien

Bevor wir in die technischen Details einsteigen, lohnt sich ein Blick auf die bestehenden Konzepte und Standards, die unser System beeinflussen. Es handelt sich um eine interdisziplinäre Lösung, die Ideen aus verschiedenen Feldern vereint. Im Folgenden ein Überblick über die wichtigsten verwandten Technologien.

Verhaltensbiometrie (Behavioral Biometrics)

Unter Behavioral Biometrics versteht man Authentifizierungsverfahren, die auf dem individuellen Verhalten einer Person basieren – im Gegensatz zu physischen Biometrics wie Fingerabdruck oder Gesicht. Solche Systeme analysieren Aktionsmuster, um die Identität einer Person fortlaufend und unaufdringlich zu verifizierentripwire.com. Typische Beispiele sind:

• Tippverhalten (Keystroke Dynamics): Jeder Mensch tippt in einem einzigartigen Rhythmus. Gemessen werden Tippgeschwindigkeit, Pausen zwischen Anschlägen, bevorzugte Tastenkombinationen (z. B. ob jemand eher mit linker oder rechter Umschalttaste arbeitet) sowie Fehlerquotepingidentity.com. So entsteht ein Muster, das einen Nutzer ähnlich wie ein Fingerabdruck charakterisieren kann. Interessanterweise geht es nicht nur um reines Tempo, sondern um die Rhythmik und den individuellen Stil der Eingabepingidentity.com. In der Praxis können Systeme die Tastatureingaben eines Benutzers im Hintergrund mit dem gespeicherten Profil abgleichen, um sicherzustellen, dass noch derselbe Mensch am Gerät ist – eine Form der kontinuierlichen Authentifizierung.
• Mausbewegungen und Zeigegeräte: Auch wie jemand die Maus bewegt – Geschwindigkeit, Beschleunigung, kleine Zitterbewegungen – sowie das Klickverhalten (Druckdauer, Doppelklick-Rhythmus) bilden ein unverwechselbares Profilpingidentity.com. Sogar minimale Handbewegungen und Gesten können erfasst werdenpingidentity.com. Ein Mensch bewegt den Mauszeiger erfahrungsgemäß mit leichten Unregelmäßigkeiten und Kurven, während Roboter oder Bots oft unnatürlich geradlinige oder gleichförmige Bewegungen zeigenpingidentity.com. Solche Analysen werden schon heute eingesetzt, um automatisierte Bots von echten Nutzern zu unterscheidenpingidentity.com.
• Touchscreen-Interaktionen: Auf Smartphones und Tablets werden Wischgesten, Tippkraft und sogar der Neigungswinkel des Fingers erfassttripwire.com. Jeder hat z. B. ein eigenes Muster, mit welchem Winkel und Druck er über den Touchscreen scrollt. Diese Daten können ebenfalls in ein Behavioral-Biometric-Profil einfließen.
• Navigation und sonstige Verhaltensmuster: Darüber hinaus lassen sich auch höhere Interaktionsmuster betrachten – z. B. wie jemand typischerweise durch eine Website oder App navigiert, welche Pfade er nimmt, wie lange er verweilt etc.tripwire.com. Solche Verhaltensweisen sind schwer durch Angreifer zu imitieren und können in Summe ein robustes Identitätsmerkmal ergeben.

Kurz gesagt ermöglichen Behavioral Biometrics einen persistenten „digitalen Fingerabdruck“ des Verhaltens, der zur kontinuierlichen Authentifizierung genutzt werden kann, ohne dass der Nutzer ständig aktiv Passwörter eingibt oder Tokens vorzeigt. Für unser Identitätssystem sind sie fundamental, denn sie liefern die Rohdaten, aus denen wir Entropie gewinnen und letztlich kryptografische Schlüssel ableiten. Wichtig ist: Im Gegensatz zu Fingerabdruck oder Iris bleiben Verhaltensdaten lokal flüchtig und werden nicht in einer zentralen Datenbank gespeichert – ein Pluspunkt in Sachen Privatsphäre, den wir später noch betrachten.

Entropiegewinnung aus Nutzereingaben

Zufall oder Entropie ist das Herzstück sicherer Kryptografie. Ein Kryptoschlüssel muss ausreichend zufällig (und damit unvorhersehbar) sein, damit Angreifer keine Chance haben, ihn durch Raten oder Berechnen zu ermittelnopensource.com. Moderne Betriebssysteme sammeln daher fortlaufend Entropie aus unterschiedlichen Quellen – Hardware-Timing, Geräuschrauschen, Netzwerkjitter etc. – um zuverlässige Zufallszahlen zu erzeugen. Eine oft unterschätzte Quelle für echten Zufall sind Nutzereingaben: Die kleinen Ungenauigkeiten und nicht vorhersagbaren Variationen in menschlichen Aktionen.

 Bereits seit den frühen Unix-Systemen füttern Ereignisse wie Mausbewegungen und Tastendrücke den sogenannten Entropie-Pool (/dev/random), weil man erkannt hat, dass menschliche Interaktionen einen wertvollen Beitrag zur Zufallserzeugung leistenopensource.com. Studien haben gezeigt, dass man aus bewussten Mausbewegungen über einige Sekunden eine beträchtliche Menge an Zufallsbits extrahieren kanncrypto.stackexchange.com. Ebenso enthalten Zeitabstände zwischen Tastaturanschlägen oder die genauen Koordinaten einer Cursor-Bewegung unpredictability, die für einen Außenstehenden nicht deterministisch vorhersagbar ist.

 Ein einfaches Beispiel: Wenn Sie gebeten werden, den Mauszeiger zufällig über den Bildschirm zu bewegen, erzeugen Sie in kurzer Zeit Hunderte von Datenpunkten (Positionen, Zeitintervalle), aus denen sich Bits extrahieren lassen. Durch kryptografisches Hashing dieser Daten erhält man einen Zufalls-Seed, der als Ausgangspunkt für Schlüssel dientcrypto.stackexchange.com. Wie eine Fachpublikation es auf den Punkt bringt: "Entropy ... obtained from keyboard strokes, mouse movements and other physical noises can be used to generate cryptographic keys from random bits."theserverside.com. Anders formuliert, jeder unvorhersehbare Zuck des Mauszeigers oder unregelmäßige Tastenanschlag trägt ein Stück zur Gesamtentropie bei.

 Für unser System ist dieses Entropy Harvesting von zentraler Bedeutung. Während der Nutzer ganz normal mit seinem Gerät arbeitet (tippt, scrollt, klickt, Texte schreibt), sammelt ein lokaler Dienst permanent diese Mikro-Datenpunkte ein. Wichtig dabei ist, tatsächlich lokal zu bleiben: Die Rohdaten der Nutzerinteraktionen verlassen zu keinem Zeitpunkt das Gerät. Stattdessen werden sie innerhalb des Clients zu Zufallsbits verdichtet. Auf diese Weise entsteht ein dynamischer Strom von Entropie, der anders als ein Hardware-Random-Generator sogar vom individuellen Nutzerverhalten geprägt ist. Damit schlagen wir zwei Fliegen mit einer Klappe: Wir bekommen einerseits genügend Zufälligkeit für starke Schlüsselopensource.com, andererseits fließt damit auch eine Portion der einzigartigen Nutzersignatur in die Schlüssel ein (was z. B. Spoofing-Angriffe erschwert, weil man nicht nur einen Schlüssel klauen, sondern auch das Verhalten imitieren müsste).

 Natürlich muss man bei dieser Entropiegewinnung sorgsam sein: Faktoren wie systematische Verzögerungen oder vorhersagbare Elemente (z. B. immer gleiche Mauswege) liefern wenig Entropie und könnten von Angreifern modelliert werden. Daher konzentriert man sich auf möglichst unabhängige, von Menschen beeinflusste Noise-Quellen. Zudem werden die gesammelten Daten durch robuste Hashfunktionen geleitet, um daraus gleichmäßig verteilte Zufallsbits abzuleiten und eventuelle Muster zu eliminieren. Eine solche Hashfunktion in unserem Baukasten ist BLAKE3, zu der wir gleich noch kommen.

WebAuthn und lokale schlüsselbasierte Authentifizierung

Eine Technologie, die bereits heute die Brücke zwischen lokalen Schlüsseln und Online-Identität schlägt, ist WebAuthn (Web Authentication). WebAuthn ist ein vom W3C und der FIDO-Allianz entwickelter Standard, der es Webdiensten ermöglicht, Benutzer über öffentliche-/private Schlüsselpaare statt Passwörtern zu authentifizierenduo.com. Dabei wird der private Schlüssel sicher auf dem Endgerät des Nutzers erstellt und gespeichert – sei es im Trusted Platform Module (TPM) des Laptops, in der Secure Enclave eines Smartphones oder auf einem externen Hardware-Token (z. B. YubiKey).

 Wenn man sich auf einer Website registriert, generiert der Browser via WebAuthn ein Schlüsselpaar und sendet nur den öffentlichen Schlüssel an den Server. Zur Anmeldung beweist das Gerät dann, dass es den privaten Schlüssel hat (etwa durch eine digitale Signatur einer Server-Challenge)duo.com. Meist wird zusätzlich eine Benutzerverifikation verlangt – z. B. Fingerabdruckscanner, Gesichts-ID oder eine PIN –, um sicherzustellen, dass der rechtmäßige Besitzer gerade am Gerät ist. Für den Benutzer fühlt sich das an wie ein bequemer Login per Fingerabdruck oder FaceID, aber im Hintergrund passiert hochgradig sichere Public-Key-Kryptografie.

 Wichtig in unserem Kontext: WebAuthn beweist, dass client-seitige Schlüsselgenerierung im Massenmarkt praktikabel ist. Milliarden von Geräten unterstützen diesen Standard bereits. Der private Schlüssel verlässt niemals das Nutzergerätcpl.thalesgroup.com, was Phishing und Datenbank-Leaks effektiv vorbeugt. Selbst ein kompromittierter Server hat keinen Zugriff auf die Login-Schlüssel der Nutzer. Dieses Prinzip – „Schlüssel gehören dem Nutzer“ – teilen wir auch in unserem System. Allerdings geht WebAuthn nicht so weit, die Schlüssel selbst aus Verhalten abzuleiten; die Schlüssel werden dort meist aus Hardware-Zufall erzeugt und sind statisch pro Registrierung. Unser System könnte man sich nun als Erweiterung vorstellen, die die lokalen Schlüssel kontinuierlich aus dem Nutzerverhalten speist und dynamisiert.

 Ein weiterer relevanter Aspekt sind Hardware-Token à la USB-Stick. FIDO2-Sicherheitsschlüssel (z. B. YubiKeys) implementieren WebAuthn auf dedizierter Hardware. Sie stecken das Gerät per USB (oder NFC) an, drücken einen Knopf zur Bestätigung – und schon meldet man sich an. Technisch gesehen ist solch ein Sicherheitsschlüssel ein kleines Kryptogerät, das einen privaten Schlüssel enthält und auf Berührungs- oder PIN-Eingabe ein Signaturverfahren ausführtcpl.thalesgroup.com. Der Vorteil: Der Schlüssel ist physisch getrennt vom PC/Smartphone und oft gegen Auslesen gehärtet. USB-Krypto-Identitäten sind daher extrem phishing-resistent und werden in Unternehmen und von sicherheitsbewussten Nutzern eingesetzt. Ihr Konzept – Schlüssel im Besitz des Users, geschützt durch Hardware – ist ein Eckpfeiler von dezentraler Identität. Unser System kann mit solchen Hardware-Token koexistieren (z. B. als zusätzliches Sicherungsmittel), unterscheidet sich jedoch darin, dass die Schlüssel hier aus verhaltensbedingter Entropie immer neu generiert werden, statt einmal im Token fix zu hinterlegen.

Dezentrale Identität (DID) und Verifiable Credentials

Im Bereich digitaler Identität vollzieht sich derzeit ein Paradigmenwechsel hin zu Self-Sovereign Identity (SSI) und Decentralized Identifiers (DIDs). Vereinfacht gesagt geht es darum, dass Individuen und Organisationen Identitäten nutzen können, ohne von zentralen Behörden oder Plattformen abhängig zu sein. Eine Decentralized Identifier (DID) ist ein weltweit eindeutiger Identifikator – z. B. in der Form did:example:123456... –, der keinem zentralen Register entspringt, sondern dezentral verwaltet wirddock.io. Typischerweise referenziert ein DID ein Dokument (DID Document) mit öffentlichen Schlüsseln und weiteren Angaben, mittels derer der DID-Besitzer Kontrolle über seine Identität nachweisen kannw3.orgw3.org.

 Wichtig ist, dass ein DID keinen persönlichen Klartext enthält wie Namen oder E-Mail, sondern eher einer Art Kontoadresse entspricht, die auf Blockchain-Netzwerken oder anderen dezentralen Systemen gespeichert werden kanndock.io. Der Clou: Nur der Inhaber des zugehörigen privaten Schlüssels kann beweisen, dass der DID ihm „gehört“ – beispielsweise durch Signaturen. So kann man eine Identität präsentieren, ohne um Erlaubnis bei Facebook, Google oder einer Behörde fragen zu müssenw3.org. Die Kontrolle liegt beim DID-Controller, also letztlich beim Nutzer selbst, der die Schlüssel hältw3.org.

 Auf diesen Fundamenten baut das Konzept der Verifiable Credentials (VCs) auf. Das sind digital signierte Nachweise (z. B. ein Führerschein, Zeugnis oder Impfzertifikat) in Händen des Nutzers. Eine VC wird von einem Issuer ausgestellt und vom Nutzer in seiner digitalen Wallet gespeichert. Bei Bedarf kann er sie einem Verifier vorzeigen, der ihre Echtheit prüft – und zwar ohne Rückfrage beim Aussteller, dank der digitalen Signatur. Beispielsweise könnte eine Universität ein digitales Diplom als VC signieren; der Absolvent speichert es und legt es später einer Firma vor, welche die Signatur prüft. Alles geschieht offline bzw. peer-to-peer zwischen den Beteiligten, oft unter Nutzung von DIDs zum Adressieren der Schlüssel.

 Um solche Abläufe mit bestehenden Web-Ökosystemen zu verbinden, entstehen neue Protokolle wie OpenID for Verifiable Credential Issuance (OID4VCI). Dieses noch im Entwurf befindliche Standardprotokoll definiert eine OAuth-2.0-basierte Schnittstelle, über die Verifiable Credentials ausgegeben werden könnenopenid.netopenid.net. OID4VCI erlaubt es z. B., dass man sich per OpenID Connect beim Aussteller (etwa einem Bank-Login) authentifiziert und dann ein signiertes Credential erhält – ähnlich einem ID-Token, aber in einem format wie W3C VC oder ISO mDL. Damit werden klassische Identity Provider (Google, Microsoft etc.) in die Lage versetzt, dezentral nutzbare Identitätsnachweise auszustellenopenid.net. Projekte wie Authlete 3.0 und Indicio implementieren bereits Teile von OID4VCI in Pilotanwendungenbiometricupdate.com, z. B. Mobile Führerscheine in Wallet-Apps.

 Unser verhaltensbasiertes System kann an diese SSI-Welt andocken: Man könnte dem Nutzer einen DID zuweisen, dessen Key-Material aus seinem Verhalten generiert wird. Über diesen DID kann er dann anonyme Anmeldungen durchführen, Zertifikate empfangen (als Verifiable Credentials) oder Zugangsrechte belegen, ohne je ein zentrales Login durchlaufen zu müssen. Die Blockchain (Ethereum, Indy oder eine andere) dient dabei als neutrale Vertrauensschicht, wo z. B. die DID-Dokumente oder Prüfmethoden hinterlegt sind. Der Nutzer bleibt aber Herr seiner Identität, da er alles Nötige lokal hat – genau im Sinne der Selbstsouveränen Identität.

Zero-Knowledge Proofs (ZKPs) für Privatsphäre

Eine spannende Frage bei Identitätssystemen lautet: Wie kann man etwas beweisen, ohne es preiszugeben? Hier kommen Zero-Knowledge Proofs ins Spiel. Ein Zero-Knowledge-Beweis ist ein kryptografisches Protokoll, bei dem eine Partei (der Beweisführer) einer anderen (dem Prüfer) nachweisen kann, dass eine bestimmte Aussage wahr ist, ohne weitere Informationen preiszugebenen.wikipedia.org. Der klassische Lehrsatz lautet: „Ich beweise Dir, dass ich ein Geheimnis kenne, verrate Dir aber nichts über das Geheimnis selbst.“

 Angenommen, unser System möchte einem Dienst zeigen: „Dies ist ein echter, autorisierter Nutzer (kein Bot), und er besitzt einen gültigen Schlüssel“, ohne jedoch biometrische Daten oder den Schlüssel selbst offenzulegen. Mit Zero-Knowledge-Methoden ist das machbar. Zum Beispiel könnten wir einen ZKP konstruieren, der nachweist, dass der aktuelle Schlüssel des Nutzers aus einer bestimmten DID-Dokument-Registrierung stammt und dass dieser Nutzer in den letzten 5 Minuten aktive Eingaben gemacht hat, ohne dass der Dienst die konkreten Eingaben oder den Schlüssel sieht. ZKPs sind mathematisch komplex, aber dank moderner ZK-SNARKs oder STARKs sogar für Blockchain-Anwendungen praktikabel geworden.

 Ein praktisches Beispiel aus der Web3-Welt ist zkLogin – ein kürzlich vorgestellter Mechanismus, der es Nutzern erlaubt, sich mit bestehenden Web2-Konten (Google, Apple etc.) in Web3-Apps anzumelden, ohne diese Kontodaten offenzulegen. Dabei werden Zero-Knowledge-Beweise genutzt, um nachzuweisen, dass man einen bestimmten Google-Account besitzt, aber gegenüber der Blockchain oder DApp wird nicht der Google-Token selbst geteiltgithub.com. Sui, eine Layer-1-Blockchain, hat zkLogin eingeführt, um Web2-Social-Logins in ihre Wallet-Infra zu integrieren – die Nutzer loggen sich mit Google ein, erhalten einen JWT (Login-Token) und daraus generiert ein ZK-Proof den Nachweis, der on-chain verifiziert werden kannbusinesswire.combusinesswire.com. Der Clou: Privatsphäre und Ownership bleiben beim Nutzer. Ähnlich könnten wir in unserem System ZKPs einsetzen, um gegenüber einem Smart Contract zu beweisen, dass ein Nutzer hinreichend „menschliches“ Verhalten gezeigt hat, bevor er z. B. einen Token claimt – Proof-of-Human sozusagen – ohne dass der Smart Contract die Rohdaten kennen muss.

 ZKPs ergänzen unser System also dahingehend, dass Anonymität und Mindestoffenlegung gewahrt bleiben. Man kann viel feinere Zugriffsregeln bauen („Zeige, dass du über 18 bist, aber verrate nicht dein Geburtsdatum“ – ein klassisches Beispiel für einen Zero-Knowledge-Altersnachweis). In Verbindung mit verhaltensbasierten Identitäten können ZKPs sogar die Akzeptanz steigern, weil Nutzer wissen: Ihre persönlichen Verhaltensmuster werden nicht offen herumgereicht, sondern maximal in Form von verschlüsselten oder Zero-Knowledge-geschützten Werten verwendet.

MPC und Threshold-Kryptografie

Multiparty Computation (MPC) und Threshold-Kryptografie beschäftigen sich damit, kryptografische Operationen und Schlüssel auf mehrere Parteien zu verteilen. Warum ist das relevant? Stellen wir uns vor, wir möchten kein einzelnes Gerät oder keinen einzelnen Punkt haben, der komplett kompromittiert werden kann. In der Threshold-Kryptografie wird ein geheimer Schlüssel in Teile aufgesplittet, die auf verschiedenen Geräten oder bei verschiedenen Personen liegen. Nur wenn genügend Teile (mindestens eine bestimmte Schwelle, z. B. 2 von 3 oder 3 von 5) zusammenkommen, kann eine kryptografische Aktion ausgeführt werdencsrc.nist.rip.

 Dies ermöglicht eine verteilte Vertrauensbasis: Selbst wenn ein Teil kompromittiert wird, bleibt der Gesamtschlüssel sichercsrc.nist.rip. Anwendung findet das z. B. in Schwellen-Signaturen. Mehrere Server können gemeinsam eine digitale Signatur erzeugen, ohne dass je ein einzelner Server den ganzen privaten Schlüssel hatte. Auch verteilte Schlüsselgenerierung gehört dazu – mehrere Parteien würfeln gemeinsam einen Zufallsschlüssel, sodass keiner allein ihn bestimmen konntecsrc.nist.rip.

 In unserem Kontext könnte man MPC nutzen, um die Sicherheit weiter zu erhöhen: Etwa indem der Verhaltens-Entropie-Generator auf dem User-Gerät nur einen Teil eines Schlüssels erzeugt und ein zweiter Teil auf einem anderen Gerät oder einem Edge-Service liegt. Nur beide zusammen ergeben den vollständigen Schlüssel zum Signieren. So ein Ansatz könnte vor Malware schützen – falls ein Virus das Benutzergerät infiltriert, käme er nicht an den vollständigen Schlüssel, weil z. B. 2 von 3 Shares benötigt würden. Allerdings erhöht MPC die Komplexität und erfordert zusätzliche Infrastruktur.

 Ein naheliegenderes Anwendungsfeld für Threshold-Krypto im Identitätsumfeld ist Account Recovery oder Social Recovery. Man stelle sich vor, der Nutzer verliert sein Hauptgerät. Bei selbstsouveränen IDs gibt es kein zentrales „Passwort zurücksetzen“. Hier könnte man bspw. Schlüsselfragmente bei vertrauenswürdigen Freunden oder eigenen Zweitgeräten hinterlegen (nach dem Prinzip von Shamir's Secret Sharing). Eine Gruppe von z. B. 3 von 5 Freunden könnte dann kollektiv einen Ersatzschlüssel generieren, den das System als legitime Fortsetzung der Identität akzeptiert. Einige Krypto-Wallets implementieren bereits Social Recovery über solche Mechanismen.

 Darüber hinaus ist MPC im allgemeineren Sinne interessant, wenn es um die Verarbeitung sensibler Daten geht. Mehrparteien-Rechenverfahren ermöglichen es, Berechnungen auf verteilten Inputs auszuführen, ohne die Inputs offenzulegen. Denkbar wäre, dass mehrere Sensoren oder Dienste zusammenarbeiten, um eine Entscheidung über die Echtheit eines Nutzers zu treffen, ohne dass jeder alles sieht (z. B. einer liefert Tipp-Daten, der andere Maus-Daten, und am Ende kommt ein Gesamtscore heraus). MPC ist aber rechenintensiv, daher sehen wir den Haupteinsatz eher in der Aufteilung von Schlüsseln (Threshold Signatures), um Single Points of Failure zu vermeidencsrc.nist.rip.

Hardware-Token und USB-Krypto-Identitäten

Last but not least seien noch einmal physische Kryptogeräte erwähnt, da sie in vielen Szenarien das Rückgrat von Sicherheit bilden. Neben den schon angesprochenen FIDO2-Sicherheitsschlüsseln (YubiKey & Co.) zählen dazu auch Hardware Wallets für Kryptowährungen (Ledger, Trezor). Die Idee ist simpel: Ein kleiner Rechner, oft in Form eines USB-Sticks oder Smartcards, verwaltet die privaten Schlüssel isoliert vom Hauptsystem. Transaktionen oder Login-Challenges müssen an das Gerät geschickt und dort signiert werden; die privaten Schlüssel verlassen nie das Token.

 In Unternehmensumgebungen werden zudem USB- oder Smartcard-Identitäten genutzt, etwa Mitarbeiterausweise mit Chip, die gleichzeitig als Login-Token dienen. Auch diese basieren auf Schlüsselpaaren (typisch X.509-Zertifikate auf der Karte gespeichert). Man kann sich unser System durchaus vorstellen, dass es mit solchen Hardware-Identitäten kombiniert wird: Zum Beispiel könnte ein Nutzer seinen verhaltensbasierten Schlüssel regelmäßig in ein Hardware-Token sichern (quasi „Entropie-Backup“) oder umgekehrt das Hardware-Token als zusätzliche Entropiequelle nutzen. Ein innovativer Gedanke wäre, ein Hardware-Token zu bauen, das live Behavioral Biometrics misst (etwa ein Sensor, der Tippintervalle aufnimmt) – aber das ist eher Zukunftsmusik.

 Wichtig festzuhalten: Hardware-Token sind Phishing- und Malware-resistent, aber sie sind physisch und können verloren gehen oder gestohlen werden. In unserem verhaltensbasierten System wäre ein gestohlenes Token allein nicht ausreichend für den Angreifer, wenn nicht auch das passende Verhalten imitiert werden kann. Hier haben wir also einen Mehr-Faktor-Effekt: Besitz (Token) + Verhalten (Biometrie) ergeben zusammen die Identität.

 Nachdem wir nun die verschiedenen Technologiebereiche umrissen haben, aus denen unser System Inspiration zieht, wenden wir uns den technischen Grundlagen und dem Entwurf der Architektur zu.

Technische Grundlagen

Im Kern unseres Systems stehen zwei Dinge: die lokale Gewinnung von Entropie aus Nutzerverhalten und die Generierung kryptografischer Schlüssel daraus – robust implementiert, z. B. in einer sicheren Sprache wie Rust. Hier beleuchten wir, wie diese Grundlagen funktionieren.

Lokale Entropiegewinnung und BLAKE3

Wie zuvor beschrieben, sammeln wir kontinuierlich zufällige Aspekte der Benutzerinteraktionen. Diese Rohdaten – seien es Zeitstempel, Positionswerte oder auch inhaltliche Merkmale wie Wortlängen – müssen nun in echte kryptografische Entropie umgewandelt werden. Dafür nutzt man typischerweise Kryptographische Hashfunktionen. Ein Hash nimmt eine beliebig lange Eingabe und erzeugt einen scheinbar zufälligen Ausgabewert fester Länge (z. B. 256 Bit), wobei jede kleine Änderung der Eingabe den Output unvorhersehbar verändert. Hashes wie SHA-256 oder BLAKE2 sind dafür bekannt, extrem empfindlich auf Input-Änderungen zu reagieren (Avalanche-Effekt), was sie ideal macht, um aus Rauschdaten gleichmäßig verteilte Bits zu destillieren.

 Wir setzen hier auf BLAKE3, einen modernen Hash-Algorithmus, der 2020 vorgestellt wurde. Warum BLAKE3? Er ist rasend schnell, parallelisierbar und vielseitig einsetzbar. Laut den Entwicklern ist BLAKE3 „viel schneller als MD5, SHA-1, SHA-2 und SHA-3“ und zugleich kryptographisch sicher (anders als MD5/SHA-1)github.com. BLAKE3 kann intern mehrere Kerne und SIMD-Befehle nutzen, weil er als Baumhash konstruiert ist – dadurch skaliert er exzellent mit moderner Hardwaregithub.com. In Benchmarks erreicht er auf PC-Prozessoren etwa die 5-fache Geschwindigkeit von BLAKE2 und 15-fache von SHA3-256infoq.com. Das ist wichtig, weil wir potenziell Unmengen an kleinen Events hashen müssen; ein langsamer Hash wäre da der Flaschenhals.

 Darüber hinaus ist BLAKE3 nicht nur ein Hash, sondern gleichzeitig ein Kryptografischer PRF, MAC, KDF und XOF in einemgithub.com. Das heißt, wir können ihn nutzen, um deterministisch aus einem Key Material neue Keys abzuleiten (KDF = Key Derivation Function) oder sehr lange bitstrings zu erzeugen (XOF = eXtendable Output Function). In unserem System könnte BLAKE3 sozusagen das „Entropie-Mischwerk“ sein: Alle paar Sekunden oder bei bestimmten Events füttern wir unsere gesammelten Rohdaten in BLAKE3, welcher intern einen laufenden Hash-Status pflegt. Man kann sich das wie einen Entropie-Akkumulator vorstellen. Jedes neue Stück Verhalten (z. B. 50 ms Tastatur-Pause gefolgt von der Eingabe des Buchstabens „e“) wird als differenzieller Input an BLAKE3 gegeben, der interne State aktualisiert sich.

 Zu definierten Zeitpunkten – vielleicht kontinuierlich oder triggerevent-basiert – extrahieren wir aus diesem Hash-Status einen Wert, den wir als privaten Schlüssel oder zur privaten Schlüsselableitung verwenden. Da BLAKE3 auch als Keyed-Hash bzw. PRF arbeiten kann, könnten wir z. B. einen Master-Secret-Seed initial setzen und die laufenden Verhaltensevents nur dazu nutzen, den Output zu variieren, ohne den Master komplett preiszugeben. So entstünde ein deterministisches, aber doch vom Verhalten abhängiges Key-System. Alternativ könnte man den Hash-Output direkt als Private Key interpretieren – allerdings muss man bei schwankenden Eingaben vorsichtig sein, um nicht ständig ganz neue Identitäten zu generieren (dazu mehr im Abschnitt Architektur).

 Wesentlich ist: BLAKE3 bietet uns die Kryptografische Robustheit und Geschwindigkeit, um fortlaufend Entropie zu „ernten“ und in Schlüsselmaterial umzuwandeln, ohne das System zu überlasten. Er ist in Rust implementiert und für zahlreiche Plattformen optimiertgithub.com, was uns zum nächsten Punkt bringt.

Client-seitige Schlüsselgenerierung und Rust-Implementierung

Die Generierung der kryptografischen Schlüssel findet vollständig client-seitig, also auf dem Endgerät des Benutzers, statt. Dies folgt dem Prinzip von WebAuthn & Co.: Private Schlüssel sollten idealerweise nur dort entstehen, wo sie auch verbleiben – nämlich beim Nutzer selbst. Es gibt keinen sicheren Grund, einen privaten Schlüssel jemals an einen Server zu senden (außer man macht Backups, aber das ist ein separater Workflow mit eigenen Schutzmaßnahmen). Durch lokale Schlüsselgenerierung vermeiden wir nicht nur zentrale Angriffspunkte, sondern ermöglichen auch echte Offline-Fähigkeit: Der Nutzer kann sich identifizieren oder Transaktionen signieren, selbst wenn keine Verbindung zu einer zentralen Instanz besteht, solange er nur irgendwie dem Gegenüber seinen öffentlichen Schlüssel oder einen Nachweis darüber präsentieren kann (z. B. in Form einer signierten Nachricht oder eines DID-Dokuments auf der Blockchain).

 Um das sicher umzusetzen, ist die Wahl der Programmiersprache und der Krypto-Bibliotheken entscheidend. Rust hat sich in den letzten Jahren als Liebling der Sicherheits- und Kryptografie-Community etabliertmedium.com. Die Sprache bietet Memory Safety (Speichersicherheit) ohne Garbage Collection, was bedeutet, dass typische Fehler wie Buffer Overflows, Use-after-free oder Null Pointer Dereferenzen vom Compiler weitgehend verhindert werdenmedium.commedium.com. Gerade in der Kryptografie, wo solche Fehler katastrophale Schlüssel-Leaks bedeuten könnten, ist das ein enormer Vorteil. Zudem ist Rust sehr performant und ermöglicht low-level Kontrolle ähnlich C/C++, aber mit Sicherheitsnetzen.

 Viele neuere Kryptografie-Implementierungen sind in Rust geschrieben – ein prominentes Beispiel haben wir schon genannt: Die offizielle Implementierung von BLAKE3 ist in Rust entwickeltgithub.com. Auch gängige Bibliotheken für Dinge wie Ed25519-Signaturen, Zero-Knowledge-Proofs (z. B. die Noir-Sprache, die in zkLogin benutzt wirdgithub.com, basiert auf Rust) oder Wallet-Funktionen existieren als Rust-Crates. Die Entscheidung für Rust bedeutet auch, dass wir auf ein wachsendes Ökosystem aufsetzen: Kryptographische Libraries, Ergebnisse formaler Verifikation, und eine aktive Entwicklergemeinde stehen bereit. Wie ein aktueller Artikel es formulierte, ist Rust für sicherheitsbewusste Entwickler inzwischen die "Go-to language" geworden, dank seiner Garantie auf Speicher- und Thread-Sicherheit, Performance und des reichen Krypto-Ökosystemsmedium.com.

 Für unser System hieße das konkret: Die Software, die auf dem Gerät des Nutzers läuft (sei es als Hintergrunddienst auf dem PC, als App auf dem Smartphone oder eingebettet in einen Browser-Plugin), sollte idealerweise in Rust entwickelt sein. So minimieren wir das Risiko von Implementierungsfehlern, die zu Seitenkanälen oder Speicherlecks führen könnten – beides heikle Punkte, wenn wir mit sensiblen Entropiedaten und Schlüsseln hantieren. Sollte Rust auf gewissen Plattformen nicht nativ verfügbar sein, könnten Critical Components in Rust als WebAssembly-Modul laufen, was ebenfalls inzwischen gängige Praxis ist.

 Noch ein Vorteil von Rust: Es erlaubt relativ leicht eine Formalüberprüfung des Codes, etwas das in Kryptografie immer mehr an Bedeutung gewinntmedium.com. Man möchte mathematisch sicherstellen können, dass z. B. ein Implementierungsdetail keine Schwäche einführt. Die strenge Typisierung und das Ownership-Modell von Rust geben hier eine gute Grundlage.

 Zusammengefasst bilden also lokal erzeugte Schlüssel + sichere Implementierung die Basis. Der Nutzer hat letztlich auf seinem Gerät eine Art Identity-Agent (in Rust oder vergleichbar), der aus dem verhaltensgenerierten Zufallsstrom z. B. alle 5 Minuten einen neuen privaten Schlüssel ableitet, diesen sicher verwahrt (z. B. in Memory, geschützt durch OS-Sicherheitsmechanismen oder im TPM) und bei Bedarf für kryptografische Operationen (Signaturen, ZKPs) verwendet.

 Nachdem wir die grundlegenden Bausteine – Verhaltensdaten, Entropie, Kryptoprimitive – besprochen haben, schauen wir uns an, wie all das in einer Systemarchitektur zusammenspielt.

Architektur des vorgeschlagenen hybriden Systems

Das verhaltensbasierte Identitätssystem lässt sich als ein hybrides Edge- bzw. Endgerätesystem beschreiben, das bei Bedarf mit einer Blockchain-Komponente interagiert. „Hybrid“ bedeutet hier, dass zwar eine Blockchain als dezentrale Vertrauensinfrastruktur genutzt wird, die eigentliche Magie aber am Rand (Edge), nämlich direkt auf den Geräten der Nutzer, passiert. Schauen wir uns die Architektur von unten (lokal) nach oben (Netzwerk/Blockchain) an, inklusive beispielhafter Komponenten:

Lokaler Identitäts-Agent

Auf jedem teilnehmenden Gerät läuft ein lokaler Identitäts-Agent – das Herzstück des Systems. Dieser besteht aus mehreren Modulen:

• Sensor- und Entropiesammler: Ein Dienst, der die erlaubten Eingaben und Sensoren überwacht. Er sammelt Maus-Ereignisse, Tastatur-Ereignisse, Touch-Eingaben, evtl. weitere Daten wie Gyroskop (wenn mobile) oder Kontextinfos. Wichtig ist, dass er nur solche Daten abgreift, denen der Nutzer zugestimmt hat, und dass dies sicher passiert (z. B. mit niedrigen Rechten, isoliert von Netzwerkkonnektivität, damit rohe Daten nicht exfiltriert werden können).
• Entropy Pool & Hashing: Hier fließen die Ereignisse kontinuierlich ein. Mithilfe von BLAKE3 oder einem ähnlichen Mechanismus wird ein laufender Entropie-Pool aktualisiert. Man kann sich das als Variable H vorstellen, die nach jedem Event ein Update macht: H = BLAKE3(H || Event). Anfangs wird H mit einem starken Zufallswert oder geräte-spezifischen Geheimnis initialisiert, um einen Grundstock an Entropie zu haben. Jedes Input-Event erhöht nun die Entropie von H (oder sollte es zumindest). BLAKE3 als XOF könnte z. B. unendlich viele Ausgabebytes generieren, sodass man jederzeit „frische“ Bits abzweigen kann, ohne denselben Zustand zweimal zu verwenden.
• Key Derivation & Rotation: Dieses Modul ist verantwortlich, aus dem Entropie-Pool kryptografische Schlüssel abzuleiten. Zum Beispiel könnte es alle 5 Minuten einen neuen 256-Bit-Wert aus H ziehen und diesen als privaten Identitätsschlüssel definieren (ggf. konvertiert zu einem gültigen elliptischen Kurven-Schlüssel, RSA-Key oder was auch immer das System nutzt). Alternativ könnte es auch kontinuierlich Keys generieren. Ein möglicher Ansatz: Sliding Window Keys – der Schlüssel wird jede Sekunde minimal geändert, basierend auf dem Entropie-Input, bleibt aber über kurze Intervalle kompatibel. Diese Designentscheidung hängt davon ab, wie eng man Identität und Schlüssel koppeln will. Für viele Anwendungen reicht es vermutlich, pro Sitzung oder pro Zeitfenster einen Key zu haben, anstatt bei jedem Tastenanschlag einen neuen. Wichtig ist aber, dass Key Rotation vorgesehen ist: Die Identität soll kein einmaliger statischer Schlüssel sein, sondern sich organisch weiterentwickeln (ähnlich wie sich ein Mensch im echten Leben auch verändert, aber trotzdem als dieselbe Person erkennbar bleibt). Key Rotation bietet außerdem Sicherheit: Selbst wenn ein Schlüssel kompromittiert würde, gilt er nur für einen begrenzten Zeitraum.
• Secure Storage: Die abgeleiteten privaten Schlüssel müssen sicher im Speicher oder auf dem Gerät aufbewahrt werden, solange sie gültig sind. Hier können OS-Mechanismen wie Hardware-Sicherheitsmodule (TPM, Secure Enclave) oder zumindest verschlüsselter Speicher helfen. Eventuell könnte pro Private Key ein kurzer PIN oder Biometriecheck verlangt werden, bevor er z. B. verwendet wird – ähnlich wie WebAuthn es macht.
• Authenticator (Signatur & ZKP Einheit): Dieses Modul nutzt die aktuellen Schlüssel, um kryptografische Aktionen durchzuführen. Beispielsweise eine digitale Signatur erstellen (etwa um eine Challenge vom Blockchain-Netzwerk zu beantworten, oder einen Token-Transfer zu signieren). Oder es erzeugt einen Zero-Knowledge-Beweis, der gegenüber einem Service vorlegt, dass dieser Nutzer gewisse Eigenschaften erfüllt. Da wir in unserem System möglicherweise viele derartige Anfragen bedienen (Login-Vorgänge, Zugriffsanfragen etc.), kann dieses Modul auch Caching- und Rate-Limiting-Strategien beinhalten, um nicht zu oft Interaktion vom Nutzer zu verlangen. Aber dank der Verhaltenskomponente könnte theoretisch sogar jede Anfrage on-the-fly authentifiziert werden, ohne den Nutzer explizit zu stören (er „authentifiziert“ sich ja quasi die ganze Zeit durchs Tippen und Bewegen – Continuous Authentication).
• DID & Credential Manager: Optional könnte der Agent auch gleich die Verwaltung von DIDs und Verifiable Credentials übernehmen. D.h. er kann auf Anfrage ein DID-Dokument erstellen (mit dem aktuellen Public Key), ans Netzwerk publizieren, oder empfangene Credentials speichern und ggf. präsentieren. Dieser Teil würde mit Standards wie DIDComm oder Credential Handler API zusammenarbeiten.

Edge-/Cloud-Komponente (optional)

Das Wort „Edge bis rein lokal“ im Anforderungstext deutet an, dass das System so konzipiert sein sollte, dass es möglichst lokal funktioniert, aber optional auch Edge-Server einbinden kann. Ein Edge-Server könnte z. B. ein persönlicher Cloud-Dienst sein, der dem Nutzer gehört (etwa ein Home-Server oder ein vom Nutzer kontrollierter Dienst in der Cloud), der aber nicht die sensiblen Daten speichert, sondern nur unterstützende Funktionen übernimmt. Mögliche Rollen einer Edge-Komponente:

• Backup & Synchronisation: Falls ein Nutzer mehrere Geräte hat, könnte ein Edge-Service dabei helfen, verifizierte Identitätsschlüssel oder Zustände zu synchronisieren. Allerdings ist das delikat – man möchte ja gerade nicht komplette Schlüssel auf einem Server speichern. Hier käme z. B. Threshold Cryptography ins Spiel: Der Edge-Server erhält nur einen Split-Key oder einen Hash der Identität, nicht das volle Geheimnis. Alternativ könnte der Edge-Server pro Gerät einen unterschiedlichen Key verwalten, und die Blockchain-Identität ist an mehrere Keys gebunden (Multi-Key-DID), sodass jeder einzelner Key rotieren kann, aber die Gesamt-ID bleibt über ein Set von Schlüsseln bestehen.
• ZKP/MPC Rechenhilfe: Zero-Knowledge-Proofs zu erstellen kann rechenintensiv sein. Ein Edge-Service (unter Kontrolle des Nutzers) könnte die schweren Beweisrechnungen übernehmen, wenn das Endgerät (z. B. ein Smartphone) zu leistungsschwach ist. Wichtig wäre nur, dass der Edge-Service nichts über die Geheimnisse lernt. Möglich wäre, dass das Endgerät die kritischen Teile (wie Zufalls-Challenges signieren) selbst macht, aber rechenaufwändige Beweisgeneration an den Edge auslagert, ohne Rohdaten offenzulegen – notfalls durch MPC: Smartphone und Edge berechnen gemeinsam einen Proof, wobei der Edge nur verschlüsselte Inputs sieht.
• Connectivity & Relay: In einer dezentralen Identitätswelt braucht man oft ein Vermittlungsstück, damit zwei Parteien sich finden. Ein Edge-Server könnte als Relay fungieren, der Anfragen entgegennimmt („User X möchte sich bei Service Y anmelden, hier die Challenge“) und an das richtige Gerät weiterleitet, falls dieses gerade online ist. Allerdings könnte das auch ein rein öffentliches dezentrales Netzwerk leisten (z. B. ein Smart Contract oder DID service endpoint).

Prinzipiell sollte das System aber rein lokal funktionieren können, d.h. ein Gerät allein mit direktem Blockchain-Zugriff sollte ausreichen, um Identitätsfunktionen auszuführen.

Blockchain-Integration

Die Blockchain-Schicht – sei es Ethereum, ein Konsortiums-Ledger wie Hyperledger Indy, oder auch ein DAG/Distributed Ledger – dient primär drei Zwecken:

1. Registrierung von Identitätsdaten: Hierunter fällt zum Beispiel das Verankern eines DID Dokuments auf der Chain, welches den aktuellen öffentlichen Schlüssel des Nutzers enthält. Auf Ethereum könnte das durch einen smarten Vertrag oder ein ENS-ähnliches System geschehen; bei Indy ist es direkt vorgesehen, DIDs und zugehörige öffentliche DID-Dokumente auf dem Ledger zu speichern. Alternativ könnte man auch gar nicht den Key an sich ablegen, sondern einen Commitment (Kryptographischen Fingerabdruck) der Identität. Z. B. einen Hash des initialen Public Keys oder einen zkSNARK-Verifikationsschlüssel, der später Zero-Knowledge-Proofs gegenprüfen kann. Entscheidend: Die Blockchain fungiert als öffentliches Verzeichnis, dem alle vertrauen können, um z. B. den öffentlichen Schlüssel oder eine Identitätsbehauptung von Nutzer X nachzuschlagen, ohne eine zentrale CA fragen zu müssen.
2. Verifikation und Audit: Smart Contracts können genutzt werden, um Zugriffskontrolle oder Token-Ausgabe automatisiert und dezentral abzuwickeln. Beispielsweise könnte ein Smart Contract für eine Web3-Anwendung so programmiert sein, dass er nur Transaktionen akzeptiert, die mit einem Schlüssel signiert sind, der zu einer bekannten verhaltensbasierten ID gehört (d. h. deren DID im System registriert ist). Oder ein Contract könnte eine Funktion mintToken() haben, die überprüft, ob der Aufrufer einen gültigen Zero-Knowledge-Beweis mitliefert, der belegt: „Ich bin eine eindeutige menschliche Identität im System und habe dieses Token noch nicht geholt.“ – Dann würde der Contract einen Token minten (ähnlich dem Proof-of-Personhood-Ansatz wie bei Worldcoin, aber eben mit Verhalten statt Iris). Die Blockchain stellt sicher, dass solche Abläufe transparent und unveränderbar geloggt werden – z. B. könnte man auditieren, wann ein bestimmter DID seinen Schlüssel zuletzt gewechselt hat (Key Rotation Event) oder wie viele eindeutige IDs einen bestimmten Zugang erhalten haben.
3. Dezentrale Identifier-Verwaltung: In einigen DID-Modellen (z. B. did:pkh, did:ethr, did:sov) dient die Blockchain selbst als Anker, der sagt: „Die DID #XYZ gehört der Person, die den privaten Schlüssel zu PublicKey P besitzt.“. Das ist quasi analog zur PKI, nur dass hier kein zentraler Trust Anchor, sondern der Konsens der Blockchain das Vertrauen schafft. Für unser System denkbar: Der allererste Schlüssel, den ein Benutzer generiert (z. B. bei Einrichtung des Systems, wenn er ein Onboarding durchläuft), wird als initialer Identitäts-Key in einem Smart Contract registriert. Danach kann der Nutzer sein Verhalten nutzen, um Nachfolgeschlüssel zu signieren und zu registrieren (Rotation), oder um sich gegenüber Diensten auszuweisen.

Beispielhafter Ablauf einer Registrierung und Nutzung:

• Beim Onboarding erstellt der Nutzer eine neue verhaltensbasierte Identität. Sein Gerät sammelt vielleicht für ein paar Minuten Entropie (der Nutzer tippt einen Beispieltext oder bewegt die Maus in einem Onboarding-Spiel, um initial genügend Zufall zu generieren). Daraus entsteht der erste private Schlüssel K0. Der zugehörige öffentliche Schlüssel P0 wird als DID registriert, sagen wir did:behavior:Alice#P0 auf der Blockchain. Eventuell gleich mit einem kurzen Zero-Knowledge-Nachweis, dass dieser Schlüssel von einem „ausreichend menschlichen“ Prozess erzeugt wurde (wobei das schwer objektiv zu messen ist – eventuell verlässt man sich initial auf das Vertrauen, dass die Software das macht).
• Später, wenn Alice sich bei einem Dienst (sei es eine dezentrale App oder auch ein traditioneller Webservice, der unser System unterstützt) anmelden will, passiert folgendes: Die Anwendung fordert einen Nachweis von Alice' DID an. Alice' Identitäts-Agent bekommt vom Dienst (oder einem zugehörigen Smart Contract) eine Challenge – typischerweise ein randomer Wert, der signiert werden soll, oder eine Aufgabenstellung für einen ZKP. Der Agent signiert die Challenge mit Alice' aktuellem privaten Schlüssel Kn (der sich unter Umständen inzwischen von K0 weg rotiert hat, aber in der DID-Dokumentation z. B. als gültiger Nachfolger vermerkt ist), oder er erzeugt einen Zero-Knowledge-Proof, der belegt „Ich kenne einen gültigen Schlüssel zu DID Alice und mein Verhalten stimmt mit Alice überein“. Die genaue Form kann variieren – einfach ist die Signaturprüfung: Der Dienst oder Smart Contract fragt die Blockchain „ist PublicKey P_n, der diese Challenge signiert hat, mit DID Alice verknüpft?“. Ist die Antwort ja (weil z. B. P_n == P0 oder in einer Update-Liste steht), gilt Alice als authentifiziert.
• Bei sensiblen Vorgängen wie Token-Transfer oder Zugriff auf geschützte Ressourcen könnte man sogar eine fortlaufende Überwachung einbauen: Solange Alice z. B. in einer VPN-Sitzung ist, prüft das System alle X Minuten, ob noch Eingaben von ihr kommen, ansonsten wird die Session gesperrt. Das aber eher als Option – primär dient das System ja dem Login/Einstieg.
• Key Rotation/Aktualisierung: Nehmen wir an, Alice tippt extrem viel und generiert dabei so viel Entropie, dass das System beschließt, nach einer Stunde einen neuen Schlüssel K1 einzuführen. Der Agent würde dann eine Transaktion an die Blockchain senden (automatisiert oder beim nächsten Nutzer-Okay), um P1 als neuen gültigen Schlüssel für DID Alice einzutragen (evtl. den alten zu entfernen oder inaktiv zu markieren). Diese Transaktion kann von Alice selbst mit K0 signiert werden (nach dem Motto „ich, Besitzer des alten Schlüssels, autorisiere diesen Wechsel auf neuen Schlüssel“). Hier sieht man den Wert des dezentralen Ledgers: Key-Management kann vom Nutzer selbst durchgeführt werden, und doch ist es für jeden verifizierbar. Ein Angreifer, der nicht gleichzeitig Zugriff auf Alices Gerät hat, könnte so einen Wechsel nicht vollziehen.
• Widerruf und Wiederherstellung: Sollte ein Gerät verloren gehen oder kompromittiert sein, kann Alice über ein Zweitgerät oder eine Social-Recovery-Prozedur einen Schlüsselwechsel oder DID-Widerruf einleiten. Die Blockchain dient dabei als globaler Anzeiger: z. B. markiert sie DID Alice als compromised bis ein neuer Key registriert ist. Das ist analog zum Zurückziehen eines Zertifikats, nur selbstgesteuert.

Der hybride Charakter zeigt sich darin, dass die Intelligenz am Rand sitzt – sprich, Alices Gerät generiert und verwaltet alles Wesentliche – und die Blockchain nur als nachprüfbares schwarzes Brett fungiert, auf dem minimal notwendige Infos (wie öffentliche Schlüssel oder Prüfsummen) liegen. Keine sensiblen Rohdaten verlassen Alices Kontrolle in lesbarer Form. Optional kann ein Edge-Service unterstützend wirken, aber die Vertrauensstellung bleibt maximal dezentralisiert bzw. beim User.

 Ein komponentenübergreifendes Beispiel: Stellen wir uns eine Zutrittskontrolle in einem Unternehmen vor, die unser System nutzt. Alice nähert sich der Tür; ihr Smartphone hat unsere Identitäts-App. Die Tür (oder ein verbundenes Terminal) sendet eine Herausforderung via Bluetooth an das Telefon: „Beweise Identität XYZ“. Das Telefon erzeugt aus dem aktuellen Verhalten von Alice (sie tippt evtl. gerade eine Nachricht oder bewegt das Handy) den Key und signiert die Challenge, schickt die Signatur zurück. Das Terminal prüft offline anhand einer zuvor geladenen Liste von gültigen öffentlichen Schlüsseln (aus der Blockchain oder einem heruntergeladenen Merkle-Tree), ob Alice berechtigt ist. Die Tür öffnet sich – kein zentraler Server, keine PIN-Eingabe, einfach fließende, unsichtbare Authentifizierung. Wenn Alices Telefon verloren geht, sperrt man auf der Blockchain ihren Key. Hätte ein Dieb das Telefon, müsste er immer noch Alices Tipp- und Nutzungsverhalten perfekt imitieren, um gültige Signaturen zu erzeugen – was äußerst unwahrscheinlich ist.

Sicherheit und Datenschutz

Ein so neuartiges System muss natürlich sorgfältig auf Sicherheitsrisiken und Datenschutzimplikationen geprüft werden. Schauen wir uns zunächst das Bedrohungsmodell an: Welche Angreifer könnten was versuchen, um das System zu kompromittieren, und wie wehrt unser Ansatz das ab?

 1. Diebstahl oder Kompromittierung des Geräts: Wenn ein Angreifer physischen Zugriff auf das Gerät bekommt (z. B. es stiehlt), könnte er versuchen, entweder an gespeicherte Schlüssel zu gelangen oder die laufende Session zu übernehmen. Hier zahlt sich unser Ansatz aus: Es gibt keinen statischen Master-Schlüssel, der auf dem Gerät in einer Datei liegt und den man kopieren kann. Die Identität ergibt sich aus dem Zusammenspiel aus Gerät und Verhalten. Ohne die fortlaufenden Eingaben des legitimen Nutzers wird spätestens nach Ablauf eines Schlüssels das System ins Leere laufen. Nehmen wir an, der Angreifer entwendet das Gerät im entsperrten Zustand – ein Worst-Case-Szenario. Er könnte für kurze Zeit Aktionen durchführen (solange der aktuelle Schlüssel gültig ist und vielleicht noch ein paar Sekunden bis Minuten kein Unterschied im Verhalten erkannt wurde). Aber sehr schnell dürfte das System Anomalien bemerken: Die Tippmuster und Mauswege weichen vom Profil ab, und die neu generierten Keys stimmen nicht mehr mit dem bisherigen Verlauf überein. Das System könnte dann z. B. eine Re-Authentifizierung verlangen oder sich sperren. Verhaltensbiometrie wirkt hier als kontinuierliche Watchdog-Funktion, die bei device theft deutlich mehr Schutz bietet als ein statisch entsperrtes Gerät.

 Selbst wenn der Angreifer das Gerät klonen könnte (z. B. ein Backup einspielen auf anderer Hardware): Er hat nicht Alices Hände und Gewohnheiten. Es ist, als würde er versuchen, Alices Handschrift perfekt zu fälschen – möglich für einzelne Signaturen vielleicht, aber nicht in der Live-Produktion bei jeder Zeile Text. Zudem würde in vielen Fällen die Benutzerverifikation (PIN/Biometrie) auf dem Gerät zusätzlich greifen, sobald kritische Aktionen anstehen.

 2. Abhören der Kommunikation (Man-in-the-Middle): Was, wenn jemand die Challenge-Response oder Blockchain-Kommunikation abhört? Durch die Verwendung von Standard-Kryptografie (digitale Signaturen, ZKPs) sind die übertragenen Daten für sich genommen nicht sensibel. Eine Signatur beweist nur, dass der Sender den privaten Schlüssel hat, aber der Lauscher kann daraus den Schlüssel nicht errechnen. Auch Zero-Knowledge-Proofs sind per Definition so gestaltet, dass ein Beobachter nichts lernen kann außer der Gültigkeit. Solange wir auf etablierten Protokollen (TLS für Transport, altbewährte Signaturverfahren wie Ed25519 oder ECDSA, etc.) aufsetzen, besteht hier kein spezielles Risiko. Wichtig: Die öffentliche Blockchain ist öffentlich einsehbar; was dort liegt (z. B. DIDs, Public Keys) kann natürlich von jedem gelesen werden. Das ist aber in Ordnung, da es keine Klardaten zur Person preisgibt – die DID ist pseudonym, der Public Key an sich verrät nichts über die reale Identität. Datenschutztechnisch muss man dennoch aufpassen, dass aus On-Chain-Aktivitäten nicht indirekt auf Personen geschlossen wird (Stichwort Metadaten). Wenn z. B. jemand beobachten kann, dass DID Alice täglich um 9 Uhr einen Login beweist und daraus auf ihre Arbeitszeiten schließt, ist das vielleicht unerwünscht. Hier könnte man mit Rotation von DIDs oder Nutzung von One-Time-Nullifiers arbeiten – aber das geht tief in Privacy-Design, eventuell unter Einsatz von ZKP, um genau solche Korrelationen zu verhindern.

 3. Nachahmung des Verhaltens (Impersonation): Ein raffinierter Angreifer könnte versuchen, Alices Verhalten aufzuzeichnen und zu replizieren, etwa mit Malware, die alle Maus- und Tastaturevents mitschneidet, um dann ein Programm dieselben Muster ausführen zu lassen. In der Tat ist dies eine ernstzunehmende Bedrohung – so wie Fingerabdruckscanner durch hochauflösende Fotos getäuscht werden können, könnte man denken, Behavior lässt sich auch faken. Allerdings gibt es hier ein paar Abmilderungen:

 Erstens sind die Verhaltenssignale extrem hochdimensional und kontextabhängig. Selbst wenn man alle Tastendrücke aufzeichnet, in welchem Kontext reproduziert man sie? Das Replay wäre nur gültig, wenn der Angreifer genau die gleiche Challenge-Signatur-Sequenz abwickeln möchte, was schwierig ist. Zweitens kann das System bewusste Challenge-Responses im Verhalten einführen: Eine Idee aus der Forschung ist es, Nutzer kleine zufällige Aufgaben machen zu lassen (z. B. ein Captcha tippen oder eine bestimmte Geste vollführen), um sicherzugehen, dass ein Live-Mensch agiert und kein stures Abspiel. Da unser System ohnedies Nutzerinteraktion hat, könnte man solche Challenges unauffällig einbetten – z. B. ändert sich die Hintergrundfarbe in der App leicht und der Nutzer klickt reflexartig einen Button, der nur auftaucht, wenn er echt ist. Das kann kein Replay so einfach vorhersehen. Letztlich bewegt man sich hier im Feld Sicherheit durch Lebenszeichen, ähnlich wie Liveness Detection bei Gesichtserkennung.

 Drittens: Durch die Kombination mit Kryptografie – sprich, die Mausbewegungen allein bringen ja nichts, sie müssen ja noch den passenden Schlüssel generieren – muss ein Angreifer, der nur Verhalten hat, trotzdem noch den initialen Schlüsselzustand kennen. Und der ist geheim. Es ist vergleichbar mit einem Einmalschlüssel-Pad: Selbst wenn man genau die gleichen Eingaben macht, ohne Kenntnis des aktuellen internen Entropiestands H wird das Ergebnis für den Key anders sein. Das System könnte etwa mit einem geheimen Startwert initialisiert sein, sodass ein reines Replay ins Leere läuft, weil der Angreifer nicht denselben hidden state hat.

 4. Kompromittierter Server oder Blockchain: Sollte ein Dienst, der unser System nutzt, kompromittiert werden, oder ein Smart Contract einen Bug haben, könnte ein Angreifer versuchen, unerlaubt Zugriffe zu erlangen. Hier punkten wir gegenüber herkömmlichen Systemen: Es gibt keinen zentralen Server, der die Schlüssel aller Nutzer enthält – kein zentrales Passwort- oder Biometrie-Repository, das geleakt werden könnte. Ein Angriff auf einen Smart Contract könnte z. B. versuchen, unberechtigt viele „Proof-of-Personhood“-Tokens zu ziehen. Doch dank der Kryptografie (z. B. jeder DID kann nur einmal einen bestimmten Token prägen, und jeder DID erfordert ein einzigartiges menschliches Verhalten) wäre das nicht trivial. Sollte die Blockchain selbst unsicher sein (50%-Angriff etc.), hat man natürlich generelle Probleme, aber das sprengt unseren Rahmen – wir verlassen uns auf die Sicherheit des gewählten Netzwerks.

 5. Datenschutz und Missbrauch der Verhaltensdaten: Ein äußerst wichtiger Aspekt: Wir sammeln sehr persönliche Verhaltensdaten. Wenn diese in falsche Hände geraten würden oder missbraucht würden, wäre das ein massiver Eingriff in die Privatsphäre. Unser Designprinzip ist daher: Datenminimierung und Lokaler Verbleib. Die Rohdaten der Eingaben sollen weder dauerhaft gespeichert (über den Bedarf hinaus) noch übertragen werden. Nur abgeleitete Entropie bzw. Keys – die man nicht zurückrechnen kann – verlassen das Gerät. Damit hätte ein potenzieller Angreifer auch wenig Interesse daran, diese Daten zu entwenden, weil sie anonym und nicht zuordenbar sind. Dennoch könnten kritische Stimmen anmerken: "Moment, aber wenn dein System auf meinem PC ständig meine Tippmuster analysiert, ist das nicht per se ein Keylogger, sprich ein Risiko?" – Hier muss Transparenz geschaffen werden. Da der Code idealerweise Open Source ist (viele solcher Projekte hosten ihren Code auf GitHub – was wir auch vorhätten – damit Experten auditieren können, dass keine böse Funktion drinsteckt), kann Vertrauen aufgebaut werden. Nutzer müssten explizit einwilligen, so wie man einer Passwortmanager-Software oder einem Fingerprint-Sensor vertraut.

 Ein Vorbild, was Privatheit betrifft, kann sogar Worldcoin sein, so kontrovers das Projekt in mancher Hinsicht ist: Worldcoin betont, dass der Iris-Scan selbst nach Berechnung einer ID gelöscht wird und nur Hashes gespeichert werdenen.wikipedia.org. Trotzdem bestehen Datenschutzbedenken globalen.wikipedia.org. Unser System hat den Vorteil, dass es ohne biometrische Massenregistrierung auskommt und keine physischen Merkmale speichert, sondern nur kurzfristige Verhaltensfetzen nutzt, um mathematische Ableitungen (Schlüssel) zu produzieren. Wir senden auch keine Verhaltensdaten an einen Server, was z. B. bei einigen verhaltensbiometrischen Betrugserkennungssystemen heute üblich ist (etwa die Banking-Branche nutzt Behavioral Biometrics oft serverseitig im Hintergrund). Bei uns bleibt alles im Gerät – somit kein zentraler Datenpool, der von Behörden oder Hackern begehrt werden könnte.

 Vorteile gegenüber serverzentrierten Systemen lassen sich wie folgt zusammenfassen:

• Kein Single Point of Failure / Breach: Es gibt keine zentrale Benutzerdatenbank mit Passwörtern oder biometrischen Templates. Somit kein großes Ziel für Angriffe à la „500 Mio. Passwörter geleakt“. Jede Identität wird vom Nutzer kontrolliert und isoliert.
• Kein Phishing, keine Passwörter: Durch die Verwendung von asymmetrischen Schlüsseln und lokalen Faktoren wird Phishing erheblich erschwert. Ein Angreifer kann nicht einfach den Nutzer auf eine Fake-Seite locken und dessen „Verhalten klauen“ – das Konzept ergibt keinen Sinn, denn Verhalten ist nicht statisch übertragbar wie ein Passwort. Selbst eine Herausgabe des momentanen Keys würde wenig nützen, da er bald verfällt.
• Anonymität und Pseudonymität: Nutzer können sich pseudonym bewegen. Man muss keinem Anbieter mehr seine E-Mail oder Telefonnummer geben, um einen Account zu erstellen – der DID genügt. Und dank Zero-Knowledge kann man trotzdem vertrauenswürdige Aussagen machen (z. B. „ich bin bereits KYC-verifiziert worden, hier ein ZKP davon“ ohne den Anbieter jedes Mal den echten Namen wissen zu lassen).
• Nutzerkontrolle & Transparenz: Der Nutzer hat Einblick in seine Identitätsprozesse. Im Idealfall bietet die App UI Einblicke wie „Deine aktuelle Identitätsstärke: hoch – Keys werden regelmäßig rotiert. Keine ungewöhnlichen Aktivitäten erkannt.“. Das schafft Vertrauen. Bei zentralen Systemen weiß man oft nicht, was hinter den Kulissen mit den Daten passiert.

Natürlich gibt es auch Nachteile oder zumindest Herausforderungen, zu denen wir im letzten Abschnitt kommen. Zunächst aber lohnt ein Blick auf bereits existierende Systeme und Forschungsprojekte, die unserem Ansatz ähnlich sind oder Teilaspekte davon realisieren.

Vergleich mit bestehenden Ansätzen

Es ist immer hilfreich, Innovationen im Kontext bereits vorhandener Lösungen zu betrachten. Unser verhaltensbasiertes Identitätssystem vereint zwar verschiedene Features in neuartiger Kombination, doch jede Komponente für sich hat Vorläufer oder Pendants.

 Worldcoin (World ID): Ein prominentes aktuelles Projekt, das auf „Proof-of-Personhood“ abzielt, ist Worldcoin. Hier wird mittels eines speziellen Iris-Scanners (dem „Orb“) überprüft, ob eine Person einzigartig ist. Nach einem Iris-Scan erhält man eine World ID, eine digitale Identität, mit der man beweisen kann, dass man ein einzelner Mensch ist (und z. B. ein UBI-Token bekommen kann)en.wikipedia.org. Im Unterschied zu unserem Ansatz setzt Worldcoin auf ein physisches Biomerkmal – die Iris – welches sehr genau und langfristig stabil ist. Die Vorteile sind: Hohe Einmaligkeit (extrem geringe False-Match-Rate laut Whitepaper) und einfache Verifizierung offline via Spezialgerät. Jedoch hagelt es Kritik in Sachen Privatsphäre und Zentralisierung: Nutzer müssen ihren hochsensiblen Iriscode einem Unternehmen anvertrauen, was weltweit Datenschutzbehörden auf den Plan gerufen haten.wikipedia.org. Zudem erfordert es dedizierte Hardware (die Orb), was das Onboarding erschwert. Unser System dagegen nutzt Alltagsgeräte und alltägliches Verhalten, was niedrigschwelliger ist, und belässt die sensiblen Daten beim Nutzer. Allerdings sind Verhaltensdaten weniger zuverlässig einzigartig als Iris – es ist eine Art weicher Biometrie-Ansatz, während Worldcoin auf harte Biometrie setzt. Ein Alleinstellungsmerkmal unseres Systems ist somit die Zugänglichkeit und Kontinuität: Keine futuristischen Scanner nötig, sondern aus Gewohnheiten generierte Identität. Und anstatt ein einmaliges Scan-Event (Orb einmal anstarren) zu haben, passiert unsere Verifikation laufend.

 zkLogin (Shield Labs / Sui): Das zkLogin-Konzept auf Sui zeigt, dass es einen Bedarf gibt, Web2-Identitäten (Google, Facebook Accounts) datenschutzfreundlich in Web3 zu nutzenbusinesswire.com. Durch Zero-Knowledge wird dabei ein Brückenschlag geschafft: Der Nutzer loggt sich herkömmlich bei Google ein, bekommt aber dann einen Beweis, den die Blockchain akzeptiert, ohne Googles Beteiligunggithub.com. Im Grunde wird also ein bestehender Identity-Provider leveraged, um die Einstiegshürde in Web3 zu senken. Unser System geht den umgekehrten Weg: wir wollen gar keinen traditionellen Provider mehr – der Nutzer selbst wird zum Identity-Provider durch sein Verhalten. Das ist radikaler und unabhängiger. Ein Vorteil von zkLogin ist die Benutzerfreundlichkeit, weil jeder einen Google-Account bedienen kann. Unser System erfordert eventuell etwas mehr Initialaufwand und neue UX-Konzepte, weil es bislang unüblich ist, dass das eigene Tippverhalten als Authentifikator dient. In einer Zukunftsvision könnten aber beide Ansätze koexistieren: Vielleicht meldet man sich initial via Google (zkLogin) an, und sobald genug Verhalten gesammelt ist, übernimmt die verhaltensbasierte ID die Sitzung und man braucht Google nicht mehr.

 Behavioral Biometrics in der Praxis: Bereits heute nutzen viele Unternehmen verhaltensbiometrische Lösungen (von Anbietern wie BehavioSec, BioCatch etc.), insbesondere zur Betrugserkennung bei Online-Banking. Dort läuft meist ein Skript im Hintergrund der Webseite oder App, das Maus- und Tastaturverhalten trackt und mit bekannten Mustern abgleicht. Weicht etwas stark ab, schlägt es Alarm (z. B. der echte Benutzer tippt immer langsam mit zwei Fingern, jetzt kommen 500 Anschläge pro Minute – könnte ein Bot sein). Diese Lösungen sind jedoch proprietär und serverseitig: Die Profile liegen beim Dienst, nicht beim Nutzer. Unser System kann man als Umkehrung sehen: Wir möchten diese Profile nicht dem Bankserver geben, sondern dem Nutzer zum Vorteil gereichen lassen, und zwar als aktives Authentifizierungsmerkmal statt nur passive Betrugserkennung. Forschungsseitig gab es in den letzten Jahren einige Arbeiten zu biometrischer Schlüsselerzeugung – wie kann man aus Fingerabdruck, Herzschlag oder Tippmustern stabile kryptografische Schlüssel ableiten? Die große Herausforderung dabei ist die Wiederholbarkeit: Biometrische Daten sind nie zu 100 % identisch, wenn man sie erneut erfasst. Man braucht also Fuzzy-Methods (Fehlerkorrektur, sichere Skizzen)crypto.stackexchange.comcrypto.stackexchange.com. Viele Ansätze scheiterten daran, dass entweder die Fehlerrate hoch war oder die Schlüssellänge gering (nur wenige Bits Entropie)crypto.stackexchange.com. Unsere Lösung umschifft das teilweise, indem wir nicht versuchen, exakt denselben Schlüssel immer aus z. B. einem Fingerabdruck zu ziehen, sondern Entropie akkumulieren und flexibel neue Schlüssel generieren. Außerdem kombinieren wir Verhalten mit traditioneller Kryptographie (Hashfunktionen), um die Instabilität abzufedern. Dennoch können wir von dieser Forschung lernen, insbesondere was Fehlertoleranz angeht (Stichwort secure sketch: öffentliche Hilfsdaten, die Unterschiede zwischen zwei biometrischen Messungen ausgleichen, ohne das Biomerkmal zu verratencrypto.stackexchange.com). Solche Mechanismen könnten wir etwa einsetzen, um sicherzustellen, dass leichte Tagesform-Schwankungen im Tippverhalten nicht gleich als komplett neue Identität gewertet werden.

 OpenID Connect & klassische IAM: Im Vergleich zu standardmäßigen zentralen Identitätslösungen (Login via Facebook, SAML in Unternehmen etc.) ist unser System dezentral und selbstverwaltet. Das heißt, es gibt keinen „Reset-Button“ durch einen Admin – was Vor- und Nachteil zugleich ist. Bestehende SSI-Projekte wie Hyperledger Indy/Aries oder Sovrin implementieren dezentrale Identitäten mit fixen Schlüsseln. Dort müssen Benutzer allerdings immer noch gut auf ihren einen Schlüssel achten (oft in Wallet-Apps verwahrt, mit Seed-Phrase-Backup). Unser Ansatz könnte solche Systeme ergänzen, indem er die Schlüsselpflege automatisiert: Die „Wallet“ füllt sich von selbst mit neuen Schlüsseln, solange der Nutzer aktiv ist, und benötigt weniger manuelles Backup (im Idealfall). Es gibt auch das Konzept DID Rotation Policies in einigen SSI-Protokollen, was wir mit Leben füllen könnten. 

Krypto-Wallets mit MPC: Einige moderne Crypto-Wallets (z. B. ZenGo, Fireblocks für Unternehmen) verzichten auf einen einzelnen Private Key und nutzen stattdessen Threshold Signatures/MPC: Der Schlüssel ist verteilt auf Handy und Server, keiner allein kann Transaktionen signieren. Das erhöht Sicherheit bei Verlust und vereinfacht Recovery. Unser System könnte sich inspirieren lassen und z. B. im Hintergrund auch einen verteilten Mechanismus fahren: ein Teil des Schlüssels wird aus Verhalten generiert, ein anderer Teil aus einer Hardwarequelle. Somit hätte man eine Zwei-Faktor-Kryptoschlüssel: Faktor „Wissen/Sein“ (Verhalten) + Faktor „Haben“ (Gerät). Einige Forschungsprojekte gehen auch in Richtung Verteilen der Biometrie – z. B. Fingerabdruck wird nicht komplett am Handy geprüft, sondern in Teile zerlegt und verteilt geprüft, damit kein einzelner Punkt das ganze Abdruckbild sieht. Übertragen auf uns: Man könnte sich Szenarien vorstellen, wo mehrere unabhängige Instanzen Teile des Verhaltens bewerten (eine Cloud-KI analysiert nur die Timing-Abstände in verschlüsselter Form, das Gerät analysiert die Druckstärke, etc.) – wobei das sehr komplex wird und vermutlich overkill ist.

Zusammenfassend lässt sich sagen: Kein derzeit bekanntes System kombiniert alle Aspekte (Behavioral Entropy + lokale Schlüssel + Blockchain-DID) genau so, was unserem Ansatz einen Innovationsvorsprung verleiht. Dennoch stützen wir uns auf Bausteine, die sich bereits bewährt haben: Dezentralisierte Identität (DID/VC) wird aktiv standardisiert, verhaltensbasierte Authentifizierung wird in Teilbereichen schon genutzt, und Kryptoverfahren wie BLAKE3, Ed25519, ZKPs haben sich als state-of-the-art herausgestellt.

Alleinstellungsmerkmale des beschriebenen Systems

Nachdem wir nun die verschiedenen Facetten beleuchtet haben, stellt sich die Frage: Was macht dieses verhaltensbasierte Identitätssystem einzigartig? Hier einige Kernpunkte, die in Kombination das Alleinstellungsmerkmal ausmachen:

• Kontinuierliche Identitätsbildung: Anders als klassische Authentifizierung (Momentaufnahmen wie Login-Passwort-Eingabe oder einmaliger Biometrics-Scan) schafft unser System eine fließende Identität, die sich dynamisch aus dem Nutzungsverhalten speist. Das heißt, Identität ist nicht mehr ein statischer Schlüssel oder Token, sondern ein lebendiger Stream. Diese „Living ID“ erschwert es Angreifern enorm, den richtigen Moment zum Angriff abzupassen oder gültige Credentials zu stehlen, da sich diese laufend verändern.
• Verbindung von Mensch und Schlüssel: Das System verknüpft auf elegante Weise die physische Einzigartigkeit des Menschen (sein Verhalten) mit der kryptografischen Einzigartigkeit des Schlüssels. In traditionellen Systemen hat ein privater Schlüssel keine innere Bindung an die Person – wenn jemand ihn kopiert, kann er die Person imitieren. Bei uns würde ein kopierter Schlüssel alleine wenig nützen, weil er ohne den ständigen Nachschub an richtiger Entropie schnell „erkaltet“. Praktisch heißt das: Die Identität ist an den Benutzer als Akteur gebunden, nicht nur an ein Stück Daten.
• Maximale Lokalität und Privatsphäre: Im Vergleich zu biometrischen ID-Lösungen (Fingerabdruck-Pass, biometrische Datenbank für Ausweise) besticht unser Ansatz dadurch, dass sämtliche Rohdaten lokal bleiben und sofort in abstrakte Entropie umgewandelt werden. Es gibt keine persistenten persönlichen Daten, die irgendwo abgerufen werden könnten. Selbst die Blockchain sieht nur Pseudonyme und mathematische Beweise, aber keine Klartext-Aktionen. Damit vereinen wir Selbstsouveränität mit Datenschutz-by-Design.
• Keine Spezialhardware nötig: Alles was man braucht, ist bereits vorhanden – ein Computer oder Smartphone mit den üblichen Eingabegeräten. Natürlich kann man zusätzlich Hardware-Token einbinden, aber man muss nicht warten, bis alle Welt neue Geräte kauft (im Gegensatz etwa zu Worldcoin Orb oder Smartcard-Lesern). Das senkt die Zugangshürde drastisch. Theoretisch könnte jeder Online-Dienst so ein System integrieren, indem er nur Software ausrollt. Für die Nutzer besteht kein Unterschied in der Interaktion (sie nutzen Maus/Tastatur wie eh und je), außer dass Passwörter wegfallen.
• Resilienz durch Dynamik: Das System ist fehlertolerant und anpassungsfähig. Sollte ein Teilkompromiss stattfinden (z. B. ein Key wird bekannt), kann durch schnelles Rotieren und den nächsten Entropie-Schub ein neuer Key generiert werden – der alte wird verworfen und Angreifer schauen in die Röhre. Auch wenn sich der Nutzer ändert (neuer Laptop mit anderer Tastatur, oder jemand erholt sich von einer Handverletzung und tippt anders): Durch Machine-Learning-Komponenten könnte das System sich an veränderte Muster adaptieren und dennoch kontinuierliche Identität wahren. Kein statisches Passwort- oder Schlüsselsystem hat diese Plastizität.
• Vielseitige Einsetzbarkeit: Einmal eingerichtet, kann dieselbe verhaltensbasierte Identität viele Zwecke erfüllen: Login bei Websites, Zugang zu physischen Türen, Signieren von Blockchain-Transaktionen, Unterzeichnen von Dokumenten (digitale Signatur), Nachweis von Berechtigungen etc. Es wäre quasi eine universelle, aber doch anonyme ID. Andere Systeme fokussieren oft nur auf einen Bereich (z. B. FIDO für Web-Login, oder Government IDs für hoheitliche Zwecke). Unser System, gerade in Verbindung mit DIDs/VCs, könnte vom Behördeneinsatz (z. B. als Ergänzung zu elektronischen Personalausweisen) bis zur Gaming-Plattform (Anti-Cheat-Identität) alles abdecken – natürlich jeweils angepasst.
• Schutz vor Missbrauch und Sybil-Angriffen: In Online-Communities und gerade im Web3 ist ein großes Problem, dass ein einzelner Akteur leicht viele Fake-Identitäten erzeugen kann (Sybil-Angriff). Unsere Lösung erschwert das massiv, da jede Identität eine echte menschliche Präsenz und Einzigartigkeit erfordert, die nicht beliebig klonbar ist. Wer 1000 Identitäten haben will, müsste 1000 Geräte mit 1000 verschiedenen echten Nutzungsverhalten betreiben – praktisch unmöglich. Damit könnten z. B. Online-Abstimmungen oder Token-Drops fairer gestaltet werden (jede Person wirklich nur einmal), ohne in die Privatsphäre der Teilnehmer einzudringen.

Zusammengefasst vereint das System die Sicherheit von Public-Key-Kryptografie, die Personengebundenheit biometrischer Merkmale und die Dezentralität der Blockchain in einem einzigen Framework. Dieser Dreiklang ist neuartig. Natürlich gibt es auch Herausforderungen und offene Punkte, auf die wir zum Schluss eingehen.

Anwendungsfälle

Wo könnte ein solches System konkret eingesetzt werden? Einige realistische Anwendungsfälle zeigen das Potenzial:

• Web3-Identität & Wallet: Stellen wir uns eine Kryptowallet vor, die keine feste Seed-Phrase hat, sondern sich aus dem Benutzerverhalten speist. Der Nutzer installiert die Wallet-App, sie generiert laufend Schlüssel während der Nutzung. Zum Senden einer Transaktion muss der Nutzer vielleicht einfach kurz sein übliches Entsperrmuster eingeben oder ein paar Zeichen tippen – die Wallet prüft im Hintergrund die Verhaltens-ID, signiert die Transaktion mit dem aktuellen Schlüssel und sendet sie ab. Sollte jemand anders das Gerät bedienen, würde die Wallet entweder gar nicht erst entsperren oder eine Warnung geben („Ungewöhnliches Verhalten erkannt, bitte zusätzliche Verifikation.“). So eine Wallet wäre benutzerfreundlich (kein Passwort, keine Seed-Aufschreibung nötig im Alltag) und gleichzeitig sicher, da ein Dieb mit dem Gerät alleine wenig anfangen kann. Auch DAO-Governance könnte profitieren: Abstimmungen könnten auf „eine Stimme pro verhaltensbasierter ID“ beschränkt sein, was weitgehend „eine Person, eine Stimme“ entspricht, ohne Klardaten der Personen zu kennen.
• Offline-Zutrittskontrollen und IoT: In Gebäuden, Fahrzeugen oder anderen Zugangsbereichen, wo vielleicht nicht jederzeit Internet verfügbar ist, könnte das System als Offline-Ausweis dienen. Beispielsweise in einem Forschungslabor bekommt jeder Mitarbeiter eine verhaltensbasierte ID auf dem Firmen-Laptop. Die Labortür hat einen Scanner, der über NFC/Bluetooth eine Challenge ans Laptop sendet, das Laptop signiert via verhaltensgeneriertem Key, und die Tür öffnet. Das alles kann offline passieren, wenn die Tür die Public Keys vorher in einem sicheren Speicher hat (oder sie regelmäßig aus der Blockchain aktualisiert). Ebenso könnte man sich ein Schloss vorstellen, das per USB oder Bluetooth an einen Laptop gekoppelt ist und nur öffnet, wenn eine gültige verhaltensbasierte Signatur kommt. Für die Automobilbranche: Ein Auto, das den Fahrer am Fahrverhalten erkennt – es startet nur, wenn Lenk- und Pedalbedienung in den ersten Sekunden dem hinterlegten Muster entsprechen (zugegebenermaßen risky, aber denkbar als Diebstahlschutz).
• Continuous Authentication in Hochsicherheit: In sensiblen Bereichen wie militärischen Systemen oder kritischer Infrastruktur möchte man vielleicht nicht nur beim Login prüfen, sondern laufend sicherstellen, dass der Bediener noch der gleiche ist und nicht während der Session jemand unberechtigt das Terminal übernommen hat. Hier kann unser System helfen, unaufdringlich im Hintergrund die Session abzusichern. Wenn z. B. in einem Kontrollraum auffällt, dass gerade jemand ganz anders zu tippen scheint, könnte sich das System sperren oder einen zweiten Faktor verlangen. Das kann Insider-Angriffe oder Coercion (wenn jemand gezwungen wird, etwas zu tun) erschweren. Auch im Home-Office-Kontext: Vielleicht lässt sich so erkennen, ob tatsächlich der Mitarbeiter selbst die Tastatur bedient oder ob jemand anders heimlich am Rechner sitzt.
• Passwortlose Logins & zk-Profiling: Dienste könnten unseren Ansatz einsetzen, um Nutzern logins zu ermöglichen, ohne dass diese je ein Passwort setzen. Man registriert sich einfach, indem man die Software laufen lässt und genug Entropie sammelt – fertig. Später geht man auf die Seite, klickt „Login mit BehaviorID“, das Gerät signiert eine Challenge und man ist drin. Zusätzlich könnte man Zero-Knowledge nutzen, um dem Dienst gewisse Attribute zu beweisen: z. B. könnte aus dem Verhalten abgeleitet werden, dass man vermutlich kein Bot ist (dafür gibt es Charakteristika), was man als ZKP verpackt übermittelt – somit wäre CAPTCHA gelöst, ohne Bilderrätsel. Oder man beweist anhand seiner verhaltensbasierten DID, dass man schon woanders verifiziert wurde (Verifiable Credentials können z. B. ein Altersnachweis sein, signiert vom Staat, aber vorgelegt via unserer DID). WebAuthn und Passkeys gehen schon in die Richtung, aber sie kennen eben den Faktor Verhalten nicht.
• Gaming und Metaverse: In Online-Spielen könnte man verhaltensbasierte IDs nutzen, um Cheating oder Multi-Accounting vorzubeugen. Jeder echte Spieler hat einen gewissen Gameplay-Stil – Bots weichen davon ab. Wenn man bestimmte Dynamiken des Spielverhaltens in die Identitätsbildung einfließen lässt, kann man es Bots schwer machen, menschliche Spieler zu imitieren. Außerdem könnten verhaltensbasierte IDs helfen, soziale Reputation aufzubauen, ohne Klarnamen: Zum Beispiel könnten Foren oder VR-Communities verlangen, dass jede Identität an eine menschliche Verhaltens-ID gebunden ist (um Sockenpuppen zu reduzieren). Gleichzeitig bleibt der User anonym, solange er möchte.
• Healthcare und persönliche Daten: In sensiblen Bereichen wie Gesundheitsdaten könnte ein verhaltensbasierter Schlüssel den Zugriff schützen. Nur wenn der Patient persönlich anwesend ist (erkennbar am Interaktionsmuster auf einem Tablet) werden seine Patientendaten entschlüsselt. Sobald jemand anderes das Gerät übernimmt oder die Interaktion abbricht, sind die Daten verschlüsselt. Dies könnte in Telemedizin-Anwendungen relevant sein, wo man sicherstellen will, dass wirklich der Patient gerade seine Akte einliest und nicht ein Familienmitglied ohne Zustimmung.

Nicht jeder dieser Anwendungsfälle ist sofort ohne Weiteres umsetzbar; manche erfordern weitere Forschung oder gesellschaftliche Akzeptanz. Aber sie zeigen die Bandbreite dessen, was möglich wird, wenn man Verhalten als Sicherheitsfaktor ernst nimmt und geschickt mit Kryptographie kombiniert.

Herausforderungen, offene Fragen und mögliche Weiterentwicklungen

Natürlich bringt ein so ambitioniertes System etliche Herausforderungen mit sich. Zum Abschluss wollen wir ehrlich beleuchten, wo noch Arbeit nötig ist und welche Fragen offen sind:

• Verlässlichkeit und False Rejects: Eine große praktische Frage ist: Wie stabil ist die Identität bei legitimen Nutzern über Zeit? Menschen sind keine Maschinen – unsere Tippweise kann sich ändern, wir benutzen mal eine andere Tastatur, sind müde oder gestresst, was unseren Rhythmus beeinflusst. Das System muss also genügend Toleranz haben, um denselben Nutzer trotz Variation wiederzuerkennen, aber dennoch sensibel genug, um einen anderen Nutzer abzulehnen. Dieses Abgrenzungsproblem ist klassisch in Biometrie. Lösungen könnten sein, mit probabilistischen Modellen zu arbeiten, die eine Vertrauensmetrik ausgeben, statt binär zu entscheiden. Vielleicht hat man einen Score, der sagt „90% Wahrscheinlichkeit, dass es derselbe Nutzer ist“. Man müsste Grenzwerte definieren, ab wann eine Re-Auth erforderlich ist. Machine Learning könnte helfen, ein Modell des Nutzers zu trainieren, das leichte Veränderungen zulässt (z. B. Tippstil an mechanischer vs. Laptop-Tastatur differenziert). Die Balance zwischen False Reject (echter Nutzer wird fälschlich nicht erkannt) und False Accept (Falscher wird akzeptiert) muss sehr gut kalibriert werden, sonst frustriert das System oder unterläuft seine Sicherheit.
• Erstinitialisierung und Trainingsphase: Gerade am Anfang, wenn das System noch wenig Daten vom Nutzer hat, ist es anfällig. Man könnte festlegen, dass in den ersten x Minuten/Stunden andere Faktoren (wie ein einfacher Passwortlogin oder Code) parallel genutzt werden, bis genügend Entropie gesammelt wurde. Vielleicht muss der Nutzer initial einen gewissen „Trainingsparcours“ absolvieren – was der Nutzererfahrung abträglich sein kann. Hier könnte Gamification helfen (eine Tipp-Spiel-App zum Start, die zugleich die Entropiesammlung durchführt). Wichtig ist aber: Die Onboarding-Experience darf nicht zu komplex sein, sonst schreckt es ab.
• Angriff mit KI und Generative Bots: In Zeiten von immer besserer KI drängt sich die Frage auf: Könnte eine KI mein Verhalten imitieren? Wenn man genug Daten von jemandem hat, könnte man theoretisch einen Bot trainieren, Tipp- und Mausmuster nachzuahmen. Zwar ist das sehr schwierig (vor allem in Echtzeit und adaptiv auf wechselnde Anforderungen), aber nicht völlig ausgeschlossen in Zukunft. Dem könnte man entgegnen, indem man verhaltensbasierte ID mit physischen Faktoren koppelt, die schwerer simulierbar sind – z. B. Leichte unbewusste Handzittrigkeit, die ein Bot nicht direkt hat, oder den Druck beim Tippen (der erfordert haptische Sensoren). Ein anderes Mittel ist Diversität der Inputs: das System könnte zusätzliche Modalitäten reinnehmen – z. B. den Schreibstil (Wortwahl, Satzbau als Art linguistischer Fingerabdruck). Eine KI mag mechanische Aktionen faken können, aber ob sie genau den gleichen spontanen Sprachstil hat, ist nochmal schwieriger. Kombiniert man mehrere dieser Aspekte (multimodale Verhaltens-Biometrics), erhöht das die Sicherheit. Auf der anderen Seite erhöht es auch den Datenschutzimpact – man muss also austarieren, welche und wie viele Verhaltensaspekte man nutzen will.
• Einordnung als Biometrie und Regulierung: Möglicherweise würde ein solches System rechtlich als biometrisches System angesehen (auch wenn es kein statisches Merkmal wie Fingerabdruck nutzt). Das hätte Implikationen im Datenschutzrecht (z. B. strenge Vorgaben nach DSGVO, eventuell Verbot in manchen Kontexten ohne Zustimmung). Hier müsste man argumentieren, dass es sich um verhaltensbezogene Biometrie handelt, die allerdings pseudonym und nur lokal verarbeitet wird. Dennoch: Eine offene Frage ist, wie Regulatoren das sehen und ob Nutzer dem trauen. Transparenz und freiwillige Nutzung sind hier Schlüssel. Für Unternehmen, die sowas einsetzen wollen, gilt es, frühzeitig Datenschutzexperten einzubeziehen.
• Interoperabilität und Standards: Damit unser System breite Anwendung findet, bräuchte es Standardisierungen – idealerweise in etablierten Gremien (W3C, FIDO, Decentralized Identity Foundation). Vielleicht ein DID Method speziell für behavioral keys, oder eine OpenID Extension dafür. Noch existiert das nicht. Pioniere werden möglicherweise proprietäre Lösungen basteln. Aber auf lange Sicht wäre z. B. ein DID:behavior Standard nützlich, oder Erweiterungen in WebAuthn, um Verhaltensdaten als Teil der Authenticator Assurance Levels zu berücksichtigen. Hier ist also nicht nur technische, sondern auch organisatorische Arbeit zu leisten.
• Usability und Akzeptanz: So technisch beeindruckend es ist, das System muss auch im Alltag bestehen. Nutzer könnten Bedenken haben („Überwacht mich mein Computer jetzt dauerhaft?“) – daher muss die Kommunikation klar sein: Es werden keine Inhalte aufgezeichnet, nur statistische Merkmale, und das dient deinem Schutz. Gleichzeitig sollte es so wenig wie möglich false positives geben, damit es nicht nervt („Schon wieder will das System, dass ich mich zusätzlich verifiziere, weil ich heute anders tippe“). Eine weitere Herausforderung: Wie erklärt man dem Nutzer das Konzept überhaupt? Viele verstehen schon Public/Private Key nicht; nun kommt noch dynamisches Verhalten dazu. Evtl. kann man es so abstrahieren: „Ihre Identität wird durch Ihre Nutzung verifiziert. Bleiben Sie einfach Sie selbst – das System kümmert sich um die Sicherheit im Hintergrund.“ Das wäre das Ideal: Sicherheit implizit, nicht explizit spürbar.
• Backup und Wiederherstellung: Was, wenn ich mein Gerät verliere oder es kaputt geht? Bei klassischen Wallets hat man seine 24-Wörter-Seedphrase. In unserem Modell hat man die gerade nicht, weil ja alles dynamisch war. Hier braucht es smarte Lösungen: Entweder man verbindet mehrere Geräte (die zusammen die ID bilden, sodass eines ausfallen kann), oder man hat im Onboarding einen einmaligen Recovery-Code, mit dem man im Notfall eine Identity Reset Proof erzeugen kann – z. B. in Kombination mit einem amtlichen Ausweis (man will ja nicht, dass Identitäten einfach gekapert werden, weil jemand sein Verhalten nicht mehr nachweisen kann). Social Recovery (Freunde bürgen) wäre auch eine Option. Dieses Thema ist knifflig, denn es darf nicht die Sicherheit konterkarieren. Vielleicht muss man in Kauf nehmen, dass ein verloren gegangenes Gerät = verlorene ID bedeutet in strengen Fällen (ähnlich wie man einen verlorenen physischen Ausweis neu beantragen muss, aber der alte dann ungültig ist). Dank der Blockchain könnte man zumindest nachvollziehen, dass ID ABC nach Datum X nicht mehr benutzt wurde oder als verloren markiert ist.
• Leistung und Energie: Permanent Daten sammeln und hashen kostet Ressourcen. Auf Desktop vermutlich kein Problem, auf mobilen Geräten muss man aufpassen, den Akku nicht leerzusaugen. BLAKE3 ist sehr effizient, aber wenn man es nonstop laufen lässt, merkt man das vielleicht. Hier sind Optimierungen gefragt: Ereignisbasiertes Hashen (nur hashen, wenn tatsächlich Eingaben passieren; Leerlauf = schlafen), adaptive Frequenz (bei intensiver Nutzung häufiger updaten, bei wenig Nutzung seltener). Ebenso muss die Datenhaltung effizient sein – ständig MB an Events puffern wäre schlecht. Zum Glück kann man Hashzustände auch inkrementell aktualisieren ohne alles vorzuhalten.
• Trust-On-First-Use Problem: Eine generelle Herausforderung in dezentralen Systemen: Woher weiß ein Dienst initial, ob eine verhaltensbasierte ID überhaupt legitim von einem Menschen angelegt wurde, und nicht von einem Bot? In Worldcoin übernimmt das der Orb (eine initiale starke Prüfung). Bei uns müsste evtl. eine initiale Prüfung oder Schranke sein, damit nicht jemand einfach 100 Instanzen in der Cloud startet und Mausbewegungen simuliert, um 100 DIDs zu registrieren. Mögliche Lösung: Man könnte für die Registrierung einer neuen ID einen einmaligen Captcha oder Video-Ident erfordern, je nach Sicherheitsbedarf. Oder man begrenzt neue IDs pro Zeit/Person via Social Attestations. Das ist noch offen. Alternativ vertraut man auf ökonomische Hürden (Angreifer mit 100 Cloud-VMs kann sicher nicht perfekt menschliches Verhalten generieren, zumindest wird das Detektionssystem hoffentlich viele davon als Bots entlarven). Hier wird man in der Praxis Kompromisse finden müssen.
• Weiterentwicklung mit KI: Die gleiche KI, die auf Angreiferseite bedrohlich ist, kann auf Verteidigerseite ein Segen sein: Machine-Learning-Modelle können immer bessere Muster erkennen, welche Kombination von Verhalten wirklich einzigartig ist. Zukünftig könnte unser System dazulernen, welche Merkmale es beim jeweiligen Nutzer stärker gewichten soll, um ihn sicher zu erkennen. Vielleicht lernt es auch typische Muster von Betrug (z. B. dass bei Replay-Angriffen geringfügige Timing-Abweichungen auftreten, die ein Mensch nicht hätte) und kann darauf reagieren. Eine weitere Vision: KI-Modelle für "Persona-Fingerprints" – man könnte eventuell aus dem Verhalten sogar ableiten, ob zwei verschiedene DIDs in Wirklichkeit dieselbe Person sind (was gegen Sybil hilft, aber zugleich die Anonymität mindern könnte). Da muss man vorsichtig sein, aber es zeigt, dass da viel Forschungsraum ist.

Zusammengefasst ist das verhaltensbasierte Identitätssystem ein spannender Aufbruch in eine neue Richtung, der aber sowohl technische Feinarbeit als auch interdisziplinäre Abstimmung (Recht, UX, Standardisierung) braucht. Viele Komponenten sind heute einzeln verfügbar, es gilt sie „nur“ richtig zu kombinieren und die offenen Punkte elegant zu lösen. Gelingt dies, hätten wir eine zukunftsweisende Identitätslösung: sicher, benutzerzentriert, dezentral und zugleich dynamisch an den Menschen gebunden. Eine solche Lösung könnte als Whitepaper konzipiert, weiter verprobt und in Pilotprojekten getestet werden – sie hätte durchaus das Zeug, in einem Pitchdeck für die nächste Generation der digitalen Identität prominent zu glänzen.

 Mit jedem Tastendruck und jeder Mausbewegung würden wir so nicht nur unseren Computer bedienen, sondern unsere eigene digitale Identität schmieden – fortlaufend, unnachahmlich und selbstbestimmt.

Quellen: Die in diesem Artikel genannten Fakten und Zitate wurden unter anderem folgenden Quellen entnommen: Biometric Update, Ping Identity Blog, Tripwire State of Security, W3C DID Core Specification, BLAKE3 GitHub Doku, InfoQ, TheServerSide, Opensource.com, NIST CSRC, Sui (BusinessWire) Pressemitteilung, Shield Labs zkLogin GitHub, Wikipedia zu Worldcoin, Cryptography StackExchange, u.a. (siehe Referenzen in

den eckigen Klammern im Text). 12                        1                                       14 18 17 26 30 33 15 43 28 27 47                                      2

1                13 What cryptographic key generation needs is a good source of entropy | Opensource.com

https://opensource.com/article/18/1/entropy

2                8                      9 10 Authentication Trends in 2024 and Beyond | Tripwire https://www.tripwire.com/state-of-security/authentication-trends

3                4                      5                      6                      7 What Is Behavioral Biometrics? How Is It Used?

https://www.pingidentity.com/en/resources/blog/post/behavioral-biometrics.html

10 11 Are mouse movement coordinates useful as a seed for a RNG?

https://crypto.stackexchange.com/questions/3347/are-mouse-movement-coordinates-useful-as-a-seed-for-a-rng

12 Use entropy as a service to bolster your security | TheServerSide https://www.theserverside.com/feature/Use-entropy-as-a-service-to-bolster-your-security 14 WebAuthn, Passwordless and FIDO2 Explained - Duo Blog | Duo Security https://duo.com/blog/webauthn-passwordless-fido2-explained-componens-passwordless-architecture

15 16 FIDO Devices - Future of Cybersecurity

https://cpl.thalesgroup.com/access-management/authenticators/fido-devices

17      Decentralized Identifiers (DIDs): The Ultimate Beginner's Guide 2025

https://www.dock.io/post/decentralized-identifiers

18      19 20 21 Decentralized Identifiers (DIDs) v1.0

https://www.w3.org/TR/did-core/

22 23 24 OpenID for Verifiable Credential Issuance - draft 15

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html

25                  Verifiable credentials mature with product launches, implementations | Biometric Update https://www.biometricupdate.com/202411/verifiable-credentials-mature-with-product-launches-implementations

26                  Zero-knowledge proof - Wikipedia

https://en.wikipedia.org/wiki/Zero-knowledge_proof

27                  41 GitHub - shield-labs/zklogin: Sign in with Apple/Google on any EVM chain. Self-custodial.

https://github.com/shield-labs-xyz/zklogin

28                  29 Sui Adds Login with Google and Twitch, Removes Major Barrier to Web3 Adoption https://www.businesswire.com/news/home/20230913187519/en/Sui-Adds-Login-with-Google-and-Twitch-Removes-MajorBarrier-to-Web3-Adoption

30 31 32 Multi-Party Threshold Cryptography | CSRC

https://csrc.nist.rip/Projects/threshold-cryptography

33 34 36 37 GitHub - BLAKE3-team/BLAKE3: the official Rust and C implementations of the BLAKE3 cryptographic hash function https://github.com/BLAKE3-team/BLAKE3

35 BLAKE3 Is an Extremely Fast, Parallel Cryptographic Hash - InfoQ https://www.infoq.com/news/2020/01/blake3-fast-crypto-hash/

38 39 40 42 Why Rust is Perfect for Cryptography & Security | by Ankita Singh | Apr, 2025 | Medium

https://medium.com/@aannkkiittaa/why-rust-is-perfect-for-cryptography-security-e7938832f16d

43 44 World (blockchain) - Wikipedia

https://en.wikipedia.org/wiki/World_(blockchain)

45 46 47 48 How is biometric data used to generate encryption keys? - Cryptography Stack Exchange

https://crypto.stackexchange.com/questions/58716/how-is-biometric-data-used-to-generate-encryption-keys