Une seule identité vérifiable pour toute votre organisation.

Pas seulement l’entreprise : chaque département, appareil, service et agent, vérifiable par les institutions avec lesquelles vous travaillez, sans passer par un fournisseur commun.

Discuter de cette architecture pour votre organisation

Quatre limites structurelles des outils d’identité standard

OpenID Connect, OAuth et l’infrastructure à clés publiques (PKI) sont d’excellents outils à l’intérieur du périmètre d’une seule organisation. La fédération ne supprime pas ce périmètre : elle le déplace, soit vers des accords négociés à l’avance entre chaque paire d’organisations, soit vers un intermédiaire central qu’aucune d’entre elles ne contrôle. Ce ne sont pas des défaillances, mais des contraintes architecturales qui apparaissent dès que la confiance doit s’étendre entre organisations.

Confiance dans les jetons

Limite des outils standard

Les jetons d’accès ne sont reconnus qu’à l’intérieur du périmètre de leur émetteur. Entre organisations, ce périmètre cède : l’organisation réceptrice n’a aucun moyen de vérifier l’autorité de l’organisation émettrice.

Solution DKMS / Verimesh

DKMS établit une identité cryptographique auto-certifiante : l’identité de chaque organisation est vérifiable par toute autre organisation, sans dépendre d’une autorité de certification commune.

Granularité des accès

Limite des outils standard

Les portées d’autorisation sont grossières, conçues pour des droits applicatifs. Un consentement au niveau du graphe de ressources, entre organisations, exige un autre modèle.

Solution DKMS / Verimesh

Le moteur de politiques de Verimesh (Open Policy Agent, OPA) permet un contrôle d’accès programmable et fin, qui franchit les frontières de confiance entre organisations.

Auditabilité

Limite des outils standard

Les journaux d’authentification s’arrêtent à l’organisation qui les a produits. Un journal d’audit interorganisationnel (qui a accédé à quoi, quand, sur autorisation de qui) exige un chaînage cryptographique que l’authentification locale ne fournit pas par conception.

Solution DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) fournit des journaux d’audit à intégrité vérifiable. Chaque événement d’identité est chaîné cryptographiquement et vérifiable indépendamment, d’où une auditabilité interorganisationnelle.

Architecture de confiance

Limite des outils standard

Ces modèles supposent une autorité centrale : un fournisseur d’identité auquel tous font confiance. La confiance institutionnelle distribuée entre organisations souveraines ne peut dépendre d’aucune autorité unique.

Solution DKMS / Verimesh

DKMS permet une gestion souveraine de l’identité : chaque organisation contrôle ses propres racines cryptographiques. La confiance s’établit bilatéralement, sans être déléguée à un coordinateur central.

Gardez votre fournisseur d’identité. Ajoutez la confiance entre institutions.

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organisational trust establishment
Infrastructure d’identité KERI : identifiants auto-certifiants, reçus d’événements de clé et confiance bilatérale sans autorité centrale

Il s’agit d’une capacité nouvelle. Votre fournisseur d’identité, et les protocoles qui le sous-tendent (OpenID Connect, OAuth, SAML), sont éprouvés pour l’authentification au sein d’une seule organisation, et ils restent en place. DKMS (Decentralized Key Management System) fait ce pour quoi ils n’ont jamais été conçus : il donne à chaque organisation une identité auto-certifiante que toute autre institution peut vérifier directement, sans fournisseur commun entre elles. Verimesh apporte DKMS et dialogue avec les systèmes que vous exploitez déjà : vous étendez l’existant plutôt que de le remplacer.

S’appuyer sur les programmes nationaux d’e-ID

Le programme swiyu est l’infrastructure fédérale suisse d’identité électronique. Son premier justificatif, le permis d’élève conducteur électronique, est en service dans tous les cantons depuis décembre 2025, avec environ 27 000 exemplaires délivrés. La mise en service de l’infrastructure de confiance de l’e-ID est visée pour le premier semestre 2027, tandis que l’introduction de l’e-ID elle-même a été reportée, sans nouvelle date annoncée. Les identifiants des émetteurs et les déclarations de confiance sont publiés dans des registres fédéraux centraux, et le justificatif est conservé sur l’appareil personnel de son titulaire. La même infrastructure devrait porter des justificatifs de cantons, d’universités et d’employeurs dès qu’elle s’ouvrira à l’ensemble des émetteurs.

