Firma elettronica qualificata esposta: le falle dell’eID belga e il perimetro che eIDAS non copre

La firma elettronica qualificata belga è rimasta esposta per mesi a causa di un’estensione browser con oltre due milioni di utenti, sviluppata da una società iscritta nella Trusted List europea come prestatore qualificato. Qualsiasi sito web poteva leggere i dati della carta d’identità elettronica dell’utente quando inserita nel lettore, indurlo a digitare il PIN in una finestra dal testo controllato dall’attaccante per poi ricavarlo in chiaro, e, sulle installazioni Windows, eseguire codice sulla sua macchina anche senza carta inserita. Le vulnerabilità, ora corrette, sono state presentate al DEF CON e mettono in discussione non tanto la qualificazione eIDAS in sé, quanto l’ampiezza del perimetro che essa certifica.

Che cosa è successo

Il software che fa da ponte fra il browser e la carta d’identità belga, e che produce con essa firme elettroniche qualificate, si è rivelato pilotabile da qualunque pagina web. Il gruppo di ricerca di Bay Area Labs, società fondata da James Arnott, ha reso pubblici il 7 agosto 2026, in concomitanza con l’intervento al DEF CON di Las Vegas, i dettagli tecnici di una serie di vulnerabilità nel sistema di firma Connective, sviluppato dall’omonima società belga e oggi in capo a Nitro Software Belgium, nell’analisi tecnica originale.

Il sistema si compone di due elementi: un’estensione per browser, distribuita per i principali browser (Chrome, Edge, Firefox e Safari), e un componente nativo installato sul sistema operativo, disponibile per Windows e macOS, che dialoga direttamente con i lettori di smart card collegati alla macchina. L’estensione funge da semplice canale di inoltro fra le pagine web e il componente nativo, che a sua volta esegue le operazioni sulla carta: lettura dei dati, verifica del PIN, calcolo della firma.

Sulla diffusione conviene essere precisi, perché il dato circola in forma imprecisa. I ricercatori parlano di oltre due milioni di utenti attivi settimanali, cifra che dichiarano di avere verificato direttamente sulle schede pubbliche dell’estensione, le sole due che espongono un conteggio: Chrome Web Store e vetrina Edge. Il dato ricorrente di otto delle dieci maggiori banche belghe e oltre sessanta amministrazioni pubbliche compare invece, con questa esatta formulazione, nel comunicato del 10 novembre 2021 con cui Nitro annunciò l’acquisizione di Connective, dove si riferisce alla base clienti complessiva della società in Europa, oltre mille clienti fra mid-market, imprese e amministrazioni, non specificamente all’estensione. Il gruppo di ricerca lo riprende dichiarando espressamente di non poterne verificare l’estensione al componente vulnerabile.

Una precisazione di trasparenza, dichiarata dagli stessi autori: la ricerca è nata come banco di prova di una piattaforma commerciale di analisi automatizzata delle estensioni e dei relativi componenti nativi, che la società offre sul mercato.

L’errore di progettazione: nessuna nozione di origine

Il difetto strutturale è tanto elementare quanto devastante. L’estensione non trasmetteva al componente nativo l’origine della richiesta, cioè il dominio della pagina che stava chiedendo un’operazione. Il programma installato sul computer, in altre parole, non aveva alcun modo di sapere con quale sito stesse parlando.

Esisteva formalmente un meccanismo di autorizzazione: un token di attivazione firmato con RSA a 2048 bit, rilasciato ai siti partner per abilitare l’uso del sistema sulla macchina dell’utente. Decodificandolo, i ricercatori hanno però constatato che il token conteneva soltanto un identificativo privo di funzione osservabile, una scadenza e una maschera di bit relativa alle operazioni abilitate. Nessun vincolo all’origine. Un token ottenuto da un servizio legittimo poteva quindi essere riutilizzato da qualunque altra pagina, iframe o annuncio pubblicitario, ottenendo lo stesso livello di accesso. I ricercatori riferiscono di averli reperiti da Doccle, la piattaforma documentale usata in Belgio per la ricezione di fatture e documenti, con tutte le operazioni abilitate e validità di ventiquattro ore.

Da qui discende la prima conseguenza: qualsiasi sito, o qualsiasi frame incorporato in un sito, poteva leggere silenziosamente i dati della carta d’identità elettronica e della carta di pagamento Maestro, storicamente co-marchiata Bancontact in Belgio, inserite nel lettore, senza consenso né consapevolezza dell’utente. Va ricordato che dal 1° luglio 2023 in Europa non vengono più emesse nuove carte Maestro, sostituite alla scadenza da Debit Mastercard o Visa Debit: le carte con quel circuito ancora in circolazione resteranno operative al più fino al 2027.

