Una sola identità verificabile per tutta la vostra organizzazione.

Non solo l’azienda: ogni reparto, dispositivo, servizio e agente, verificabile dalle istituzioni con cui lavorate, senza alcun provider condiviso nel mezzo.

Parlate con noi di questa architettura per la vostra organizzazione

Quattro limiti strutturali degli strumenti di identità standard

OpenID Connect, OAuth e l’infrastruttura a chiave pubblica (PKI) sono strumenti eccellenti entro il confine di una singola organizzazione. La federazione non elimina quel confine, lo sposta: o in accordi negoziati in anticipo fra ogni coppia di organizzazioni, o in un intermediario centrale che nessuna di esse controlla. Non sono difetti, ma vincoli architetturali che diventano visibili nel momento in cui la fiducia deve estendersi oltre la singola organizzazione.

Fiducia nei token

Dove si fermano gli strumenti standard

I token di accesso sono affidabili entro il confine di chi li emette. Fra organizzazioni quel confine viene a mancare: l’organizzazione che riceve non ha modo di verificare l’autorità dell’organizzazione che emette.

Soluzione DKMS / Verimesh

DKMS stabilisce un’identità crittografica autocertificante: l’identità di ogni organizzazione è verificabile da qualsiasi altra, senza dipendere da un’autorità di certificazione condivisa.

Granularità degli accessi

Dove si fermano gli strumenti standard

Gli scope sono grossolani, pensati per permessi a livello di applicazione. Il consenso a livello di grafo delle risorse, fra organizzazioni, richiede un modello diverso.

Soluzione DKMS / Verimesh

Il motore di policy di Verimesh (Open Policy Agent, OPA) permette un controllo degli accessi programmabile e granulare che attraversa i confini di fiducia fra organizzazioni.

Verificabilità

Dove si fermano gli strumenti standard

I log di autenticazione si fermano all’organizzazione che li ha scritti. Le tracce di audit fra organizzazioni (chi ha avuto accesso a cosa, quando e con quale autorizzazione) richiedono un collegamento crittografico che l’autenticazione locale non offre.

Soluzione DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) produce tracce di audit in cui ogni manomissione risulta evidente. Ogni evento di identità è collegato crittograficamente e verificabile in modo indipendente, anche fra organizzazioni diverse.

Architettura di fiducia

Dove si fermano gli strumenti standard

Questi modelli presuppongono un’autorità centrale: un provider di identità di cui tutti si fidano. La fiducia istituzionale distribuita fra organizzazioni sovrane non può dipendere da un’unica autorità.

Soluzione DKMS / Verimesh

DKMS permette una gestione sovrana delle identità: ogni organizzazione controlla le proprie radici crittografiche. La fiducia si stabilisce in modo bilaterale, non delegata a un coordinatore centrale.

Mantenete il vostro provider di identità e aggiungete la fiducia fra istituzioni.

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organisational trust establishment
L’infrastruttura di identità KERI: identificatori autocertificanti, ricevute degli eventi di chiave e fiducia bilaterale senza autorità centrale

È una capacità nuova. Il vostro provider di identità, e i protocolli che lo sostengono (OpenID Connect, OAuth, SAML), sono collaudati per l’autenticazione all’interno di una singola organizzazione e restano dove sono. DKMS (sistema di gestione decentralizzata delle chiavi) fa ciò per cui non sono mai stati costruiti: dà a ogni organizzazione un’identità autocertificante che qualsiasi altra istituzione può verificare direttamente, senza un provider condiviso fra le due. Verimesh porta DKMS e dialoga con i sistemi che già gestite, così estendete ciò che avete invece di migrare altrove.

Costruire sui programmi nazionali di eID

