Self-Sovereign Tunneling: Verwendung von DIDs zur Ersetzung zentralisierter Authentifizierungstokens
> Hören Sie auf, Drittanbieterdienste mit Ihren auth tokens zu vertrauen. Hier erfahren Sie, wie Self-Sovereign Identity (SSI) und Decentralized Identifiers (DIDs) eine neue Generation von Peer-to-Peer-Tunneln ermöglichen — bei denen Ihre Identitäts-Wallet die einzige “Login”-Möglichkeit ist.
Einführung: Der Wandel weg vom zentralisierten Tunneling
In den frühen 2020er Jahren dominierte eine Handvoll zentraler “Tunnel-as-a-Service”-Anbieter die Entwickler-Tools für die lokale bis öffentliche Exposition. ngrok, Cloudflare Tunnel und ihre Zeitgenossen wurden in Entwicklerkreisen bekannte Namen. Praktisch, ja. Aber architektonisch fehlerhaft in einem entscheidenden Punkt: Der Anbieter wurde zum Torwächter Ihrer Identität.
Um einen Tunnel zu öffnen, brauchte man ein Konto. Zur Authentifizierung wurde ein Bearer Token in einer .yml-Datei gespeichert. Wenn die Datenbank dieses Anbieters kompromittiert wurde — oder wenn Sie versehentlich Ihre Konfiguration in ein öffentliches Repository committen — war Ihr Zugangspunkt in der lokalen Umgebung offen.
Die Branche bewegt sich jetzt durch eine grundlegende Korrektur. Entwickler mieten ihre Identitäten nicht mehr bei Anbietern, sondern bringen ihre eigenen mit. Dies ist das Zeitalter der SSI-Tunnels — kryptografische Handshakes zwischen souveränen Entitäten, basierend auf Decentralized Identifiers (DIDs) und Peer-to-Peer-Netzwerken, ganz ohne Mittelsmann.
Was ist Self-Sovereign Identity?
Bevor wir uns speziell den Tunneln widmen, ist es hilfreich, die zugrunde liegende Basis zu verstehen.
Self-Sovereign Identity (SSI) ist ein Identitätsmanagement-Modell, das Einzelpersonen und Systeme vollständig im Besitz und unter Kontrolle ihrer digitalen Identitäten lässt, ohne auf eine zentrale Autorität angewiesen zu sein. Wie die Decentralized Identifiers (DIDs) v1.0 des W3C DID-Arbeitskreises festlegen, ist ein DID eine neue Art von weltweit eindeutiger Kennung, die verifizierbare, dezentrale digitale Identität ermöglicht — die vom Eigentümer, nicht von einer Firma oder Regierung kontrolliert wird.
Die SSI-Architektur basiert auf drei Teilnehmern:
- Inhaber — die Entität (Person, Server oder Gerät), die eine DID erstellt und kontrolliert, sowie Verifiable Credentials erhält.
- Aussteller — die Behörde, die kryptografisch signierte Verifiable Credentials über den Inhaber ausstellt.
- Prüfer — die Partei, die die Credentials überprüft, ohne direkt Kontakt zum Aussteller aufnehmen zu müssen.
Dieses “Trust-Dreieck” bildet die Grundlage für alles, von digitalen Diplomen und Gesundheitsakten bis hin zu Authentifizierungsprozessen in Entwickler-Tools.
Der SSI-Markt spiegelt diesen Schwung wider. Laut aktuellen Prognosen wird der globale SSI-Markt von etwa 3,49 Milliarden USD im Jahr 2025 auf erstaunliche 1,15 Billionen USD bis 2034 wachsen, mit einer durchschnittlichen jährlichen Wachstumsrate von über 90 %. Ob diese Prognose genau ist oder nicht, das Signal ist eindeutig: Dezentrale Identität wird zur Infrastruktur.
Was ist ein SSI-Tunnel?
Ein SSI-Tunnel ist eine sichere, verschlüsselte Netzwerkbrücke zwischen zwei Endpunkten — typischerweise einem Entwickler-Computer und einem entfernten Client — bei der die Authentifizierung ausschließlich über SSI-Protokolle erfolgt.
Im Gegensatz zu traditionellen Tunneln, die auf einen zentralen Relay-Server zur Validierung eines API-Schlüssels angewiesen sind, verwendet ein SSI-Tunnel einen Decentralized Identifier (DID), um den Besitz eines Endpunkts nachzuweisen. Es gibt kein Konto zu erstellen, kein Token zu speichern und keine Anbieter-Datenbank, die kompromittiert werden könnte.
Kernkomponenten
DIDs (Decentralized Identifiers) Ein W3C-Standard für eine neue Klasse von Identifikatoren, die verifizierbare, selbstsouveräne digitale Identität ermöglichen. Jeder DID löst sich in ein DID-Dokument auf, das die öffentlichen Schlüssel für die Verifikation enthält.
Die Identitäts-Wallet Eine CLI oder Anwendung, die Ihre privaten Schlüssel hält und Authentifizierungsherausforderungen signiert. Stellen Sie es sich als Ihren Hardware-Sicherheitsschlüssel vor, aber für das offene Internet.
KERI (Key Event Receipt Infrastructure) Von Samuel M. Smith vorgeschlagen und in arXiv:1907.02143 dokumentiert, bietet KERI ein ledger-freies Protokoll zur Verwaltung von Schlüsselrotationen und zum Aufbau eines “Root of Trust” ohne eine Blockchain für jedes Authentifizierungsereignis. KERI führt Autonomic Identifiers (AIDs) ein — selbstzertifizierende Identifikatoren, die bei der Inception an kryptografische Schlüsselpaar gebunden sind, mit einem nur anhängenden, hash-kettenden Key Event Log (KEL), das jeder Peer unabhängig verifizieren kann.
libp2p (P2P-Transport) Der zugrunde liegende Netzwerkstack, ursprünglich für IPFS entwickelt und heute weit verbreitet im dezentralen Ökosystem. Es handhabt NAT-Traversal (“Hole Punching”), um zwei Maschinen hinter Firewalls direkt zu verbinden, ohne Traffic durch einen Relay-Server zu leiten.
Das Ende des Auth-Tokens
Seit Jahren war der ngrok-auth-token eine bekannte Zielscheibe für Angreifer. Eine falsch konfigurierte CI/CD-Pipeline, eine versehentlich commitete .env-Datei oder ein Datenbankeinbruch des Anbieters — und Ihre lokale Entwicklungsumgebung wurde zur offenen Tür in Ihr internes Netzwerk.
In einem SSI-Tunnel gibt es kein persistentes Auth-Token. Die Verbindung folgt einem Zero-Trust-Workflow:
- Anfrage — Ein Client versucht, sich mit Ihrer Tunnel-Adresse zu verbinden.
- Herausforderung — Die Tunnel-Software gibt eine kryptografische Herausforderung (Nonce) aus.
- Signatur — Sie “loggen sich ein”, indem Sie diese Herausforderung mit Ihrer Identity Wallets privatem Schlüssel signieren.
- Verifikation — Der Client überprüft die Signatur anhand Ihres öffentlichen DID-Dokuments, das über ein DHT oder eine Blockchain wie Polygon oder Cheqd aufgelöst wird.
Kein Passwort. Keine Anbieter-Datenbank. Kein zentraler Ausfallpunkt.
Der technische Stack im Detail
Der Aufbau eines Tunnels ohne zentralen Anbieter erfordert die Lösung zweier grundlegender Probleme: Identität und Konnektivität.
Die Identitätsschicht: DIDs und KERI
Die Branche bewegt sich weg von “ledger-lastigen” Identitätssystemen für Netzwerkaufgaben. Frühe SSI-Implementierungen schrieben jede Schlüsseländerung auf eine Blockchain — teuer, langsam und betrieblich fragil. KERI bietet eine praktischere Alternative.
Mit KERI generiert Ihre CLI beim Start eines Tunnels ein Key Event Log (KEL). Dieses Log ist eine hash-kettierte Sequenz von Ereignissen — Inception, Rotation, Interaktion —, die an kein externes Ledger gebunden ist. Da das Log end-verifizierbar ist, kann jeder Peer Ihre Identität durch das Abspielen des Logs bestätigen. Kein Identity Provider (IdP) notwendig. Kein Netzwerkaufruf zu einem Blockchain-Knoten erforderlich.
Die reale SSI-Infrastruktur entwickelt sich in Richtung dieses Modells. Projekte wie Hyperledger Indy (unter der Linux Foundation), die Sovrin Foundation und die European Blockchain Services Infrastructure (EBSI) setzen aktiv verifizierbare Credentials-Systeme im großen Maßstab ein — und bieten die bewährte Grundlage, auf der SSI-Tunnels aufbauen können.
Die Verbindungsschicht: libp2p und Hole Punching
Ohne einen zentralen Relay, wie finden zwei Computer hinter unterschiedlichen Firewalls und NAT-Schichten einander?
SSI-Tunnels verwenden dezentrale Peer-Discovery, basierend auf Kademlia-basierten Distributed Hash Tables (DHTs). Ihr Tunnel meldet seine DID im DHT an. Wenn ein Client eine Verbindung herstellen möchte, sucht er den DID, ruft die neueste “multiaddress” ab (eine strukturierte Kombination aus IP, Port und Protokoll) und initiiert einen STUN/TURN-Handshake, um das NAT zu durchdringen — und eine direkte Verbindung herzustellen, ohne Traffic durch einen Drittanbieter-Server zu leiten.
Vergleich der Ansätze
| Feature | Zentrale Tunnel (Legacy) | SSI-Tunnel |
|---|---|---|
| Authentifizierung | Bearer Token / OAuth | DID Signatur / Wallet |
| Vertrauensmodell | Vertrauen in den Anbieter | Vertrauen in die Kryptografie |
| Datenpfad | Über Relay-Server | Peer-to-Peer (Direkt) |
| Logging | Anbieter-seitig (undurchsichtig) | Forensische KERI-Logs (verifizierbar) |
| Fehlerquelle | Datenbank des Anbieters | Keine (kein zentraler Speicher) |
| Kosten | Monatliches Abonnement | Infrastrukturfrei / Open Source |
Warum Regulierungsdruck diesen Wandel vorantreibt
Mehrere convergierende Kräfte — nicht nur Sicherheitspräferenzen — machen DID-authentifizierte Tunnel zunehmend notwendig, insbesondere in regulierten Branchen.
eIDAS 2.0 und die europäische digitale Identitäts-Wallet
Die überarbeitete eIDAS-Verordnung der EU (Verordnung EU 2024⁄1183), die am 20. Mai 2024 in Kraft trat, schreibt vor, dass jeder EU-Mitgliedstaat mindestens eine EU Digitale Identitäts-Wallet (EUDI Wallet) bis Dezember 2026 für Bürger und Einwohner bereitstellen muss. Diese Wallet muss Verifiable Credentials, selektive Offenlegung von Attributen und kryptografisch verifizierbare Prüfpfade unterstützen.
Für Entwickler im FinTech-, MedTech- oder anderen regulierten EU-Kontexten ist dies keine Wunschvorstellung — es ist eine rechtliche Frist. Organisationen im Finanzdienstleistungs-, Gesundheits-, Telekommunikations- und digitalen Infrastrukturbereich müssen Wallet-basierte Authentifizierung akzeptieren und konforme Prüfpfade erstellen können. Drittanbieter-Relay-Tunnel, die unverschlüsselten oder undurchsichtigen Datenverkehr durch Server leiten, sind mit diesen Anforderungen grundsätzlich unvereinbar.
Die Kommission hat im November 2024 auch technische Standards für die grenzüberschreitende Interoperabilität von Wallets verabschiedet, die Entwicklern eine konkrete Spezifikation für den Aufbau bieten.
HIPAA und Datenkette der Verantwortlichkeit
In den USA konzentriert sich die aktualisierte HIPAA-Richtlinie zunehmend auf das Konzept der “Datenkette der Verantwortlichkeit” — die Fähigkeit, mit kryptografischer Sicherheit genau nachzuweisen, wer wann auf welche Daten zugegriffen hat und über welchen Kanal. Ein Drittanbieter-Tunnel, der Verbindungen undurchsichtig protokolliert, kann dies nicht leisten. Ein KERI-basiertes SSI-Tunnel, bei dem jedes Verbindungsereignis in ein unveränderliches Key Event Log signiert wird, schon.
Post-Quantum-Sicherheit: Eine reale und gegenwärtige Sorge
Traditionelle Authentifizierungstokens — und die RSA- oder ECDSA-Signaturen, die den meisten modernen TLS zugrunde liegen — sind anfällig für eine Angriffsklasse, die “harvest now, decrypt later” heißt, bei der ein Angreifer verschlüsselten Traffic heute speichert, um ihn zu entschlüsseln, sobald ein kryptografisch relevantes Quantencomputing verfügbar ist.
Dies ist kein theoretisches Zukunftsrisiko mehr. NIST hat im August 2024 seine ersten drei Post-Quantum Cryptography (PQC)-Standards finalisiert:
- FIPS 203 (ML-KEM, abgeleitet von CRYSTALS-Kyber) — für Schlüsselaustausch und Verschlüsselung.
- FIPS 204 (ML-DSA, abgeleitet von CRYSTALS-Dilithium) — der primäre Standard für quantenresistente digitale Signaturen.
- FIPS 205 (SLH-DSA, abgeleitet von SPHINCS+) — ein hash-basiertes Backup-Signaturverfahren.
Ein vierter Standard, FIPS 206 (FN-DSA, abgeleitet von FALCON), befindet sich in der Standardisierungsphase und ist für SSI-Tunnels besonders relevant: FALCON produziert kompakte Signaturen, die für Hochdurchsatz-Authentifizierungen geeignet sind — genau die Arbeitslast, die Tunnel-Handshakes darstellen.
Im März 2025 wählte NIST auch HQC als fünften Algorithmus, der eine zusätzliche code-basierte KEM als Backup zu ML-KEM bietet.
Moderne SSI-Tunnel-Implementierungen können PQC-Signaturen (ML-DSA oder FN-DSA) direkt im DID-Dokument integrieren, um sicherzustellen, dass Authentifizierungs-Handshakes gegen sowohl klassische als auch Quanten-Angreifer sicher bleiben. Dies ist eine Eigenschaft, die kein Bearer-Token-System bieten kann.
Die forensische Komponente: Audit-fähiges Netzwerk
Eine der wichtigsten betrieblichen Eigenschaften von SSI-Tunnels ist ihre inhärente Auditierbarkeit.
In einem providerbasierten Tunnelmodell vertrauen Sie darauf, dass die Logs des Anbieters korrekt sind — aber Sie können sie nicht unabhängig verifizieren. Der Anbieter kontrolliert das Log. Im SSI-Modell ist das Key Event Log (KEL) die Aufzeichnung. Es ist nur anhängend, hash-kettend und von jeder Partei, die das Log und den Inception-Key des DIDs besitzt, verifizierbar.
Für einen FinTech-Entwickler, der eine Produktionsdatenbank über eine Tunnel-Sitzung debuggt, bedeutet dies, dass Sie einem Compliance-Auditor — mit kryptografischem Nachweis — zeigen können, dass nur ein spezifischer, autorisierter DID während dieser Sitzung auf das System zugegriffen hat. Das Log ist kein nachträglich erstellter Bericht; es ist eine strukturelle Eigenschaft des Protokolls.
Dies entspricht direkt der Kategorie “Elektronische Attestierung von Attributen”, die neu im Rahmen von eIDAS 2.0 definiert wurde, wo Vertrauensdienste kryptografisch verifizierbare Aufzeichnungen von Interaktionen bereitstellen müssen.
Ein konzeptioneller Workflow
Während die spezifischen Produktionstools noch reifen, unterscheidet sich der Workflow für einen SSI-Tunnel grundlegend vom kontobasierten Modell:
Schritt 1: Initialisieren Sie Ihren DID
Anstelle von ngrok config add-authtoken <token> generieren Sie eine lokal kontrollierte Identität:
# Erstellen eines neuen KERI-basierten Autonomic Identifier (AID)
ssi-tunnel identity create --name "local-dev-node"
# Ausgabe: did:keri:Emkr4SGBXRoRPiWXW3GR7Q...
Schritt 2: Aufbau des Tunnels
Sie definieren, welcher lokale Port freigegeben wird, und binden ihn an Ihre DID:
# Starten eines P2P-Tunnels, gebunden an Ihre DID-Identität
ssi-tunnel share http://localhost:3000 --id did:keri:Emkr4SGBXRoRPiWXW3GR7Q...
# Tunnel aktiv bei: did:keri:Emkr4SGBXRoRPiWXW3GR7Q.tunnel
Schritt 3: Peer-Authentifizierung
Wenn ein Mitarbeiter oder Kunde eine Verbindung herstellen möchte, führt seine Umgebung keinen “einfachen” Zugriff auf die URL durch. Ihr Client führt einen DIDAuth-Handshake durch:
- Der Client sendet eine DIDAuth-Anfrage mit einer kryptografischen Herausforderung (Nonce).
- Ihr lokaler Rechner sendet eine Push-Bush-Nachricht an Ihre Identity Wallet.
- Sie genehmigen die Verbindung.
- Die signierte Antwort wird anhand Ihres öffentlichen DID-Dokuments verifiziert.
- Der P2P-Stream wird direkt hergestellt, ohne Routing durch einen Relay.
Der gesamte Austausch wird in das KEL auf beiden Seiten protokolliert.
Bestehende SSI-Infrastruktur: Was bereits vorhanden ist
Das Konzept des SSI-Tunnels basiert nicht auf Hypothesen. Es baut auf einer bereits eingesetzten Infrastruktur auf:
- Hyperledger Indy / Aries (Linux Foundation) — eine Blockchain-Implementierung speziell für dezentrale Identität, mit einem Agenten-Framework für Credential-Exchange. Wird weltweit von Regierungen und Unternehmen genutzt.
- Sovrin Network — eine Open-Source-SSI-Infrastruktur mit einem permissioned Ledger für Verifiable Credentials.
- EBSI (European Blockchain Services Infrastructure) — eine paneuropäische Initiative für digitale Diplome, grenzüberschreitende Identität und Regierungsdienste, die direkt eIDAS 2.0-konform ist.
- ID Union (Deutschland) — ein dezentrales Identitätsnetzwerk mit Banken, Universitäten und Behörden.
- MyData (Finnland) — ein bürgerkontrolliertes Framework für persönliche Daten, das in Produktion in öffentlichen und privaten Diensten läuft.
Dies sind keine Proof-of-Concepts. Es ist die Infrastruktur, auf der DID-authentifizierte Entwickler-Tools heute aufbauen können.
Grenzen und ehrliche Hinweise
Eine glaubwürdige Einschätzung erfordert, die noch reifende SSI-Tunnel-Technologie anzuerkennen:
Usability-Lücke. Das Management kryptografischer Schlüssel, DID-Dokumente und Wallets ist technisch anspruchsvoll. Der Wechsel verlagert die Verantwortung für die Sicherheit der Schlüssel auf Entwickler oder Nutzer — verlieren Sie Ihren privaten Schlüssel, ist die Wiederherstellung nicht trivial. Traditionelle Passwörter sind schlecht; verlorene Schlüssel sind schlimmer.
Fragmentierung der Interoperabilität. Es gibt mehrere DID-Methoden (did:web, did:key, did:keri, did:ion usw.), die nicht alle nahtlos zusammenarbeiten. Das Fehlen eines universellen Protokolls erschwert die Ökosystem-Integration.
Unreife Tooling. Produktionsreife SSI-Tunnel-Tools entwickeln sich noch. Entwickler, die heute dieses Muster übernehmen, sind Early Adopters, die auf Bibliotheken und Protokolle setzen, nicht auf fertige Produkte.
Skalierbarkeit von KERI-basierten Systemen. Während KERI Overhead durch Blockchain vermeidet, erfordert die hochfrequente Zeugen-Infrastruktur eine sorgfältige betriebliche Planung.
Digitale Chancengleichheit. SSI-Systeme setzen zuverlässigen Internetzugang, kompatible Geräte und ausreichende digitale Kompetenz voraus. Das ist eine echte Einschränkung, auch im Entwicklerkontext.
Was kommt als Nächstes
Der Trend ist klar, auch wenn der Zeitplan unsicher ist:
Browser-native DID-Unterstützung. Vorschläge im W3C zielen darauf ab, dass Browser DIDAuth-Handshakes nativ handhaben, was die Notwendigkeit separater CLI-Clients auf der Nutzerseite reduziert. Die eIDAS 2.0-Mandatierung für die Integration der EUDI Wallet in große Online-Plattformen bis 2027 wird dies beschleunigen.
Autonome Microservice-Identitäten. Server werden DIDs verwenden, um Verbindungen für Microservice-Kommunikation auszuhandeln, was zu einer “anbieterlosen” Infrastruktur führt.
Dezentrale Dienstentdeckung. Menschlich lesbare Namen, die DIDs über dezentrale Namensdienste (ENS, .did-Namespaces) zugeordnet sind, werden das aktuelle Subdomain-Modell ersetzen.
Post-Quantum-DID-Dokumente. Mit der zunehmenden Verbreitung von ML-DSA und FN-DSA nach NIST 2024 werden DID-Implementierungen standardmäßig Post-Quantum-Schlüsseltypen enthalten.
Fazit
Der Übergang zu SSI-Tunnels ist mehr als ein Sicherheits-Upgrade — es ist eine strukturelle Korrektur eines architektonischen Fehlers, der sich über ein Jahrzehnt erstreckte. Zentrale Anbieter haben sich als Identitäts-Torwächter eingeschlichen, nicht weil die Technologie es erforderte, sondern weil die Werkzeuge für eine andere Lösung noch nicht existierten. Diese Werkzeuge existieren jetzt oder werden schnell entwickelt.
Der W3C DID-Standard ist finalisiert. KERI ist spezifiziert und in aktiver Entwicklung. NIST hat die Standards für Post-Quantum-Kryptographie veröffentlicht. eIDAS 2.0 ist Gesetz. Die regulierten Branchen, die die wertvollsten Anwendungsfälle für Entwickler darstellen, nähern sich genau den Eigenschaften — verifizierbare Audit-Trails, souveräne Identität, kein zentraler Ausfallpunkt — die SSI-Tunnels von Natur aus bieten.
Ihr auth token war immer eine Schwachstelle. Ihre Identity Wallet ist ein kryptografischer Beweis. Der Unterschied ist bedeutend.
Weiterführende Literatur: W3C DID Core Specification · KERI Protocol Paper (arXiv:1907.02143) · NIST PQC Standards · eIDAS 2.0 Regulation (EU 2024⁄1183) · Hyperledger Indy · Sovrin Foundation
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.