Vereign participe au processus suisse de l’e-ID depuis le début, à travers des réunions de participation et des échanges bilatéraux, et Georg Greve a été membre du Technical Advisory Circle (un groupe convoqué par fedpol) qui a éclairé la décision technologique de janvier 2024.

L’Union européenne suit la même voie. Le règlement (UE) 2024/1183 impose à chaque État membre de proposer au moins un portefeuille européen d’identité numérique (EUDI), et le justificatif fondamental de la personne provient de fournisseurs désignés par l’État. Les deux programmes répondent à la même question, et y répondent bien : comment une personne prouve son identité à une institution. Aucun des deux ne spécifie l’identité des départements, appareils, services et agents qu’une organisation exploite réellement, et tous deux ancrent la confiance dans des registres centraux, ce qui explique qu’aucun ne tienne de registre des parties utilisatrices qui vérifient les justificatifs : à l’échelle de l’Union, elles seraient beaucoup trop nombreuses à recenser.

Pour les organisations qui déploient Verimesh, swiyu et EUDI deviennent des briques sur lesquelles bâtir. Le pont est aujourd’hui conçu, mais pas livré : dès que ces systèmes atteindront la production, vous accepterez une e-ID étatique lors de l’intégration, qui deviendra une racine de confiance, et Verimesh portera cette confiance à travers les institutions, les juridictions et les systèmes que traverse un processus métier réel, en émettant vos propres justificatifs dans ce même portefeuille.

Verimesh fournit cette architecture

Verimesh (anciennement le projet Stargate) est la mise en œuvre en production de l’architecture de confiance décrite ci-dessus. Il fonctionne avec l’authentification que vous exploitez déjà et ajoute ce pour quoi elle n’a jamais été conçue : une identité organisationnelle ancrée dans DKMS pour la confiance entre institutions, un moteur de politiques programmable (Open Policy Agent), une signification commune des données via Overlays Capture Architecture (OCA) et une remise de messages à intégrité vérifiable via SEAL.

Verimesh est en production dans le système de santé suisse : la passerelle et l’autorité de certification centrale chez HIN fonctionnent en production, les premières institutions sont migrées et les utilisent, et la migration de l’ensemble du réseau HIN est prévue pour s’achever avant fin 2026.

Découvrir Verimesh

Une seule identité organisationnelle, jusqu’à la couche réseau.

Verimesh fait passer son trafic par WireGuard, et la clé du tunnel est ancrée dans la même identité organisationnelle que les applications situées au-dessus. Les clés de tunnel Curve25519 de chaque organisation sont dérivées de son propre matériel Decentralized Key Management (DKMS) : aucune autorité centrale ne les délivre, et il n’existe aucun écart entre l’identité de la couche réseau et celle de la couche applicative. La rotation des clés est coordonnée avec DKMS (pré-rotation fondée sur KERI), et chaque établissement de tunnel est auditable au regard du Key Event Log. Aucun intermédiaire ne possède le flux de données.

Silencieux par conception

Les paquets non authentifiés restent sans réponse. Le maillage est invisible à un balayage de ports : aucune surface d’attaque publique à sonder.

Environ 4 000 lignes que vous pouvez lire

WireGuard représente environ 4 000 lignes de code, contre quelque 100 000 pour OpenVPN et 400 000 pour IPsec. L’auditabilité est en soi une propriété de sécurité.

Ni négociation, ni rétrogradation

Des algorithmes modernes figés : Curve25519, ChaCha20-Poly1305, BLAKE2s, la poignée de main Noise_IKpsk2. Confidentialité persistante avec renouvellement des clés toutes les deux minutes environ et dissimulation des identités : intégrées, non configurées.

Souverain jusqu’au fil

Open Source de bout en bout, auto-hébergé, sans plan de contrôle SaaS sur le chemin. La souveraineté s’étend de l’application jusqu’au transport lui-même.

