Eine verifizierbare Identität für Ihre ganze Organisation.

Nicht nur das Unternehmen: jede Abteilung, jedes Gerät, jeder Dienst und jeder Agent, verifizierbar für Ihre Partnerinstitutionen, ohne gemeinsamen Anbieter dazwischen.

Diese Architektur für Ihre Organisation besprechen

Vier strukturelle Grenzen herkömmlicher Identitätswerkzeuge

OpenID Connect, OAuth und Public-Key-Infrastruktur (PKI) sind hervorragende Werkzeuge innerhalb der Grenzen einer einzelnen Organisation. Föderation hebt diese Grenze nicht auf, sie verschiebt sie: entweder in vorab verhandelte Vereinbarungen zwischen je zwei Organisationen oder in einen zentralen Vermittler, den keine von ihnen kontrolliert. Das ist kein Versagen, sondern eine architektonische Grenze, die sichtbar wird, sobald Vertrauen über Organisationen hinweg reichen muss.

Token-Vertrauen

Grenzen der Standardwerkzeuge

Zugriffstoken gelten innerhalb der Grenzen ihres Ausstellers als vertrauenswürdig. Zwischen Organisationen hält diese Grenze nicht: Die empfangende Organisation kann die Befugnis des Ausstellers nicht verifizieren.

Lösung mit DKMS / Verimesh

DKMS begründet eine kryptografische Identität, die sich selbst zertifiziert: Die Identität jeder Organisation ist für jede andere verifizierbar, ohne gemeinsame Zertifizierungsstelle.

Granularität der Zugriffsrechte

Grenzen der Standardwerkzeuge

Scopes sind grob und für Berechtigungen auf Anwendungsebene gedacht. Einwilligung über Organisationsgrenzen hinweg, auf Ebene des Ressourcengraphen, verlangt ein anderes Modell.

Lösung mit DKMS / Verimesh

Die Policy-Engine von Verimesh (Open Policy Agent, OPA) ermöglicht eine programmierbare, feingranulare Zugriffssteuerung, die über Vertrauensgrenzen von Organisationen hinweg funktioniert.

Prüfbarkeit

Grenzen der Standardwerkzeuge

Authentifizierungsprotokolle enden bei der Organisation, die sie schreibt. Organisationsübergreifende Prüfpfade (wer hat wann worauf zugegriffen, autorisiert durch wen) verlangen eine kryptografische Verknüpfung, für die lokale Authentifizierung nie gebaut worden ist.

Lösung mit DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) liefert Prüfpfade, in denen jede nachträgliche Veränderung sichtbar wird. Jedes Identitätsereignis ist kryptografisch verknüpft und unabhängig verifizierbar. So entsteht organisationsübergreifende Prüfbarkeit.

Vertrauensarchitektur

Grenzen der Standardwerkzeuge

Diese Modelle setzen eine zentrale Autorität voraus: einen Identitätsanbieter, dem alle vertrauen. Verteiltes institutionelles Vertrauen zwischen souveränen Organisationen kann von keiner einzelnen Autorität abhängen.

Lösung mit DKMS / Verimesh

DKMS ermöglicht eine souveräne Identitätsverwaltung: Jede Organisation kontrolliert ihre eigenen kryptografischen Wurzeln. Vertrauen entsteht bilateral, es wird nicht an eine zentrale Koordinationsstelle delegiert.

Identitätsanbieter behalten, Vertrauen zwischen Institutionen ergänzen

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organisational trust establishment
KERI-Identitätsinfrastruktur: selbstzertifizierende Identifikatoren, Key Event Receipts und bilaterales Vertrauen ohne zentrale Autorität

Das ist eine neue Fähigkeit. Ihr Identitätsanbieter und die Protokolle dahinter (OpenID Connect, OAuth, SAML) sind für die Authentifizierung innerhalb einer einzelnen Organisation bewährt und bleiben, wo sie sind. DKMS (Decentralized Key Management System) leistet das, wofür sie nie gebaut worden sind: Es gibt jeder Organisation eine selbstzertifizierende Identität, die jede andere Institution direkt verifizieren kann, ohne gemeinsamen Anbieter dazwischen. Verimesh liefert DKMS und spricht mit den Systemen, die Sie schon betreiben: Sie erweitern Ihren Bestand, statt ihn zu ersetzen.

Nationale E-ID-Programme als Grundlage