Il PIN restituito alla pagina, con la chiave per decifrarlo

La seconda conseguenza riguarda il PIN. Il comando di verifica accettava dalla pagina web il titolo e il testo della finestra di dialogo nativa mostrata all’utente. La finestra era in tutto identica a quella di un’applicazione legittima e non indicava il dominio richiedente: nessun elemento consentiva a chi la vedeva di distinguere una richiesta autentica da una fraudolenta. Il phishing del PIN diventava così un’operazione banale.

Il punto più grave, però, riguarda ciò che accadeva dopo l’inserimento. Il componente nativo restituiva alla pagina un token relativo al PIN che, all’analisi, si è rivelato contenere sia il testo cifrato sia la chiave AES a 128 bit necessaria a decifrarlo, con un vettore di inizializzazione fisso codificato nel binario. Il PIN, in sostanza, era ricavabile in chiaro dal token stesso. Ottenuto una volta il PIN, un attaccante poteva generare autonomamente nuovi token e utilizzare la carta ogni volta che questa si trovava inserita nel lettore.

È il passaggio che rende l’incidente sistemico. La carta non lascia mai il lettore e le chiavi non lasciano mai il chip, ma il possesso del PIN unito alla capacità di inviare comandi alla carta equivale, sul piano pratico, ad avere la carta in mano, con un raggio d’azione più ampio, perché l’attacco funziona da un iframe e non richiede che la vittima visiti volontariamente un sito ostile.

L’esecuzione di codice: un parametro di troppo

Il risultato che gli stessi ricercatori considerano il più grave riguarda però un’altra strada, indipendente dalla presenza della carta nel lettore, come sottolinea anche la ricostruzione di SecurityWeek. Questa seconda catena sfrutta il meccanismo di caricamento delle librerie dinamiche di Microsoft e riguarda quindi le installazioni su Windows, non quelle su macOS.

Il comando che restituisce l’elenco dei lettori accettava dalla pagina web un parametro con il percorso della libreria da caricare, ammettendo anche percorsi relativi. L’unico vincolo era la presenza della sequenza .dll nel percorso. Poiché il browser segnala e ostacola il download diretto di file con quell’estensione, i ricercatori hanno aggirato il controllo con un file polyglot il cui nome contiene la sequenza in posizione interna, mascherato da normale documento. Trovandosi il software installato sotto la cartella dei dati applicativi dell’utente, bastava risalire con un percorso relativo fino alla cartella dei download per fare caricare ed eseguire la libreria.

L’esito è l’esecuzione di codice a livello utente, con uscita dalla sandbox del browser, senza che alla vittima sia richiesta alcuna azione consapevolmente rischiosa: dal suo punto di vista si scarica un documento e si visita una pagina. I ricercatori segnalano inoltre che nulla impediva, in linea teorica, una propagazione a catena, sottraendo i token di sessione e recapitando il collegamento ad altri utenti dell’estensione.

Vale la pena registrare, sul piano del metodo, che gli autori dichiarano di avere individuato le vulnerabilità con l’ausilio di modelli linguistici di grandi dimensioni impiegati nella loro piattaforma di analisi, indicando espressamente le versioni di Claude Opus utilizzate, pur sostenendo nello stesso passaggio che nessuna delle scoperte richiedeva strumenti di quel tipo, ma soltanto ingegneri di sicurezza competenti che guardassero il codice.

Firma elettronica qualificata: dall’identità alla sottoscrizione con valore legale

La chiave di non ripudio della carta belga produce firme elettroniche qualificate ai sensi del regolamento eIDAS, giuridicamente equiparate alla sottoscrizione autografa e destinate a un ruolo ancora più centrale con l’identità digitale europea. L’equiparazione discende dall’articolo 25, paragrafo 2 del regolamento, e nell’ordinamento italiano trova riscontro nell’articolo 20 del Codice dell’amministrazione digitale, che al documento sottoscritto con firma qualificata attribuisce l’efficacia probatoria dell’articolo 2702 del codice civile. La conseguenza pratica, evidenziata dai ricercatori, è che chi subisce una firma falsificata si trova nella posizione processuale più scomoda: è lui a dover attivare la contestazione e a doverne sostenere l’onere.