Infrastructure éprouvée, sans surprise

Dans le noyau Linux principal depuis 2020. Rien ici n’est de la cryptographie inédite, et cela porte aujourd’hui le déploiement de Verimesh avec HIN.

Prêt pour la migration quantique

La couche de clé pré-partagée de WireGuard couvre déjà le trafic actuel contre les attaques « stocker maintenant, déchiffrer plus tard ». Et comme les clés de tunnel dérivent de DKMS, passer aux algorithmes post-quantiques n’est qu’une rotation de clés de routine sur le Key Event Log existant, non une réémission générale.

Voir le cycle de vie complet de la connexion

DKMS existe pour appliquer le consentement

L’article 71(8) de l’EHDS crée une contrainte structurelle qu’aucune autorité centrale ne peut satisfaire : lorsqu’une personne exerce son opt-out pour l’utilisation secondaire, ce retrait doit se propager à toute institution qui détient les données d’origine ou en dérive. Aucune autorité de certification ne peut co-signer l’opt-out ; aucun fournisseur d’identité ne peut répercuter la révocation en cascade. Sur le plan architectural, la contrainte est incompatible avec une identité centralisée.

DKMS satisfait les cinq exigences posées par l’article 71 de l’EHDS : identifiants rattachés à la personne qui survivent à une nouvelle inscription ; enregistrements d’opt-out vérifiables et horodatés, ancrés dans le Key Event Log ; réversibilité sans ré-identification ; propagation entre responsables de traitement sans accord bilatéral entre chaque paire d’institutions ; et non-chaînabilité entre l’enregistrement de consentement et les données qu’il couvre.

Une fois les données divulguées (partagées dans un réseau hospitalier, un consortium de recherche ou une chaîne de payeurs), un opt-out ultérieur doit encore atteindre chaque responsable de traitement en aval. Les Key Event Logs de DKMS propagent la révocation par voie cryptographique : le KEL de chaque responsable est à ajout uniquement et attesté par des témoins, si bien qu’une révocation ajoutée du côté de la personne devient vérifiable dans chaque institution détenant un enregistrement dérivé.

Lisez la thèse sur l’architecture du consentement

Éprouvé dans le système de santé suisse, choisi pour un déploiement à l’échelle nationale

HIN (Health Info Net) est le réseau suisse d’information de santé : il relie hôpitaux, cabinets de médecine générale et prestataires spécialisés au-delà des frontières cantonales. SEAL, la porte d’entrée de la gamme sur cette couche de confiance, traite déjà plus de 800 000 remises vérifiées par mois. Verimesh est en production dans le système de santé suisse : la passerelle et l’autorité de certification centrale chez HIN fonctionnent en production, les premières institutions sont migrées et les utilisent, et la migration de l’ensemble du réseau HIN est prévue pour s’achever avant fin 2026.

HIN (Health Info Net)

800 000+

remises vérifiées par mois

Architecture de confiance : questions fréquentes