Das swiyu-Programm ist die schweizerische Bundesinfrastruktur für die elektronische Identität. Das erste Credential, der elektronische Lernfahrausweis, läuft seit Dezember 2025 in allen Kantonen, rund 27.000 sind ausgestellt. Die Inbetriebnahme der Vertrauensinfrastruktur für die E-ID ist für das erste Halbjahr 2027 vorgesehen, die Einführung der E-ID selbst ist verschoben worden, ein neuer Termin ist nicht bekannt. Aussteller-Identifikatoren und Vertrauensaussagen sind in zentralen Bundesregistern veröffentlicht, das Credential liegt auf dem eigenen Gerät der Bürgerinnen und Bürger. Öffnet sich die Infrastruktur für weitere Aussteller, soll sie auch Credentials von Kantonen, Hochschulen und Arbeitgebern tragen.

Vereign ist von Beginn an am Schweizer E-ID-Prozess beteiligt, über Partizipationsmeetings und bilaterale Gespräche, und Georg Greve war Mitglied des von fedpol einberufenen Technical Advisory Circle, dessen Beratung in die Technologieentscheidung vom Januar 2024 eingeflossen ist.

Die Europäische Union geht denselben Weg. Die Verordnung (EU) 2024/1183 verpflichtet jeden Mitgliedstaat, mindestens eine European Digital Identity (EUDI) Wallet bereitzustellen, und das grundlegende Personen-Credential kommt von staatlich benannten Anbietern. Beide Programme beantworten dieselbe Frage, und zwar gut: wie eine Person einer Institution nachweist, wer sie ist. Keines von beiden regelt die Identität der Abteilungen, Geräte, Dienste und Agents, die eine Organisation tatsächlich betreibt, und beide verankern Vertrauen in zentralen Registern. Deshalb führt keines ein Register der vertrauenden Parteien, die Credentials verifizieren: Auf Unionsebene wären es viel zu viele.

Für Organisationen, die Verimesh einsetzen, werden swiyu und EUDI zu Bausteinen. Die Brücke ist heute architektonisch angelegt, nicht ausgeliefert: Sobald diese Systeme im Produktivbetrieb sind, nehmen Sie beim Onboarding eine staatliche E-ID als Vertrauenswurzel an, und Verimesh trägt dieses Vertrauen über die Institutionen, Rechtsräume und Systeme eines realen Arbeitsablaufs hinweg, und stellt Ihre Credentials in dieselbe Wallet zurück.

Verimesh als Umsetzung dieser Architektur

Verimesh (früher das Stargate-Projekt) ist die produktive Umsetzung der oben beschriebenen Vertrauensarchitektur. Es arbeitet mit Ihrer bestehenden Authentifizierung und ergänzt das, wofür diese Schicht nie gebaut worden ist: eine in DKMS verankerte Organisationsidentität für Vertrauen zwischen Institutionen, eine programmierbare Policy-Engine (Open Policy Agent), gemeinsames Verständnis der Daten über die Overlays Capture Architecture (OCA) und manipulationserkennbare Nachrichtenzustellung über SEAL.

Verimesh ist im Schweizer Gesundheitswesen in Produktion: Gateway und zentrale CA bei HIN laufen produktiv, die ersten Institutionen sind migriert und nutzen sie, und die Migration im HIN-Netz soll vor Ende 2026 abgeschlossen sein.

Verimesh entdecken

Eine Organisationsidentität, bis hinunter zur Netzwerkebene.

Verimesh führt seinen Verkehr über WireGuard, und der Tunnelschlüssel ist in derselben Organisationsidentität verankert wie die Anwendungen darüber. Die Curve25519-Tunnelschlüssel jeder Organisation werden aus deren eigenem Material des Decentralized Key Management (DKMS) abgeleitet: Keine zentrale Autorität stellt sie aus, und zwischen Identität auf Netzwerk- und auf Anwendungsebene bleibt keine Lücke. Die Schlüsselrotation ist mit DKMS abgestimmt (Pre-Rotation, aufgebaut auf KERI), und jeder Tunnelaufbau ist gegen das Key Event Log prüfbar. Kein Intermediär besitzt den Datenfluss.

Stille als Grundprinzip

Nicht authentifizierte Pakete erhalten keine Antwort. Für einen Portscan ist das Mesh unsichtbar: keine öffentliche Angriffsfläche, die sich abtasten liesse.

Rund 4.000 Zeilen, die sich lesen lassen

WireGuard umfasst rund 4.000 Codezeilen, gegenüber etwa 100.000 bei OpenVPN und 400.000 bei IPsec. Prüfbarkeit ist selbst eine Sicherheitseigenschaft.

Keine Verhandlung, kein Downgrade

Feste, moderne Grundbausteine: Curve25519, ChaCha20-Poly1305, BLAKE2s und der Noise_IKpsk2-Handshake. Perfect Forward Secrecy mit Schlüsselwechsel etwa alle zwei Minuten und das Verbergen der Identität sind eingebaut, nicht konfiguriert.

Souverän bis auf die Leitung

