Carta d'identità elettronica a rischio: una falla esponeva 2 milioni di PC

Un’estensione per il browser installata su oltre 2 milioni di sistemi, impiegata per collegare le applicazioni web alla carta d’identità elettronica (eID) belga, poteva trasformare una normale pagina Internet in un punto di accesso a dati personali, PIN e perfino al PC Windows dell’utente. La ricerca presentata da Bay Area Labs a DEF CON 34 riguarda Connective Signing Extension, componente riconducibile a Nitro Software Belgium. I problemi descritti dai ricercatori meritano un’analisi attenta perché coinvolgono uno dei passaggi più delicati della sicurezza digitale: il ponte tra browser e dispositivi crittografici locali.

Secondo i dati commerciali pubblicati in passato da Connective e ripresi dai ricercatori, la tecnologia raggiungeva 8 delle 10 maggiori banche belghe, oltre 60 servizi di organizzazioni pubbliche e più di 1.000 imprese.

La questione tocca inoltre la fiducia costruita attorno alle firme elettroniche europee. Il regolamento eIDAS, introdotto nel 2014 e successivamente aggiornato, attribuisce alla firma elettronica qualificata lo stesso effetto giuridico di una firma autografa negli Stati membri dell’Unione Europea. Nitro Software Belgium compare nella Trusted List eIDAS come prestatore qualificato di servizi fiduciari. Un errore nel software che collega browser, carta e operazioni di firma non riguarda soltanto la riservatezza dei dati: può indebolire il confine tecnico sul quale poggia una transazione con conseguenze giuridiche concrete.

Come funziona il collegamento tra browser, applicazione nativa e carta d’identità elettronica

Per capire la gravità delle falle bisogna guardare all’architettura. Connective Signing non lavorava soltanto all’interno del browser: il sistema comprendeva due elementi distinti, ovvero un’estensione e un programma nativo installato sul computer. La prima riceveva le richieste provenienti dalle pagine web e le inoltrava al secondo; il processo nativo poteva quindi dialogare con i lettori di smart card e con dispositivi come la carta d’identità elettronica belga (in Italia si parla di CIE e CieID).

È un modello previsto espressamente dai browser Chromium attraverso il meccanismo Native Messaging. Chrome consente a un’estensione dotata del permesso appropriato di avviare o contattare un’applicazione locale mediante messaggi JSON scambiati attraverso stdin e stdout.

Token, PIN e controlli sull’origine: dove si rompeva la sicurezza

Nel caso della gestione delle carte d’identità elettroniche belghe, il primo problema riguardava il modo in cui Connective autorizzava le operazioni più sensibili.

Il native host (programma locale installato sul PC con cui l’estensione del browser comunica per accedere a funzioni e dispositivi che il browser, da solo, non può raggiungere) richiedeva un activationToken firmato con RSA a 2048 bit, contenente un UUID, una scadenza e una bitmask che indicava quali funzioni potevano essere utilizzate: lettura delle carte, verifica del PIN, generazione delle firme e altre operazioni.

La firma crittografica garantiva però soltanto che il token fosse autentico e non alterato; non stabiliva quale dominio web avesse diritto a usarlo. Un token valido ottenuto da un servizio autorizzato poteva essere riutilizzato da un’altra pagina, perché il componente locale non disponeva di un vincolo affidabile tra token e origine web.

Da qui la possibilità di interrogare eID e carte Maestro inserite nel lettore, anche tramite iframe incorporati in altri siti.

Il problema diventava ancora più serio con il pinToken: quando l’utente digitava il PIN nella finestra nativa di Connective, il valore veniva cifrato con AES-128, ma il token restituito alla pagina conteneva anche il materiale necessario per ricostruire la chiave. I ricercatori hanno mostrato che, decodificando il valore Base64 di 48 byte, era possibile derivare la chiave dai primi 32 byte e decifrare gli ultimi 16 byte.

In sostanza, il PIN era cifrato ma la stessa struttura forniva anche ciò che serviva per recuperarlo. Inoltre titolo e messaggio della finestra che chiedeva il codice potevano essere controllati dalla pagina, rendendo credibile un prompt apparentemente proveniente da una banca o da un servizio pubblico.

Dal browser a Windows: come si arrivava all’esecuzione di codice da remoto (RCE)