I ricercatori osservano inoltre che i file presenti sul chip, firmati dal Registro nazionale, contengono nome completo, numero di registro nazionale e indirizzo. Un attaccante non otteneva dunque soltanto dati anagrafici, ma una copia attestata dallo Stato di quei dati, unita alla capacità di firmare documenti con valore legale pieno.

Ne discende un effetto a cascata sull’intero ecosistema. Il gruppo riporta di avere dimostrato l’acquisizione di un account sul portale governativo CSAM.be, che si autentica tramite eID. Sul provider di identità itsme, utilizzato in Belgio per l’accesso a home banking, dichiarazione dei redditi e servizi previdenziali, i ricercatori descrivono uno scenario di takeover basato sulla combinazione fra creazione dell’account tramite firma con eID e procedure di blocco e riattivazione documentate dal provider stesso, precisando però di non averlo verificato sperimentalmente.

Il punto editorialmente più significativo è un altro: né itsme né CSAM.be presentavano difetti nei rispettivi software. Lo schema di identificazione elettronica belga di cui itsme fa parte è notificato ai sensi di eIDAS con livello di garanzia “elevato”, il più alto previsto, come risulta dalla notifica pubblicata nella Gazzetta ufficiale dell’Unione europea nel dicembre 2019; la stessa società che gestisce itsme è a sua volta prestatore qualificato di servizi fiduciari. La loro esposizione derivava dalla fiducia riposta in un componente a monte. Va detto, per completezza, che lo scenario descritto per itsme poggia anche su due elementi delle procedure del provider, che gli stessi ricercatori discutono criticamente: il blocco di un account non richiede alcuna autenticazione, e un account non attivo può essere riattivato tramite firma con eID associandolo a un nuovo numero di telefono.

Centoquarantasei giorni, nessun CVE, duecento dollari

La gestione della segnalazione merita di essere ricostruita, perché è la parte che interroga più direttamente il quadro regolatorio.

Un primo intervento correttivo è stato rilasciato l’8 maggio 2026, introducendo una verifica dell’origine tramite un server remoto. Era una correzione parziale: non toccava l’esecuzione di codice né la restituzione del token del PIN alla pagina, limitandosi a restringere l’insieme dei siti in grado di sfruttarli. Il 19 maggio il fornitore ha chiesto di posticipare la divulgazione per consentire l’aggiornamento delle installazioni presso i clienti in locale; nello stesso giorno i ricercatori hanno segnalato l’incompletezza della correzione, indicando le modifiche necessarie.

La correzione completa è arrivata il 1° giugno, con la disabilitazione del comando che consentiva il caricamento di librerie arbitrarie e con lo spostamento della gestione del token del PIN all’interno dell’estensione, sostituendo il dato sensibile con un identificativo casuale. L’applicazione effettiva dei controlli sull’origine è stata completata il 22 luglio; l’ultimo aggiornamento dell’estensione pubblicato sul Chrome Web Store risale al 29 luglio. I ricercatori quantificano in centoquarantasei giorni l’intervallo fra la prima segnalazione e la correzione, senza rendere pubblica la data della segnalazione iniziale. Non risultano assegnati identificativi CVE. Al ricercatore è stata offerta una ricompensa di duecento dollari.

Va detto, per completezza, che il fornitore disponeva di un canale dedicato alle segnalazioni di sicurezza, ha risposto, non ha subordinato il dialogo alla firma di accordi di riservatezza e ha infine corretto i difetti. Non ha invece dato riscontro alla richiesta di commento avanzata dalla stampa specializzata. La pubblicazione è avvenuta con il benestare del Centre for Cybersecurity Belgium, nell’ambito della clausola di esenzione da responsabilità penale, a determinate condizioni, prevista dal quadro nazionale belga per la divulgazione coordinata: benestare che gli autori dichiarano di non avere ritenuto strettamente necessario. Contestualmente all’articolo tecnico, gli autori dichiarano di avere reso pubblico anche il codice di sfruttamento delle vulnerabilità: un elemento da tenere presente per le installazioni in locale che non avessero completato l’aggiornamento.

Alla data del 10 agosto 2026 non risultano dichiarazioni pubbliche del fornitore, del provider itsme, dell’amministrazione responsabile del portale CSAM.be o del Centre for Cybersecurity Belgium sulla vicenda.

La domanda che riguarda anche noi