Il programma swiyu è l’infrastruttura federale svizzera di identità elettronica. La sua prima credenziale, la licenza per allievo conducente elettronica, è attiva in tutti i cantoni da dicembre 2025, con circa 27.000 rilasci. La messa in esercizio dell’infrastruttura di fiducia per l’e-ID è prevista nel primo semestre 2027, mentre l’introduzione dell’e-ID è stata rinviata senza una nuova data annunciata. Gli identificatori degli emittenti e le dichiarazioni di fiducia sono pubblicati in registri federali centrali e la credenziale resta sul dispositivo del cittadino. La stessa infrastruttura dovrebbe portare credenziali di cantoni, università e datori di lavoro quando si aprirà agli emittenti generici.

Vereign partecipa al processo svizzero sull’e-ID dall’inizio, attraverso gli incontri di partecipazione e scambi bilaterali, e Georg Greve è stato membro del Technical Advisory Circle convocato da fedpol. Il lavoro di quel gruppo ha contribuito alla decisione tecnologica di gennaio 2024.

L’Unione europea segue la stessa strada. Il regolamento (UE) 2024/1183 impone a ogni Stato membro di offrire almeno un wallet europeo di identità digitale (EUDI Wallet) e la credenziale di identità di base proviene da fornitori designati dallo Stato. Entrambi i programmi rispondono alla stessa domanda, e lo fanno bene: come una persona dimostra a un’istituzione chi è. Nessuno dei due definisce l’identità di reparti, dispositivi, servizi e agenti che un’organizzazione gestisce davvero, ed entrambi ancorano la fiducia a registri centrali: per questo nessuno dei due tiene un registro delle relying party che verificano le credenziali, perché su scala europea sarebbero troppe da elencare.

Per chi adotta Verimesh, swiyu ed EUDI diventano una base su cui costruire. Oggi il ponte è progettato, non rilasciato: quando quei sistemi arriveranno in produzione, accetterete un e-ID statale in fase di onboarding, lo userete come radice di fiducia e lascerete che Verimesh porti quella fiducia attraverso le istituzioni, le giurisdizioni e i sistemi che un flusso di lavoro reale tocca, emettendo le vostre credenziali nello stesso wallet.

Verimesh realizza questa architettura

Verimesh (già progetto Stargate) è l’implementazione in produzione dell’architettura di fiducia descritta sopra. Funziona con l’autenticazione che già usate e aggiunge ciò per cui quello strato non è mai stato costruito: un’identità organizzativa radicata in DKMS per la fiducia fra istituzioni, un motore di policy programmabile (Open Policy Agent), un significato condiviso dei dati attraverso la Overlays Capture Architecture (OCA) e la consegna dei messaggi tramite SEAL, in cui qualsiasi manomissione risulta evidente.

Verimesh è in produzione nella sanità svizzera: il gateway e la CA centrale presso HIN sono in produzione, le prime istituzioni sono migrate e li utilizzano, e la migrazione dell’intera rete HIN è prevista entro la fine del 2026.

Scoprite Verimesh

Una sola identità organizzativa, fino al livello di rete.

Verimesh trasporta il traffico su WireGuard e la chiave del tunnel è radicata nella stessa identità organizzativa delle applicazioni che vi girano sopra. Le chiavi Curve25519 dei tunnel di ogni organizzazione derivano dal suo materiale di gestione decentralizzata delle chiavi (DKMS): nessuna autorità centrale le emette e non c’è scarto fra identità di rete e identità applicativa. La rotazione delle chiavi è coordinata con DKMS (la pre-rotazione si basa su KERI) e ogni tunnel stabilito è verificabile rispetto al key event log. Nessun intermediario possiede il flusso dei dati.

Silenzioso per progettazione

I pacchetti non autenticati non ricevono risposta. La mesh è invisibile a una scansione delle porte: non esiste una superficie di attacco pubblica da sondare.

Circa 4.000 righe che potete leggere

WireGuard è composto da circa 4.000 righe di codice, contro le circa 100.000 di OpenVPN e le 400.000 di IPsec. La verificabilità è essa stessa una proprietà di sicurezza.

Nessuna negoziazione, nessun downgrade

Algoritmi moderni e fissi: Curve25519, ChaCha20-Poly1305, BLAKE2s, l’handshake Noise_IKpsk2. La perfect forward secrecy, con rinnovo delle chiavi ogni due minuti circa, e l’occultamento dell’identità sono integrati, non da configurare.