Open Source von Anfang bis Ende, im Self-Hosting betrieben, ohne SaaS-Steuerebene im Datenpfad. Die Souveränität reicht von der Anwendung bis in den Transport selbst.

Langweilige, bewährte Infrastruktur

Seit 2020 im Mainline-Kernel von Linux. Nichts davon ist neuartige Kryptografie, und WireGuard trägt heute den Verimesh-Rollout mit HIN.

Bereit für die Quantenmigration

Die Pre-shared-Key-Schicht von WireGuard sichert den heutigen Verkehr bereits gegen Angriffe vom Typ «jetzt speichern, später entschlüsseln» ab. Und weil die Tunnelschlüssel aus DKMS abgeleitet werden, ist der Wechsel zu Post-Quanten-Algorithmen eine gewöhnliche Schlüsselrotation im bestehenden Key Event Log, keine Neuausstellung auf einen Schlag.

Den vollständigen Lebenszyklus einer Verbindung ansehen

Durchsetzung von Einwilligungen: der Zweck von DKMS

Artikel 71(8) EHDS schafft eine strukturelle Vorgabe, die keine zentrale Autorität erfüllen kann: Wenn eine Person ein Opt-out für die Sekundärnutzung erklärt, muss dieser Widerruf jede Institution erreichen, die Daten aus dem Original hält oder daraus ableitet. Keine Zertifizierungsstelle kann das Opt-out mitzeichnen, kein Identitätsanbieter kann die Sperrung kaskadieren. Diese Vorgabe ist mit zentralisierter Identität architektonisch unvereinbar.

DKMS erfüllt fünf Anforderungen, die Artikel 71 EHDS stellt: personengebundene Identifikatoren, die eine Neuregistrierung überdauern; verifizierbare, mit Zeitstempel versehene Opt-out-Einträge, verankert im Key Event Log; Umkehrbarkeit ohne erneute Identifizierung; Weitergabe über Verantwortliche hinweg ohne bilaterale Vereinbarungen zwischen jedem Institutionenpaar; und Unverknüpfbarkeit zwischen dem Einwilligungseintrag und den Daten, die er abdeckt.

Sind Daten bereits offengelegt, etwa in einem Spitalnetzwerk, einem Forschungskonsortium oder einer Kostenträgerkette, muss ein späteres Opt-out dennoch jeden nachgelagerten Verantwortlichen erreichen. Die Key Event Logs von DKMS geben die Sperrung kryptografisch weiter: Das KEL jedes Verantwortlichen lässt sich nur ergänzen und wird bezeugt, sodass eine am Rand der Person angefügte Sperrung bei jeder Institution verifizierbar wird, die einen abgeleiteten Datensatz hält.

These zur Einwilligungsarchitektur lesen

Im Schweizer Gesundheitswesen bewährt: ausgewählt für den landesweiten Einsatz

HIN (Health Info Net) ist das schweizerische Gesundheitsinformationsnetz, das Spitäler, Hausarztpraxen und Fachanbieter über Kantonsgrenzen hinweg verbindet. SEAL, das Einstiegsprodukt auf dieser Vertrauensschicht, trägt bereits über 800.000 verifizierte Zustellungen pro Monat. Verimesh ist im Schweizer Gesundheitswesen in Produktion: Gateway und zentrale CA bei HIN laufen produktiv, die ersten Institutionen sind migriert und nutzen sie, und die Migration im HIN-Netz soll vor Ende 2026 abgeschlossen sein.

HIN (Health Info Net)

800.000+

verifizierte Zustellungen pro Monat

Vertrauensarchitektur: Häufig gestellte Fragen

