Dall’interrogazione DNS allo scambio di dati verificato, in millisecondi.
Con Verimesh l’infrastruttura email non dipende più dalla fiducia presunta: la verifica. Ogni scambio di messaggi tra organizzazioni risolve l’identità crittografica, stabilisce il consenso secondo le policy e crea un registro verificabile, senza appesantire i flussi di lavoro né cambiare il modo in cui lavorano gli utenti finali.
Prenotate una presentazione guidata dell’architettura (30 minuti)Gli attuali sistemi di fiducia costringono le organizzazioni a dipendere da autorità centrali per ogni verifica di identità e ogni scambio di dati. L’architettura di Vereign elimina queste dipendenze permettendo a ogni organizzazione di controllare la propria identità crittografica e di verificare le altre direttamente. Ecco come funziona nella pratica, dalla gestione delle chiavi allo scambio di dati verificato.
Che cosa succede quando inviate un messaggio
La sequenza in 7 passaggi qui sotto è il percorso di ogni messaggio abilitato a Verimesh: dal momento in cui il vostro client DNS effettua un’interrogazione al momento in cui i dati arrivano a destinazione verificati e sottoposti ad audit.
Passaggio 1: il DNS Proxy intercetta l’interrogazione
Quando la vostra applicazione risolve il dominio di una controparte (per esempio hospital-b.ch), il DNS Proxy di Verimesh intercetta l’interrogazione prima che raggiunga il vostro resolver a monte. È questo il punto di ingresso: nessuna modifica al codice applicativo. Il proxy opera in modo trasparente a livello di rete.
Passaggio 2: l’Identity Agent verifica lo stato della controparte
L’Identity Agent interroga il record di identità che la controparte pubblica tramite Verimesh. Due esiti possibili: la controparte è abilitata a Verimesh (si procede con la verifica crittografica completa) oppure non lo è (si torna alla consegna standard e il messaggio viene contrassegnato come non verificato). È così che Verimesh garantisce la retrocompatibilità: non blocca mai i messaggi verso controparti prive di Verimesh.
Passaggio 3: tunnel WireGuard stabilito con chiavi derivate dal DKMS
Se la controparte è abilitata a Verimesh, viene stabilito un tunnel VPN WireGuard con chiavi derivate dai record di identità DKMS di entrambe le organizzazioni. Queste chiavi non sono emesse da un’autorità di certificazione centrale: sono derivate dal registro degli eventi di chiave KERI (Key Event Log) di ciascuna organizzazione. Il tunnel è bilaterale: ciascuna parte è autenticata verso l’altra in modo indipendente.
Passaggio 4: il motore di policy valuta il consenso
Prima che qualsiasi dato si muova, il motore di policy di Verimesh (Open Policy Agent, OPA) valuta se lo scambio di dati è autorizzato dalle policy di entrambe le parti. Per i dati sanitari, il FHIR Resolver verifica il consenso a livello di risorsa: i consensi dei pazienti, le autorizzazioni organizzative e le normative di settore (EHDS, nLPD svizzera) vengono valutati in tempo reale. I dati non autorizzati dalle policy non si muovono. Lo stesso controllo di policy copre l’ambito delegato: la parte ricevente può confermare che una persona, un ruolo o un agente agisce entro le autorizzazioni concesse dalla sua organizzazione, con una verifica rispetto alla catena di credenziali di quell’organizzazione anziché a un registro centrale.
FHIR-over-Verimesh è oggi a livello architetturale: il deployment in produzione dipende dall’onboarding degli ospedali, e la prima data realistica è la fine del 2026.
Leggete perché questa architettura è necessaria, non solo migliore →
Passaggio 5: il token viene tradotto localmente
I vostri token OAuth e i certificati X.509 esistenti restano validi. Il bridge di compatibilità di Verimesh traduce le credenziali ancorate a KERI in formato JWT o X.509 sul lato ricevente: localmente, senza contattare alcuna autorità esterna. La vostra infrastruttura di identità non cambia. Verimesh la estende per operare oltre i confini organizzativi.
Passaggio 6: i dati vengono scambiati sulla mesh cifrata
Con il consenso di policy confermato e il tunnel WireGuard cifrato stabilito, lo scambio di dati procede. SEAL (Secure Edge Application Layer) avvolge ogni messaggio in uno strato di autenticità verificabile: l’organizzazione ricevente può dimostrare chi ha inviato i dati, quando sono stati inviati e che non sono stati modificati in transito. Questo sostituisce la dipendenza di S/MIME da autorità di certificazione di terze parti con una verifica bilaterale derivata dal DKMS.
Passaggio 7: il registro di audit viene scritto in KEL/TEL
Ogni scambio crea una voce nel Key Event Log (KEL) e nel Transaction Event Log (TEL) di KERI. Questi registri sono concepiti in modo che qualsiasi manomissione risulti evidente, e sono verificabili in modo indipendente da qualsiasi parte: non solo da un server di log centrale. Per i settori regolamentati, questo significa registri di audit tra organizzazioni crittograficamente solidi e disponibili senza infrastruttura centralizzata. Il vostro team di conformità può verificare qualsiasi scambio in modo indipendente, in qualsiasi momento.
Cinque strati di infrastruttura di fiducia
Lo stack di fiducia di Verimesh è progettato a strati. Ogni strato fa bene una cosa e passa il testimone in modo pulito al successivo. L’infrastruttura esistente si innesta nello strato di compatibilità: non si elimina nulla.
Che cosa resta. Che cosa cambia.
Verimesh non è un progetto di sostituzione: è un’estensione dell’infrastruttura che già gestite. La tabella qui sotto mostra che cosa mantenete e che cosa Verimesh aggiunge.
443 violazioni di dati personali segnalate ogni giorno in Europa ai sensi del GDPR, con sanzioni cumulative superiori a 1,2 miliardi di EUR (DLA Piper GDPR Fines and Data Breach Survey)
Che cosa resta
- ✓OAuth 2.0 / OIDC: continua a gestire l’autenticazione interna e l’emissione locale dei token. Nessuna modifica richiesta.
- ✓Certificati X.509: restano validi. Il bridge da KERI a X.509 traduce al confine senza toccare la vostra PKI.
- ✓JWT: il vostro formato di token non cambia. Verimesh produce credenziali verificabili ancorate a KERI che vengono tradotte in JWT sul lato ricevente.
- ✓SMTP / DKIM / DMARC: l’instradamento email e l’infrastruttura anti-spam restano in funzione. SEAL aggiunge uno strato di autenticità verificabile sopra DKIM, non in sua sostituzione.
- ✓Flussi di lavoro esistenti: gli utenti finali inviano email come prima. La verifica della fiducia è invisibile per loro.
Che cosa cambia
- →Dipendenza da un’autorità di certificazione centralizzata: sostituita da una derivazione bilaterale delle chiavi ancorata al DKMS. Nessuna terza parte può revocare alla vostra organizzazione la capacità di comunicare.
- →Email basata sulla fiducia al primo utilizzo: sostituita da un’identità organizzativa verificata crittograficamente a ogni scambio. Gli attacchi di phishing e di falsificazione dell’identità contro la comunicazione organizzativa sono prevenuti in modo strutturale.
- →Flussi di consenso manuali: sostituiti dal consenso valutato dal motore di policy (OPA). Gli accordi di condivisione dei dati sono leggibili dalle macchine e applicati a livello di infrastruttura.
- →Registri di audit frammentati: sostituiti da registrazioni KEL/TEL collegate crittograficamente e verificabili in modo indipendente oltre i confini organizzativi.
Altri hanno tentato l’identità decentralizzata. Che cosa rende diverso questo approccio?
È la domanda giusta. Tre progetti ben finanziati non sono riusciti a realizzare l’identità decentralizzata su larga scala:
- Sovrin: la Sovrin Foundation ha esaurito il capitale operativo nel 2023. La sua blockchain Hyperledger Indy richiedeva un coordinamento continuo dei nodi validatori e una fondazione finanziata per mantenerne la governance. Quando la fondazione non è più riuscita a sostenersi, la rete si è arenata. La modalità di fallimento non è stata tecnica, ma di governance ed economica: la dipendenza dalla blockchain ha creato un problema di coordinamento che richiedeva una gestione centralizzata per essere risolto.
- uPort: il progetto di identità di ConsenSys è stato ribattezzato Serto, per poi abbandonare del tutto il campo dell’identità. uPort era costruito su Ethereum: ogni operazione di identità comportava commissioni gas e la latenza delle transazioni on-chain. La gestione dell’identità su scala di produzione, milioni di eventi al giorno, non è economicamente sostenibile su una blockchain pubblica.
- Jolocom: ha abbandonato l’infrastruttura di identità dopo non aver raggiunto l’adozione in produzione. Lo schema di fallimento comune ai progetti SSI: dipendenza da un’infrastruttura blockchain che non può scalare economicamente, o una governance di fondazione che non riesce a sostenersi.
KERI è strutturalmente diverso. Non ha alcuna dipendenza dalla blockchain. Gli eventi di chiave sono ancorati in registri append-only che ogni controller mantiene in modo indipendente: nessun registro condiviso, nessuna commissione gas, nessuna governance di fondazione richiesta. La rete non ha bisogno di un coordinatore centrale, perché la fiducia si stabilisce bilateralmente tra le parti e non viene convalidata da uno stato globale condiviso.
La convalida istituzionale: GLEIF, la Global Legal Entity Identifier Foundation, gestisce il sistema LEI globale per le istituzioni finanziarie in 180 paesi. GLEIF ha scelto KERI per il sistema vLEI (verifiable Legal Entity Identifier). Non è una prova di concetto: è infrastruttura di produzione che verifica l’identità delle istituzioni finanziarie a livello globale. Verimesh (in precedenza il progetto Stargate) si basa sullo stesso fondamento KERI che GLEIF ha convalidato su scala istituzionale.
Volete capire come si adatta alla vostra organizzazione?
Scoprite come l’infrastruttura di fiducia verificata si applica ai vostri requisiti specifici e al vostro contesto normativo.