De la requête DNS à l’échange de données vérifié, en millisecondes.
Avec Verimesh, la confiance de l’infrastructure de messagerie n’est plus présumée : elle est vérifiée. Chaque échange de messages entre organisations résout l’identité cryptographique, établit le consentement selon les politiques et crée une trace auditable, sans alourdir les processus ni changer les habitudes des utilisateurs.
Réserver une présentation d’architecture (30 min)Les systèmes de confiance actuels font dépendre les organisations d’autorités centrales pour les vérifications d’identité et les échanges de données entre elles. L’architecture de Vereign laisse chaque organisation contrôler sa propre identité cryptographique : les contreparties qui vérifient au regard de son journal d’événements de clés n’ont besoin d’aucune autorité centrale pour la vérifier. Voici comment cela fonctionne en pratique, de la gestion des clés à l’échange de données.
Ce qui se passe lorsque vous envoyez un message
La séquence en 7 étapes ci-dessous est le chemin que suit chaque message transitant par Verimesh, du moment où votre client DNS émet une requête jusqu’au moment où les données arrivent à destination, vérifiées et auditées.
Étape 1 : le proxy DNS intercepte la requête
Lorsque votre application résout le domaine d’une contrepartie (par exemple hospital-b.ch), le proxy DNS de Verimesh intercepte la requête avant qu’elle n’atteigne votre résolveur amont. C’est le point d’entrée : aucune modification du code applicatif n’est requise. Le proxy opère de manière transparente au niveau de la couche réseau.
Étape 2 : l’Identity Agent vérifie le statut de la contrepartie
L’Identity Agent interroge l’enregistrement d’identité publié via Verimesh par la contrepartie. Deux issues possibles : la contrepartie est équipée de Verimesh (la vérification cryptographique complète se poursuit) ou elle ne l’est pas (repli vers la remise standard, le message étant marqué comme non vérifié). C’est ainsi que Verimesh assure la rétrocompatibilité : il ne bloque jamais les messages vers des contreparties non équipées de Verimesh.
Étape 3 : tunnel WireGuard établi avec des clés dérivées du DKMS
Si la contrepartie est équipée de Verimesh, un tunnel VPN WireGuard est établi à l’aide de clés dérivées des enregistrements d’identité DKMS des deux organisations. Ces clés ne sont pas émises par une autorité de certification centrale : elles sont dérivées du journal d’événements de clés KERI propre à chaque organisation. Le tunnel est bilatéral : chaque partie est authentifiée auprès de l’autre de manière indépendante.
Étape 4 : le moteur de politiques évalue le consentement
Avant tout mouvement de données, le moteur de politiques de Verimesh (Open Policy Agent, OPA) évalue si l’échange est autorisé par les politiques des deux parties. Pour les données de santé, le résolveur FHIR contrôle le consentement au niveau de la ressource : dossiers de consentement des patients, autorisations organisationnelles et réglementations sectorielles (EHDS, LPD suisse) sont évalués en temps réel. Les données non autorisées par les politiques ne circulent pas. Le même contrôle de politique couvre la délégation de périmètre : la partie destinataire peut confirmer qu’une personne, un rôle ou un agent agit dans les autorisations accordées par son organisation, la vérification s’effectuant au regard de la chaîne de justificatifs propre à cette organisation plutôt que d’un registre central.
FHIR sur Verimesh est aujourd’hui architectural : le déploiement en production dépend de l’intégration des hôpitaux, la première échéance réaliste étant fin 2026.
Lisez pourquoi cette architecture est nécessaire, et pas seulement meilleure →
Étape 5 : traduction locale du jeton
Vos jetons OAuth et vos certificats X.509 existants restent valides. Le pont de compatibilité de Verimesh traduit les justificatifs ancrés dans KERI au format JWT ou X.509 du côté du destinataire : localement, sans contacter d’autorité externe. Votre infrastructure d’identité ne change pas. Verimesh l’étend pour opérer à travers les frontières organisationnelles.
Étape 6 : données échangées sur le maillage chiffré
Une fois le consentement confirmé selon les politiques et le tunnel WireGuard chiffré établi, l’échange de données a lieu. SEAL (Secure Edge Application Layer) enveloppe chaque message d’une couche d’authenticité vérifiable : l’organisation destinataire peut prouver qui a envoyé les données, à quel moment, et qu’elles n’ont pas été modifiées en transit. Cette approche remplace la dépendance de S/MIME envers des autorités de certification tierces par une vérification bilatérale fondée sur des clés dérivées du DKMS.
Étape 7 : le journal d’audit est consigné dans le KEL/TEL
Chaque échange crée une entrée dans le Key Event Log (KEL) et le Transaction Event Log (TEL) de KERI. Ces journaux sont à intégrité vérifiable et peuvent être vérifiés de manière indépendante par toute partie, et pas uniquement par un serveur de journaux central. Pour les secteurs réglementés, cela signifie des journaux d’audit inter-organisationnels cryptographiquement solides, disponibles sans infrastructure centralisée. Votre équipe conformité peut vérifier n’importe quel échange de manière indépendante, à tout moment.
Cinq couches d’infrastructure de confiance
La pile de confiance de Verimesh est conçue en couches. Chaque couche fait une seule chose, et la fait bien, puis passe proprement le relais à la suivante. L’infrastructure existante s’intègre à la couche de compatibilité ; rien n’est mis au rebut, l’existant reste en place.
Zero Trust entre organisations
La publication NIST SP 800-207 indique qu’en Zero Trust « la confiance n’est jamais accordée implicitement mais doit être évaluée en continu » (§2). Pour la collaboration à travers les frontières d’entreprise (§4.4), elle note que l’inscription des deux organisations dans un système d’identité fédéré rendrait ces relations plus rapides à établir : une commodité, non une exigence de Zero Trust. Dans DKMS, les contreparties qui vérifient au regard de journaux d’événements de clés contrôlent entre elles leurs identifiants sans intermédiaire. Le contrôleur d’un identifiant s’engage à l’avance sur ses prochaines clés, et tout vérificateur lit l’état actuel des clés dans le journal. Lorsqu’une contrepartie ne valide que X.509, comme c’est le cas chez HIN aujourd’hui, une autorité de certification pont relie les deux.
Ce qui reste. Ce qui change.
Verimesh est une extension de l’infrastructure que vous exploitez déjà. Le tableau ci-dessous montre ce que vous conservez et ce que Verimesh ajoute.
443 violations de données RGPD signalées chaque jour en Europe, pour des amendes cumulées dépassant 1,2 milliard d’euros (DLA Piper GDPR Fines and Data Breach Survey)
Ce qui reste
- ✓OAuth 2.0 / OIDC : continue de gérer l’authentification interne et l’émission locale de jetons. Aucune modification requise.
- ✓Certificats X.509 : restent valides. Le pont KERI vers X.509 traduit à la frontière, sans toucher à votre PKI.
- ✓JWT : votre format de jeton reste inchangé. Verimesh produit des justificatifs vérifiables ancrés dans KERI, traduits en JWT du côté du destinataire.
- ✓SMTP / DKIM / DMARC : le routage des e-mails et l’infrastructure anti-spam restent en place. SEAL ajoute une couche d’authenticité vérifiable par-dessus DKIM, et non à sa place.
- ✓Flux de travail existants : les utilisateurs finaux envoient leurs e-mails comme avant. La vérification de confiance leur est invisible.
Ce qui change
- →Dépendance exclusive envers une autorité de certification centrale : pour les contreparties qui vérifient au regard du journal d’événements de clés, la confiance repose sur des clés ancrées dans le DKMS. Le contrôleur d’un identifiant organisationnel non délégué procède à la rotation ou à la révocation de ses clés par pré-rotation, et la partie vérificatrice en contrôle le résultat dans le journal. Lorsqu’une contrepartie ne valide que X.509, comme c’est le cas chez HIN aujourd’hui, une autorité de certification pont relie les deux.
- →E-mail fondé sur la confiance au premier contact : les échanges entre organisations qui se vérifient mutuellement au regard de journaux d’événements de clés portent l’identité vérifiée de l’organisation émettrice ; se faire passer pour elle exige ses clés ou celles de son délégant, et non une adresse qui lui ressemble.
- →Flux de consentement manuels : seraient remplacés par un consentement évalué par le moteur de politiques (OPA). Les accords de partage de données seraient lisibles par machine et appliqués au niveau de l’infrastructure.
- →Journaux d’audit fragmentés : seraient remplacés par des enregistrements KEL/TEL liés cryptographiquement, vérifiables de manière indépendante à travers les frontières organisationnelles.
D’autres ont tenté l’identité décentralisée. Qu’est-ce qui rend cette approche différente ?
C’est la bonne question. Trois projets bien financés n’ont pas réussi à déployer l’identité décentralisée à grande échelle :
- Sovrin : la Sovrin Foundation a épuisé son capital d’exploitation en 2023. Sa blockchain Hyperledger Indy exigeait une coordination permanente des nœuds validateurs et une fondation financée pour en assurer la gouvernance. Lorsque la fondation n’a plus pu se financer, le réseau s’est enrayé. Le mode de défaillance n’était pas technique, il était économique et de gouvernance : la dépendance à la blockchain créait un problème de coordination qui ne pouvait se résoudre que par une gestion centralisée.
- uPort : le projet d’identité de ConsenSys a été rebaptisé Serto, puis a quitté entièrement le domaine de l’identité. uPort reposait sur Ethereum, si bien que chaque opération d’identité entraînait des frais de gaz et la latence des transactions sur la chaîne. La gestion d’identité à l’échelle de la production, des millions d’événements par jour, n’est pas économiquement viable sur une blockchain publique.
- Jolocom : a abandonné l’infrastructure d’identité faute d’adoption en production. Le schéma d’échec commun aux projets SSI : une dépendance à une infrastructure blockchain qui ne peut pas passer à l’échelle économiquement, ou une gouvernance de fondation qui ne peut pas se maintenir.
KERI est structurellement différent. Il n’a aucune dépendance à une blockchain. Les événements de clés sont ancrés dans des journaux en mode ajout seul que chaque contrôleur tient de manière indépendante : pas de registre partagé, pas de frais de gaz, aucune gouvernance de fondation requise. Le réseau n’a pas besoin de coordinateur central, car la confiance s’établit bilatéralement entre les parties au lieu d’être validée par un état global partagé.
La validation institutionnelle : GLEIF (la Global Legal Entity Identifier Foundation) exploite le système mondial des LEI pour les institutions financières de 180 pays. GLEIF a choisi KERI pour le système vLEI (verifiable Legal Entity Identifier) : une infrastructure de production qui vérifie l’identité d’institutions financières dans le monde entier. Verimesh (anciennement le projet Stargate) s’appuie sur le même socle KERI que GLEIF a validé à l’échelle institutionnelle.
Vous souhaitez comprendre comment cela s’applique à votre organisation ?
Découvrez comment l’infrastructure de confiance vérifiée s’applique à vos exigences spécifiques et à votre environnement réglementaire.