La vulnerabilità più grave permetteva invece di superare il confine tra browser e sistema operativo.

Il comando GET_READERS del native host accettava un parametro chiamato library che indicava una DLL da caricare; il percorso poteva includere sequenze relative come “..\..\..\..” e non risultava limitato a un elenco di librerie fidate.

Un sito poteva quindi far scaricare sul PC un file controllato dall’attaccante e indicarne successivamente il percorso al processo Connective. A quel punto entrava in gioco LoadLibrary: su Windows non si limita a leggere una DLL come un normale file, ma la mappa nello spazio di memoria del processo ed esegue il relativo codice di inizializzazione.

I ricercatori hanno inoltre mostrato un modo per aggirare i controlli di Chrome sui download con estensione .dll usando un file poliglotta dal nome apparentemente riconducibile a un PDF; tramite il path traversal, Connective poteva poi raggiungerlo nella cartella Downloads.

Il passaggio decisivo è proprio questo: la pagina web non eseguiva direttamente il file e l’utente non doveva fare doppio clic. Era il native host, già autorizzato a operare fuori dalla sandbox del browser, a caricare la libreria e a eseguirne il codice con i privilegi dell’utente. Per tale ragione gli autori parlano di drive-by RCE.

L’attacco richiedeva comunque che estensione e componente Connective fossero installati e raggiungibili: non era quindi una vulnerabilità generale di Chrome o Windows, né un difetto intrinseco delle carte d’identità elettroniche.

Com’è arrivata la correzione delle falle di sicurezza

Le vulnerabilità descritte da Bay Area Labs non sono rimaste in essere fino alla pubblicazione della ricerca, in questi giorni.

Nitro ha iniziato a intervenire l’8 maggio 2026 introducendo un controllo sull’origine web autorizzata a impartire comandi, ma la prima modifica non risolveva né la Remote Code Execution né il problema del pinToken. Dopo una nuova segnalazione dei ricercatori, il 1° giugno scorso è arrivata la correzione più importante: il software non consentiva più alla pagina di specificare arbitrariamente la DLL da caricare e il PIN rimaneva gestito all’interno dell’estensione.

Al sito veniva restituito soltanto un UUID casuale che identificava l’operazione, non il token contenente il materiale necessario per ricostruire il codice segreto.

Dal 22 luglio il controllo remoto sui domini autorizzati è diventato inoltre obbligatorio, impedendo ai siti non approvati di sfruttare silenziosamente il collegamento tra browser e componente locale.

La conclusione, tuttavia, è molto importante: una smart card può proteggere perfettamente la chiave privata, ma la sicurezza complessiva crolla se il software che le impartisce i comandi accetta richieste da pagine che non dovrebbe considerare attendibili.

E in Italia? CIE e firma digitale usano un’impostazione diversa

Il confronto con l’Italia è interessante perché anche la CIE può richiedere un componente installato sul computer.

Per utilizzare la CIE con un lettore NFC, il Ministero dell’Interno distribuisce infatti il Middleware CIE, cioè il software che consente alle applicazioni di dialogare con il chip della carta. L’architettura, però, è diversa da quella mostrata nel caso Connective: il middleware italiano implementa interfacce crittografiche standard come PKCS#11 e, su Windows, il modello CSP/Smart Card Minidriver; la libreria CIEPKI.dll espone agli applicativi il certificato di autenticazione e le operazioni consentite dalla chiave privata custodita nella carta.

Con Chrome, Edge e Opera l’accesso tramite CIE non richiede inoltre una specifica estensione del browser paragonabile a Connective Signing Extension dopo l’abbinamento della carta.

Per gli accessi CIE di livello 1 e 2 la carta fisica non deve neppure essere letta a ogni autenticazione: possono bastare credenziali e, quando previsto, un secondo fattore come OTP o QR code; il livello 3 resta invece quello che richiede la CIE fisica. Un’impostazione analoga basata su middleware e smart card esiste anche per CNS e molti dispositivi italiani di firma digitale.

Ciò non significa che il modello italiano sia immune da vulnerabilità: driver, moduli PKCS#11, applicazioni di firma e software locali restano componenti privilegiati da mantenere aggiornati. La differenza importante è che il problema belga nasceva soprattutto da un ponte molto permissivo tra una pagina web, un’estensione e un programma nativo capace di eseguire operazioni sul PC.