Qui la vicenda va letta con precisione, perché è facile trarne la conclusione sbagliata. Nitro Software Belgium figura effettivamente nella Trusted List europea come prestatore qualificato, ma il servizio iscritto è un servizio qualificato di validazione delle firme elettroniche qualificate, come risulta dalla stessa documentazione di conformità della società e dal certificato eIDAS LSTI che ne attesta la conformità. L’estensione e il componente nativo, cioè esattamente il software che dialoga con la carta e raccoglie il PIN, non rientrano nel perimetro qualificato e non costituiscono oggetto degli audit periodici di conformità che il regolamento impone ai prestatori qualificati, condotti da organismi di valutazione accreditati con cadenza almeno biennale ai sensi dell’articolo 20, paragrafo 1, del regolamento 910/2014.

Il dettaglio più istruttivo sta proprio dentro quel certificato. Il documento in vigore, numero 980, è stato emesso il 5 giugno 2025 sulla base di una valutazione di conformità del 17 marzo 2025, ha validità fino al 4 giugno 2027 e fissa al 16 marzo 2027 la successiva valutazione. Dichiara la conformità al regolamento (UE) 2024/1183, cioè alla versione riformata di eIDAS, e cita fra le norme applicate la EN 319 401 nella versione 3.1.1, che incorpora i requisiti di cibersicurezza della direttiva NIS2, in particolare quelli dell’articolo 21. Il quadro è completato dal regolamento di esecuzione (UE) 2025/1942 sui servizi di validazione qualificati e dal regolamento di esecuzione (UE) 2025/2162 sull’accreditamento degli organismi di valutazione.

In altre parole: il prestatore è stato valutato, di recente e su uno standard che già assorbe gli obblighi di gestione del rischio della NIS2. Il software che raccoglieva il PIN degli utenti non era però l’oggetto di quella valutazione.

Il problema, dunque, non è che l’audit abbia mancato il bersaglio: è che il bersaglio non era nel poligono. La fiducia che il marchio di qualificazione genera sul mercato è più ampia del perimetro che la qualificazione certifica, e nel mezzo resta il client, cioè il punto in cui l’utente incontra materialmente la propria identità digitale. Vale la pena aggiungere che il fornitore dichiarava sul proprio sito, in una versione archiviata risalente al 2022, di sottoporre il software a test di penetrazione annuali: un impegno volontario, non un obbligo regolamentare, e questo è precisamente il punto.

La conclusione dei ricercatori è netta: serve un obbligo normativo esplicito di test di sicurezza tecnicamente competenti in capo ai prestatori qualificati, perché l’assetto attuale rischia di certificare processi anziché prodotti.

È qui che la vicenda cessa di essere belga. Il modello architetturale colpito, un’estensione browser che fa da ponte verso un componente nativo con accesso al lettore di smart card, è lo stesso adottato in tutta Europa per l’interazione fra browser e carte di identità o dispositivi di firma, Italia inclusa. Nessun elemento agli atti indica che prodotti italiani siano interessati da queste specifiche vulnerabilità, e non risultano segnalazioni in tal senso. Ma la classe di difetto è generale, e i ricercatori affermano di avere individuato problematiche analoghe in altre estensioni della stessa famiglia, alcune delle quali interessano un numero elevato di istituti bancari.

Per il lettore italiano restano tre implicazioni concrete. La prima riguarda il Cyber Resilience Act: un’estensione con componente nativo ricade con ogni probabilità nella nozione di prodotto con elementi digitali, e come tale nei requisiti di sicurezza per progettazione e di gestione delle vulnerabilità, applicabili dall’11 dicembre 2027, mentre l’obbligo di segnalazione delle vulnerabilità attivamente sfruttate decorre dall’11 settembre 2026. La seconda riguarda NIS2, che colloca i prestatori di servizi fiduciari fra i soggetti dell’infrastruttura digitale dell’allegato I e qualifica quelli qualificati come soggetti essenziali a prescindere dalla dimensione. La terza riguarda DORA e la gestione del rischio derivante da terze parti: se il dato del 2021 sulla diffusione presso la maggioranza delle grandi banche belghe fosse ancora attuale, si tratterebbe di una concentrazione di rischio che nessuna delle entità coinvolte controlla direttamente, e che il regolamento chiede a ciascuna di mappare e presidiare, con un regime distinto e ulteriore per i fornitori designati come critici a livello europeo.

La qualificazione eIDAS produce fiducia. La domanda che questa ricerca lascia aperta è se quella fiducia sia oggi accompagnata da una verifica tecnica proporzionata alle conseguenze giuridiche che essa abilita, e se il suo perimetro coincida con quello che il mercato le attribuisce.