Sovranità fino al trasporto

Open Source da un capo all’altro, in self-hosting, senza alcun control plane SaaS sul percorso. La sovranità si estende dall’applicazione fino al trasporto stesso.

Infrastruttura noiosa e collaudata

Nel kernel Linux mainline dal 2020. Non c’è nulla di nuovo nella crittografia impiegata e oggi sostiene il roll-out di Verimesh con HIN.

Pronta per la migrazione quantistica

Il livello di chiave pre-condivisa di WireGuard riduce già oggi l’esposizione del traffico agli attacchi store-now, decrypt-later. E poiché le chiavi dei tunnel derivano da DKMS, passare ad algoritmi post-quantistici è una normale rotazione di chiavi sul key event log esistente, non una riemissione in blocco.

Scoprite il ciclo di vita completo della connessione

DKMS esiste per far valere il consenso

L’articolo 71(8) dell’EHDS crea un vincolo strutturale che nessuna autorità centrale può soddisfare: quando una persona esercita l’opposizione all’uso secondario, quella revoca deve propagarsi a ogni istituzione che detiene i dati originali o ne deriva altri. Nessuna CA può controfirmare l’opposizione, nessun identity provider può propagare a cascata la revoca. Il vincolo è architetturalmente incompatibile con un’identità centralizzata.

DKMS soddisfa i cinque requisiti posti dall’articolo 71 dell’EHDS: identificatori specifici per persona che sopravvivono a una nuova registrazione; registrazioni di opposizione verificabili e con marca temporale, ancorate al Key Event Log; reversibilità senza re-identificazione; propagazione tra titolari senza accordi bilaterali fra ogni coppia di istituzioni; e non collegabilità fra la registrazione del consenso e i dati che essa riguarda.

Una volta comunicati i dati (in una rete ospedaliera, in un consorzio di ricerca o in una catena di enti paganti), un’opposizione successiva deve comunque raggiungere ogni titolare a valle. I key event log di DKMS propagano la revoca in modo crittografico: il KEL di ogni titolare è append-only e attestato da testimoni, quindi una revoca aggiunta al margine della persona è verificabile in ogni istituzione che detiene un dato derivato.

Leggete la tesi sull’architettura del consenso

Collaudato nella sanità svizzera: scelto per un’implementazione su scala nazionale

HIN (Health Info Net) è la rete svizzera di informazione sanitaria: collega ospedali, studi di medicina generale e specialisti oltre i confini cantonali. SEAL, il prodotto di ingresso su questo livello di fiducia, veicola già oltre 800.000 consegne verificate al mese. Verimesh è in produzione nella sanità svizzera: il gateway e la CA centrale presso HIN sono in produzione, le prime istituzioni sono migrate e li utilizzano, e la migrazione dell’intera rete HIN è prevista entro la fine del 2026.

HIN (Health Info Net)

800.000+

consegne verificate al mese

Architettura di fiducia: domande frequenti