Qu’est-ce que DKMS ?
DKMS (gestion décentralisée des clés) désigne la catégorie d’infrastructure d’identité où la confiance cryptographique est ancrée à la périphérie des organisations, et non dans une autorité de certification centrale. Chaque organisation contrôle son propre matériel cryptographique et son propre Key Event Log (KEL), un journal à ajout uniquement. Vereign a co-fondé la DKMS Alliance pour formaliser DKMS en tant que catégorie, aux côtés de PKI et d’OAuth.
En quoi DKMS diffère-t-il de PKI ?
PKI ancre la confiance dans des autorités de certification centrales ; la compromission d’une seule affecte tous les sujets qu’elle a signés. DKMS ancre la confiance dans le Key Event Log propre à chaque organisation : une défaillance reste circonscrite à un seul contrôleur, la rotation des clés est native et atomique grâce aux engagements de pre-rotation, et la confiance entre juridictions ne dépend d’aucun traité de reconnaissance entre autorités. DKMS, c’est la PKI à la périphérie, sans le point de défaillance unique.
DKMS remplace-t-il OAuth ?
Non. OAuth est le bon choix pour les flux de jetons locaux au sein d’une même organisation, et doit continuer à y être utilisé. DKMS résout un problème pour lequel OAuth n’a jamais été conçu : établir une confiance vérifiable entre organisations, sans intermédiaire partagé. Gardez votre fournisseur d’identité et ajoutez DKMS pour la confiance entre institutions.
DKMS est-il prêt pour le post-quantique ?
Oui. DKMS traite la rotation des clés comme une opération de premier ordre. Lorsque des algorithmes post-quantiques sont requis, la migration se ramène à une rotation de clés ordinaire sur le Key Event Log existant, et non à une réémission massive de certificats. Grâce à la propriété de pre-rotation de KERI, la clé suivante peut utiliser n’importe quel algorithme auquel le contrôleur s’est engagé, y compris un schéma post-quantique, sans rompre les relations de confiance existantes.
Qui maintient DKMS ?
DKMS est une spécification ouverte. La DKMS Alliance, cofondée par Vereign, en coordonne la spécification. L’implémentation de référence de KERI (le protocole qui sous-tend DKMS) est maintenue en Open Source par la communauté KERI au sens large. Verimesh, de Vereign, est une implémentation AGPLv3+ de la couche DKMS : sa passerelle et son autorité de certification centrale fonctionnent en production chez HIN, les premiers clients ayant déjà été migrés. SEAL est le système de remise en essaim chiffrée de Vereign, sous AGPLv3+, et il est architecturalement indépendant de DKMS.
DKMS nécessite-t-il une blockchain ?
Non. DKMS utilise des Key Event Logs (KELs) chaînés par hachage pour garantir une intégrité à ajout uniquement, mais il n’y a ni couche de consensus, ni jeton, ni registre distribué. Le choix architectural d’écarter la blockchain est délibéré : une infrastructure réglementée exige une vérification déterministe, et non une finalité probabiliste.
Vereign peut-il m’aider à intégrer le portefeuille swiyu ou EUDI ?
Oui, par conception, mais pas encore en production : les composants du pont sont aujourd’hui d’ordre architectural, pas livrés. Dès que ces systèmes seront en service, vous accepterez une e-ID étatique (swiyu, EUDI) lors de l’intégration et vous en ferez une racine de confiance ; Verimesh portera ensuite cette confiance plus loin : à travers les institutions, les juridictions et les systèmes que traverse un processus métier réel, y compris les personnes, les rôles et les agents qui y agissent, et jusqu’à ce qu’il advient d’une décision de consentement une fois les données déjà partagées.
Vereign est-il un concurrent des portefeuilles nationaux ?
Non. Un portefeuille national donne une identité vérifiable à une personne. Verimesh en donne une à une organisation, pour les départements, appareils, services et agents qu’elle exploite : les deux opèrent à des niveaux différents et se composent au lieu de se recouvrir. Verimesh conserve sa propre couche de confiance et est conçu pour parler les protocoles de ces portefeuilles à la périphérie.
Le pont Verimesh vers swiyu ou EUDI est-il en production ?
Non. Les composants du pont (un fournisseur OID4VCI/VP, l’export de justificatifs, la mise en correspondance des identifiants) sont d’ordre architectural, démontrés au niveau de la conception, mais pas livrés. Verimesh lui-même est en production dans le système de santé suisse : la passerelle et l’autorité de certification centrale chez HIN fonctionnent en production, les premières institutions sont migrées et les utilisent, et la migration de l’ensemble du réseau HIN est prévue pour s’achever avant fin 2026.

Réservez une revue d’architecture. Nous l’adaptons à vos frontières de confiance.

Cette architecture est déployée à l’échelle nationale dans le système de santé suisse. Que vous évaluiez des alternatives à l’identité centralisée ou prépariez un échange de données interorganisationnel, nous la transposons à votre environnement en 30 minutes d’appel.

Réserver une revue d’architecture
Protection des données suisse Conforme au RGPD Open Source AGPLv3+ Hébergement suisse
Découvrez le fonctionnement de l’architecture, étape par étape