In questo articolo Indice dei contenuti 3 sezioni
Carta d’identità elettronica nel mirino: un’estensione per il browser installata su oltre 2 milioni di sistemi, pensata per collegare le applicazioni web alla eID belga, poteva trasformare una semplice pagina Internet in una porta d’ingresso verso dati personali, PIN e persino il PC Windows di chi la utilizzava. A raccontare la storia è stata la ricerca portata a DEF CON 34 da Bay Area Labs, tutta concentrata su Connective Signing Extension, componente riconducibile a Nitro Software Belgium. Un caso che merita attenzione perché tocca uno dei punti più delicati della sicurezza digitale, ovvero il ponte tra browser e dispositivi crittografici locali.
I numeri aiutano a capire la portata della faccenda. Secondo i dati commerciali diffusi in passato da Connective e ripresi dai ricercatori, questa tecnologia arrivava a 8 delle 10 maggiori banche belghe, oltre 60 servizi di enti pubblici e più di 1.000 aziende. Non un dettaglio da poco, considerato che qui entra in gioco anche la fiducia costruita attorno alle firme elettroniche europee. Il regolamento eIDAS, introdotto nel 2014 e poi aggiornato, assegna alla firma elettronica qualificata lo stesso valore giuridico di quella autografa in tutti gli Stati membri. E Nitro Software Belgium compare proprio nella Trusted List eIDAS come prestatore qualificato. Un baco nel software che collega browser, carta e operazioni di firma non riguarda quindi solo la riservatezza dei dati, ma può indebolire il confine tecnico su cui poggia una transazione con effetti legali reali.
Come funzionava il collegamento tra browser e carta
Per capire quanto fossero serie queste falle bisogna guardare all’architettura. Connective Signing non lavorava soltanto dentro il browser: c’erano due elementi distinti, un’estensione e un programma nativo installato sul computer. La prima riceveva le richieste dalle pagine web e le passava al secondo, che a sua volta dialogava con i lettori di smart card e con dispositivi come la carta d’identità elettronica belga. In Italia, giusto per intenderci, si parla di CIE e CieID.
È un modello previsto dai browser Chromium tramite il meccanismo Native Messaging. Chrome, in pratica, consente a un’estensione con i permessi giusti di avviare o contattare un’applicazione locale scambiando messaggi JSON. Il problema, però, stava nel modo in cui Connective autorizzava le operazioni più delicate. Il native host richiedeva un activationToken firmato con RSA a 2048 bit, contenente un UUID, una scadenza e una bitmask che indicava quali funzioni si potevano usare. La firma però garantiva solo che il token fosse autentico, non stabiliva quale dominio web avesse il diritto di usarlo. Risultato: un token valido ottenuto da un servizio autorizzato poteva essere riciclato da un’altra pagina, magari incorporata in un iframe su un sito qualunque.
La faccenda peggiorava con il pinToken. Quando l’utente digitava il PIN nella finestra nativa, il valore veniva cifrato con AES-128, ma il token restituito conteneva anche tutto il necessario per ricostruire la chiave. Decodificando i 48 byte in Base64 si potevano ricavare i primi 32 byte per la chiave e decifrare gli ultimi 16. In pratica il PIN era cifrato, ma la struttura stessa forniva già il grimaldello. E titolo e messaggio della finestra potevano essere controllati dalla pagina, rendendo credibile un finto prompt bancario.
Dal browser fino a Windows
La vulnerabilità più grave permetteva di scavalcare 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, e il percorso poteva includere sequenze relative come “……..” senza alcuna limitazione a librerie fidate. Un sito poteva così far scaricare sul PC un file controllato dall’attaccante e poi indicarne il percorso al processo Connective. A quel punto entrava in scena LoadLibrary, che su Windows non si limita a leggere la DLL ma la carica in memoria ed esegue il suo codice di inizializzazione. I ricercatori hanno pure mostrato come aggirare i controlli di Chrome sui download .dll con un file poliglotta camuffato da PDF.
Il punto decisivo è questo: la pagina non eseguiva direttamente il file e l’utente non doveva cliccare nulla. Era il native host, già fuori dalla sandbox del browser, a caricare la libreria coi privilegi dell’utente. Per questo si parla di drive-by RCE. Serviva comunque che estensione e componente fossero installati, quindi non era un difetto generale di Chrome o Windows né delle carte.
Le correzioni sono arrivate a scaglioni. Nitro ha iniziato a intervenire l’8 maggio 2026 con un controllo sull’origine web, che però non risolveva né la Remote Code Execution né il pinToken. Il 1° giugno è arrivata la patch più importante: niente più DLL scelte a piacere dalla pagina, e PIN gestito dentro l’estensione, con al sito restituito solo un UUID casuale. Dal 22 luglio il controllo sui domini autorizzati è diventato obbligatorio.
E in Italia come stanno le cose
Il confronto con l’Italia è interessante, perché anche la CIE può richiedere un componente sul computer. Per usarla con un lettore NFC il Ministero dell’Interno distribuisce il Middleware CIE, ma l’architettura è diversa da quella di Connective. Il middleware italiano si appoggia a interfacce crittografiche standard come PKCS#11 e, su Windows, al modello CSP/Smart Card Minidriver, mentre la libreria CIEPKI.dll espone agli applicativi il certificato di autenticazione. Con Chrome, Edge e Opera l’accesso non richiede un’estensione paragonabile a Connective dopo l’abbinamento della carta.
Per gli accessi CIE di livello 1 e 2 la carta fisica non serve nemmeno a ogni autenticazione, bastano credenziali e magari un secondo fattore come OTP o QR code, mentre il livello 3 resta quello che richiede la CIE fisica. Un’impostazione simile vale anche per CNS e molti dispositivi italiani di firma digitale. Questo non vuol dire che il modello italiano sia a prova di bomba: driver, moduli PKCS#11 e software locali restano componenti privilegiati da tenere aggiornati. La differenza sta nel fatto che il guaio belga nasceva soprattutto da un ponte troppo permissivo tra pagina web, estensione e un programma nativo capace di operare sul PC.