Was ist DKMS?
DKMS (Decentralised Key Management) bezeichnet die Kategorie von Identitätsinfrastruktur, in der kryptografisches Vertrauen am organisatorischen Rand verankert ist und nicht in einer zentralen Zertifizierungsstelle. Jede Organisation kontrolliert ihr eigenes Schlüsselmaterial und ihr eigenes Key Event Log (KEL), das ausschliesslich fortgeschrieben wird. Vereign hat die DKMS Alliance mitbegründet, um DKMS als Kategorie neben PKI und OAuth zu formalisieren.
Wie unterscheidet sich DKMS von PKI?
PKI verankert Vertrauen in zentralen Zertifizierungsstellen: Wird eine einzige CA kompromittiert, ist jedes Subjekt betroffen, das sie signiert hat. DKMS verankert Vertrauen im eigenen Key Event Log jeder Organisation: Ein Ausfall bleibt auf einen einzelnen Controller beschränkt, die Schlüsselrotation erfolgt nativ und atomar über Pre-Rotation-Commitments, und Vertrauen über Rechtsräume hinweg benötigt keine Anerkennungsabkommen zwischen Zertifizierungsstellen. DKMS ist PKI am Rand, ohne den Single Point of Failure.
Ersetzt DKMS OAuth?
Nein. OAuth ist für lokale Token-Flows innerhalb einer Organisation richtig und sollte dort weiter eingesetzt werden. DKMS löst ein Problem, für das OAuth nie entworfen worden ist: verifizierbares Vertrauen zwischen Organisationen ohne gemeinsamen Vermittler. Behalten Sie Ihren Identitätsanbieter und ergänzen Sie DKMS für institutionelles Vertrauen.
Ist DKMS Post-Quantum-fähig?
Ja. Bei DKMS ist die Schlüsselrotation ein nativ unterstützter Standardvorgang. Wenn Post-Quantum-Algorithmen erforderlich werden, wird die Migration zu einer routinemässigen Schlüsselrotation im bestehenden Key Event Log und nicht zu einer flächendeckenden Neuausstellung von Zertifikaten. Die Pre-Rotation-Eigenschaft von KERI bedeutet, dass der nächste Schlüssel auf jedem Algorithmus beruhen kann, auf den sich der Controller festlegt (einschliesslich Post-Quantum-Verfahren), ohne bestehende Vertrauensbeziehungen zu brechen.
Wer pflegt DKMS?
DKMS ist eine offene Spezifikation. Die von Vereign mitbegründete DKMS Alliance koordiniert die Spezifikation. Die Referenzimplementierung von KERI (dem Protokoll, auf dem DKMS aufbaut) wird von der breiteren KERI-Community als Open Source gepflegt. Verimesh von Vereign ist eine AGPLv3+-Implementierung der DKMS-Schicht: Gateway und zentrale CA laufen bei HIN produktiv, die ersten Institutionen sind migriert. SEAL ist das AGPLv3+-System von Vereign für verschlüsselte Swarm-Zustellung und ist architektonisch unabhängig von DKMS.
Benötigt DKMS eine Blockchain?
Nein. DKMS nutzt hashverkettete Key Event Logs (KELs), die ausschliesslich fortgeschrieben werden, arbeitet aber ohne Konsensschicht, ohne Token und ohne Distributed Ledger. Der Verzicht auf Blockchain ist eine bewusste Architekturentscheidung: Regulierte Infrastruktur benötigt deterministische Verifikation, keine probabilistische Finalität.
Kann Vereign mich bei der Integration mit der swiyu- oder EUDI-Wallet unterstützen?
Ja, so ist es vorgesehen, aber noch nicht produktiv: Die Brückenkomponenten sind heute architektonisch angelegt, nicht ausgeliefert. Sobald diese Systeme laufen, nehmen Sie beim Onboarding eine staatliche E-ID (swiyu, EUDI) als Vertrauenswurzel an, und Verimesh trägt dieses Vertrauen weiter: über die Institutionen, Rechtsräume und Systeme eines realen Arbeitsablaufs, einschliesslich der dort handelnden Personen, Rollen und Agents, und was mit einer Einwilligungsentscheidung geschieht, nachdem Daten weitergegeben worden sind.
Ist Vereign ein Konkurrent nationaler Wallets?
Nein. Eine nationale Wallet gibt einer Person eine verifizierbare Identität. Verimesh gibt sie einer Organisation, samt ihren Abteilungen, Geräten, Diensten und Agents. Beide arbeiten auf verschiedenen Ebenen und ergänzen sich, statt sich zu überschneiden. Verimesh behält seine eigene Vertrauensschicht und ist darauf ausgelegt, am Rand deren Protokolle zu sprechen.
Ist die Verimesh-Brücke zu swiyu oder EUDI im Produktivbetrieb?
Nein. Die Brückenkomponenten (ein OID4VCI/VP-Provider, Credential-Export, Identifier-Mapping) sind architektonisch angelegt und auf Designebene demonstriert, aber nicht ausgeliefert. Verimesh selbst ist im Schweizer Gesundheitswesen in Produktion: Gateway und zentrale CA bei HIN laufen produktiv, die ersten Institutionen sind migriert und nutzen sie, und die Migration im HIN-Netz soll vor Ende 2026 abgeschlossen sein.

Architekturüberprüfung buchen: Die Übertragung auf Ihre Vertrauensgrenzen übernehmen wir.

Diese Architektur ist im Schweizer Gesundheitswesen landesweit im Einsatz. Ob Sie Alternativen zu zentralisierter Identität prüfen oder organisationsübergreifenden Datenaustausch planen: In einem 30-minütigen Gespräch übertragen wir sie auf Ihre Umgebung.

Architekturüberprüfung buchen
Schweizer Datenschutz DSGVO-konform Open Source AGPLv3+ Schweizer Hosting
Die Architektur Schritt für Schritt ansehen