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 obligent les organisations à dépendre d’autorités centrales pour chaque vérification d’identité et chaque échange de données. L’architecture de Vereign élimine ces dépendances : chaque organisation contrôle sa propre identité cryptographique et vérifie les autres directement. Voici comment cela fonctionne en pratique, de la gestion des clés à l’échange de données vérifié.
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 au-delà des 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.
Ce qui reste. Ce qui change.
Verimesh n’est pas un projet de remplacement. C’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 envers une autorité de certification centralisée : remplacée par une dérivation de clés bilatérale ancrée dans le DKMS. Aucun tiers ne peut révoquer la capacité de votre organisation à communiquer.
- →E-mail fondé sur la confiance au premier contact : remplacé par une identité organisationnelle vérifiée cryptographiquement à chaque échange. Les attaques d’hameçonnage et d’usurpation visant la communication organisationnelle sont structurellement empêchées.
- →Flux de consentement manuels : remplacés par un consentement évalué par le moteur de politiques (OPA). Les accords de partage de données sont lisibles par machine et appliqués au niveau de l’infrastructure.
- →Journaux d’audit fragmentés : remplacés par des enregistrements KEL/TEL liés cryptographiquement, vérifiables de manière indépendante au-delà des 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). Ce n’est pas une preuve de concept : c’est 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.