Vom DNS-Query zum verifizierten Datenaustausch – in Millisekunden.
Verimesh verändert die E-Mail-Infrastruktur grundlegend: Vertrauen wird nicht mehr vorausgesetzt, sondern nachgewiesen. Jeder Nachrichtenaustausch zwischen Organisationen löst die kryptografische Identität auf, stellt die Einwilligung nach Richtlinien fest und erzeugt einen Prüfpfad, ohne Mehraufwand im Arbeitsablauf und ohne die Arbeitsweise der Nutzenden zu ändern.
30-minütigen Architekturüberblick buchenHeutige Vertrauenssysteme zwingen Organisationen, sich für jede Identitätsprüfung und jeden Datenaustausch auf zentrale Stellen zu verlassen. Die Architektur von Vereign beseitigt diese Abhängigkeiten: Jede Organisation kontrolliert ihre eigene kryptografische Identität und verifiziert andere direkt. So funktioniert das in der Praxis, vom Schlüsselmanagement bis zum verifizierten Datenaustausch.
Was passiert, wenn Sie eine Nachricht senden
Die folgende Sequenz aus sieben Schritten ist der Weg, den jede Verimesh-fähige Nachricht nimmt: vom Moment, in dem Ihr DNS-Client eine Anfrage stellt, bis zu dem Moment, in dem die Daten verifiziert und auditiert am Ziel eintreffen.
Schritt 1: Der DNS-Proxy fängt die Anfrage ab
Wenn Ihre Anwendung die Domain einer Gegenpartei auflöst (z. B. spital-b.ch), fängt der Verimesh-DNS-Proxy die Anfrage ab, bevor sie Ihren Upstream-Resolver erreicht. Das ist der Einstiegspunkt: Änderungen am Anwendungscode sind nicht erforderlich. Der Proxy arbeitet transparent auf der Netzwerkebene.
Schritt 2: Der Identity Agent prüft den Status der Gegenpartei
Der Identity Agent fragt den über Verimesh veröffentlichten Identitätseintrag der Gegenpartei ab. Zwei mögliche Ergebnisse: Die Gegenpartei ist Verimesh-fähig (die vollständige kryptografische Verifizierung wird fortgesetzt), oder sie ist es nicht (Rückfall auf die Standardzustellung, die Nachricht wird als unverifiziert markiert). So erreicht Verimesh Abwärtskompatibilität: Nachrichten an Gegenparteien ohne Verimesh werden nie blockiert.
Schritt 3: Aufbau des WireGuard-Tunnels mit DKMS-abgeleiteten Schlüsseln
Ist die Gegenpartei Verimesh-fähig, wird ein WireGuard-VPN-Tunnel mit Schlüsseln aufgebaut, die aus den DKMS-Identitätseinträgen beider Organisationen abgeleitet werden. Diese Schlüssel stellt keine zentrale Zertifizierungsstelle aus; sie werden aus dem eigenen KERI Key Event Log jeder Organisation abgeleitet. Der Tunnel ist bilateral: Jede Partei authentifiziert sich unabhängig gegenüber der anderen.
Schritt 4: Die Policy Engine bewertet die Einwilligung
Bevor Daten fliessen, bewertet die Policy Engine von Verimesh (Open Policy Agent, OPA), ob dieser Datenaustausch nach den Richtlinien beider Parteien autorisiert ist. Bei Gesundheitsdaten prüft der FHIR-Resolver die Einwilligung auf Ressourcenebene: Patienteneinwilligungen, organisatorische Autorisierungen und sektorspezifische Vorschriften (EHDS, Schweizer DSG) werden in Echtzeit ausgewertet. Daten, die nicht durch Richtlinien autorisiert sind, fliessen nicht. Dieselbe Richtlinienprüfung deckt auch delegierte Befugnisse ab: Die empfangende Partei kann bestätigen, dass eine Person, eine Rolle oder ein Agent innerhalb der Berechtigungen handelt, die ihre Organisation erteilt hat, verifiziert anhand der eigenen Credential-Kette dieser Organisation statt eines zentralen Registers.
FHIR-over-Verimesh ist heute eine architektonische Integration: Der Produktiveinsatz hängt vom Onboarding der Spitäler ab, und der früheste realistische Termin liegt Ende 2026.
Lesen Sie, warum diese Architektur notwendig ist, nicht nur besser →
Schritt 5: Token werden lokal übersetzt
Ihre bestehenden OAuth-Token und X.509-Zertifikate bleiben gültig. Die Kompatibilitätsbrücke von Verimesh übersetzt KERI-verankerte Credentials auf der Empfangsseite in das JWT- oder X.509-Format: lokal, ohne eine externe Instanz zu kontaktieren. Ihre Identitätsinfrastruktur ändert sich nicht. Verimesh erweitert sie über Organisationsgrenzen hinweg.
Schritt 6: Datenaustausch über das verschlüsselte Mesh
Sobald die Einwilligung nach Richtlinien bestätigt und der verschlüsselte WireGuard-Tunnel aufgebaut ist, findet der Datenaustausch statt. SEAL (Secure Edge Application Layer) umhüllt jede Nachricht mit einer verifizierbaren Authentizitätsschicht: Die empfangende Organisation kann nachweisen, wer die Daten gesendet hat, wann sie gesendet wurden und dass sie unterwegs nicht verändert wurden. Damit entfällt die Abhängigkeit, die S/MIME von Zertifizierungsstellen Dritter hat; an ihre Stelle tritt die bilaterale, DKMS-abgeleitete Verifizierung.
Schritt 7: Prüfpfad in KEL/TEL aufgezeichnet
Jeder Austausch erzeugt einen Eintrag im Key Event Log (KEL) und im Transaction Event Log (TEL) von KERI. In diesen Logs wird jede nachträgliche Veränderung sichtbar, und jede Partei kann sie unabhängig verifizieren, nicht nur ein zentraler Log-Server. Für regulierte Sektoren bedeutet das organisationsübergreifende Prüfpfade, die kryptografisch fundiert und ohne zentralisierte Infrastruktur verfügbar sind. Ihr Compliance-Team kann jeden Austausch jederzeit unabhängig verifizieren.
Fünf Schichten der Vertrauensinfrastruktur
Der Vertrauens-Stack von Verimesh ist in Schichten aufgebaut. Jede Schicht erledigt eine Aufgabe gut und übergibt sauber an die nächste. Bestehende Infrastruktur dockt an der Kompatibilitätsschicht an; nichts wird herausgerissen.
Was bleibt. Was sich ändert.
Verimesh ist kein Ersatzprojekt, sondern eine Erweiterung der Infrastruktur, die Sie bereits betreiben. Die folgende Tabelle zeigt, was Sie behalten und was Verimesh hinzufügt.
443 DSGVO-Datenschutzverletzungen pro Tag in ganz Europa gemeldet, mit kumulierten Bussgeldern von über 1,2 Milliarden EUR (DLA Piper GDPR Fines and Data Breach Survey)
Was bleibt
- ✓OAuth 2.0 / OIDC: übernimmt weiterhin die interne Authentifizierung und die lokale Token-Ausstellung. Keine Änderungen erforderlich.
- ✓X.509-Zertifikate: bleiben gültig. Die KERI-zu-X.509-Brücke übersetzt an der Grenze, ohne Ihre PKI anzutasten.
- ✓JWT: Ihr Token-Format bleibt unverändert. Verimesh erzeugt KERI-verankerte verifizierbare Credentials, die auf der Empfangsseite in JWT übersetzt werden.
- ✓SMTP / DKIM / DMARC: E-Mail-Routing und Anti-Spam-Infrastruktur bleiben bestehen. SEAL ergänzt DKIM um eine verifizierbare Authentizitätsschicht, statt es zu ersetzen.
- ✓Bestehende Workflows: Die Nutzenden senden E-Mails wie bisher. Die Vertrauensverifizierung ist für sie unsichtbar.
Was sich ändert
- →Abhängigkeit von einer zentralen Zertifizierungsstelle: ersetzt durch bilaterale, DKMS-verankerte Schlüsselableitung. Kein Dritter kann Ihrer Organisation die Fähigkeit zur Kommunikation entziehen.
- →E-Mail nach dem Prinzip Trust-on-First-Use: ersetzt durch kryptografisch verifizierte Organisationsidentität bei jedem Austausch. Phishing und Identitätsmissbrauch in der Kommunikation von Organisationen werden strukturell verhindert.
- →Manuelle Einwilligungsworkflows: ersetzt durch Einwilligungsprüfung in der Policy Engine (OPA). Vereinbarungen zur Datenweitergabe sind maschinenlesbar und werden auf der Infrastrukturebene durchgesetzt.
- →Fragmentierte Prüfpfade: ersetzt durch kryptografisch verknüpfte KEL/TEL-Einträge, die über Organisationsgrenzen hinweg unabhängig verifizierbar sind.
Andere haben dezentrale Identität versucht. Was ist hier anders?
Das ist die richtige Frage. Drei gut finanzierte Projekte sind daran gescheitert, dezentrale Identität in grossem Massstab zu liefern:
- Sovrin: Der Sovrin Foundation ist 2023 das Betriebskapital ausgegangen. Ihre Hyperledger-Indy-Blockchain hat eine laufende Koordination der Validator-Nodes und eine finanzierte Stiftung für die Governance erfordert. Ohne eine sich selbst tragende Stiftung ist das Netzwerk zum Stillstand gekommen. Das Scheitern war nicht technisch, sondern eine Frage von Governance und Ökonomie: Die Blockchain-Abhängigkeit hat ein Koordinationsproblem geschaffen, das sich nur durch zentrales Management lösen liess.
- uPort: Das Identitätsprojekt von ConsenSys ist in Serto umbenannt worden und hat sich dann ganz aus dem Identitätsbereich zurückgezogen. uPort hat auf Ethereum aufgebaut, womit jede Identitätsoperation Gas-Gebühren und On-Chain-Transaktionslatenz mit sich gebracht hat. Identitätsmanagement im Produktionsmassstab, also Millionen von Ereignissen pro Tag, ist auf einer öffentlichen Blockchain wirtschaftlich nicht tragfähig.
- Jolocom: Hat sich von der Identitätsinfrastruktur abgewendet, nachdem die Verbreitung im Produktiveinsatz ausgeblieben ist. Das gemeinsame Muster des Scheiterns bei SSI-Projekten: Abhängigkeit von Blockchain-Infrastruktur, die wirtschaftlich nicht skalieren kann, oder eine Stiftungs-Governance, die sich nicht selbst tragen kann.
KERI ist strukturell anders. Es hat keine Blockchain-Abhängigkeit. Schlüsselereignisse werden in Append-only-Logs verankert, die jeder Controller unabhängig führt: kein gemeinsames Ledger, keine Gas-Gebühren, keine Stiftungs-Governance erforderlich. Das Netzwerk braucht keinen zentralen Koordinator, weil Vertrauen bilateral zwischen den Parteien aufgebaut wird, nicht über einen gemeinsamen globalen Zustand validiert.
Die institutionelle Validierung: GLEIF, die Global Legal Entity Identifier Foundation, betreibt das globale LEI-System für Finanzinstitute in 180 Ländern. GLEIF hat KERI für das vLEI-System (verifiable Legal Entity Identifier) gewählt. Das ist kein Proof of Concept, sondern Produktionsinfrastruktur, die weltweit die Identität von Finanzinstituten verifiziert. Verimesh (ehemals das Stargate-Projekt) baut auf demselben KERI-Fundament auf, das GLEIF im institutionellen Massstab validiert hat.
Möchten Sie wissen, wie das zu Ihrer Organisation passt?
Erfahren Sie, wie sich verifizierte Vertrauensinfrastruktur auf Ihre konkreten Anforderungen und Ihr regulatorisches Umfeld anwenden lässt.