Che cos’è DKMS?
DKMS (gestione decentralizzata delle chiavi) è la categoria di infrastruttura di identità in cui la fiducia crittografica è ancorata al margine dell’organizzazione, non in un’autorità di certificazione centrale. Ogni organizzazione controlla il proprio materiale crittografico e il proprio Key Event Log (KEL) append-only. Vereign ha co-fondato la DKMS Alliance per formalizzare DKMS come categoria accanto a PKI e OAuth.
In che cosa DKMS è diverso da PKI?
PKI ancora la fiducia in autorità di certificazione centrali, quindi la compromissione di una sola CA colpisce ogni soggetto che quella CA ha firmato. DKMS ancora la fiducia nel Key Event Log di ogni organizzazione: un guasto resta circoscritto a un solo controller, la rotazione delle chiavi è nativa e atomica grazie alla pre-rotation, e la fiducia fra giurisdizioni non richiede accordi di riconoscimento fra CA. DKMS è PKI al margine, senza il single point of failure.
DKMS sostituisce OAuth?
No. OAuth è la scelta giusta per i flussi di token locali dentro una singola organizzazione, e lì deve restare in uso. DKMS risolve un problema per cui OAuth non è mai stato progettato: stabilire una fiducia verificabile fra organizzazioni senza un intermediario condiviso. Mantenete il vostro provider di identità e aggiungete DKMS per la fiducia fra istituzioni.
DKMS è pronto per il post-quantistico?
Sì. DKMS tratta la rotazione delle chiavi come un’operazione di prima classe. Quando servono algoritmi post-quantistici, la migrazione diventa una normale rotazione di chiavi sul Key Event Log esistente, non una riemissione in blocco dei certificati. Con la pre-rotation di KERI la chiave successiva può usare qualsiasi algoritmo su cui il controller si impegna, schemi post-quantistici compresi, senza rompere le relazioni di fiducia esistenti.
Chi mantiene DKMS?
DKMS è una specifica aperta. La DKMS Alliance, co-fondata da Vereign, ne coordina la specifica. L’implementazione di riferimento di KERI (il protocollo su cui si basa DKMS) è mantenuta come Open Source dalla più ampia comunità KERI. Verimesh di Vereign è un’implementazione AGPLv3+ dello strato DKMS: il suo gateway e la CA centrale sono in produzione presso HIN, con i primi clienti migrati. SEAL è il sistema di consegna cifrata a sciame AGPLv3+ di Vereign ed è architetturalmente indipendente da DKMS.
DKMS richiede una blockchain?
No. DKMS usa Key Event Log (KEL) concatenati tramite hash per l’integrità append-only, ma senza livello di consenso, senza token e senza ledger distribuito. La scelta di evitare la blockchain è deliberata: un’infrastruttura regolamentata richiede una verifica deterministica, non una finalità probabilistica.
Vereign può aiutarvi nell’integrazione con il wallet swiyu o EUDI?
Sì a livello di progettazione, ma non ancora in produzione: oggi i componenti del ponte sono architetturali, non rilasciati. Quando quei sistemi saranno attivi, accetterete un e-ID statale (swiyu, EUDI) in fase di onboarding e lo userete come radice di fiducia, poi sarà Verimesh a portare quella fiducia più avanti: attraverso le istituzioni, le giurisdizioni e i sistemi che un flusso di lavoro reale tocca, comprese le persone, i ruoli e gli agenti che vi operano, e attraverso ciò che accade a una decisione sul consenso dopo la condivisione dei dati.
Vereign è un concorrente dei wallet nazionali?
No. Un wallet nazionale dà a una persona un’identità verificabile. Verimesh la dà a un’organizzazione, coprendo i reparti, i dispositivi, i servizi e gli agenti che gestisce: i due livelli sono diversi e si compongono, non si sovrappongono. Verimesh mantiene il proprio livello di fiducia ed è progettato per parlare i protocolli dei wallet al margine.
Il ponte tra Verimesh e swiyu o EUDI è in produzione?
No. I componenti del ponte (un provider OID4VCI/VP, l’esportazione delle credenziali, la mappatura degli identificatori) sono architetturali: dimostrati a livello di progettazione, non rilasciati. Verimesh, invece, è in produzione nella sanità svizzera: il gateway e la CA centrale presso HIN sono in produzione, le prime istituzioni sono migrate e li utilizzano, e la migrazione dell’intera rete HIN è prevista entro la fine del 2026.

Prenotate una revisione dell’architettura: mappiamo noi questo modello sui vostri confini di fiducia.

Questa architettura è in esercizio nella sanità svizzera su scala nazionale. Se valutate alternative all’identità centralizzata o pianificate uno scambio di dati fra organizzazioni, in una chiamata di 30 minuti vediamo come si applica al vostro ambiente.

Prenotate una revisione dell’architettura
Protezione dei dati svizzera Conforme al GDPR Open Source AGPLv3+ Hosting svizzero
Scoprite come funziona l’architettura, passo per passo