Il 16 aprile 2026, a poche ore dal lancio ufficiale, l'app europea di verifica dell'età per i minori online è stata aggirata completamente in meno di due minuti. Non da un gruppo di ricercatori avanzati, non con exploit zero-day. Con un editor di testo su un file XML.
Il consulente di sicurezza britannico Paul Moore ha pubblicato su X una dimostrazione live che ha raggiunto 2,6 milioni di visualizzazioni. La Commissione Europea ha risposto definendo la versione bucata "una demo". Il repository GitHub conteneva già un disclaimer: standard di sicurezza "lower than final releases", sconsigliato per produzione. L'app era stata lanciata dalla presidente von der Leyen come strumento pilota in 5 paesi, Italia compresa. Il punto non è che l'implementazione aveva dei bug — è che l'architettura era sbagliata strutturalmente. Il bypass ne è la prova tecnica, non la causa.
Questo post analizza cosa non ha funzionato, perché un'alternativa decentralizzata basata su zero-knowledge proof è diversa non solo nel dettaglio ma nel paradigma, e cosa significa per chi gestisce infrastruttura in Italia — entro il 30 giugno 2026, data entro cui il mini-portafoglio di verifica età dovrà essere disponibile per i social network. Se ti interessa capire come la verifica età online dei minori arriverà a toccare chiunque operi servizi pubblici con un proprio homelab, hai il contesto giusto.
Il contratto di sviluppo dell'app — aggiudicato a Scytáles AB (Svezia) e Deutsche Telekom — vale tra 1,99 e 4 milioni di euro secondo le fonti disponibili (la discrepanza riflette tender stimato vs assegnazione reale su lotti multipli). L'app è il primo use case concreto del framework EUDI Wallet, che eIDAS 2.0 richiede a tutti gli stati EU di implementare entro fine 2026.
Moore ha identificato tre vulnerabilità distinte, tutte nel file shared_prefs/eudi-wallet.xml — un file di preferenze Android accessibile tramite backup locale senza permessi root su dispositivi non protetti.
PIN cifrato ma disaccoppiato dal vault identità: cancellando i valori PinEnc e PinIV dal file XML, il PIN viene resettato — l'identità verificata rimane valida
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Cybersecurity
AIWALL: 16 giorni in produzione — cosa ha bloccato, cosa ha sbagliato, cosa ho corretto
Diario tecnico onesto: 16 giorni di AIWALL in produzione. 1.460 query DNS bloccate, un evento CRITICAL reale con alert Telegram, un falso positivo DGA su
Rate limiter bypassabile: il contatore dei tentativi falliti è un semplice intero nel file XML — azzerarlo rimuove qualsiasi protezione brute-force
Autenticazione biometrica disattivabile: il boolean flag UseBiometricAuth impostato a false disabilita completamente il secondo fattore
Tre falle indipendenti. Tutte dello stesso tipo: logica di sicurezza gestita client-side, in uno store non protetto, senza verifica server-side dello stato. Moore ha definito l'approccio "a really poor design" — non un errore di implementazione isolato, ma una scelta architetturale.
Seriously, Von der Leyen – this product will be the catalyst for an enormous breach at some point. It's just a matter of time. — Paul Moore, cybernews.com
La risposta ufficiale della Commissione — tramite il portavoce Thomas Regnier — ha mescolato due argomenti. Quello trasparente: "Why did we decide to have it open source: to be transparent and to allow, indeed, for the community, for developers to test it, to play with it, to potentially help us to improve it." Quello difensivo: la versione bucata era "a demo version", non il prodotto finale. Il problema è che l'app era in deployment pilota attivo con minori reali in 5 paesi. "Demo" e "pilota di produzione" sono categorie mutuamente esclusive.
Non è un dettaglio minore. Se il team di sviluppo aveva inserito quel disclaimer, significa che la decisione di procedere al lancio pilota era una scelta politica consapevole — non un errore di valutazione tecnica. Oltre 400 esperti avevano firmato un appello per sospendere il deployment prima del lancio. La europarlamentare Gregorová aveva denunciato che il progetto veniva "rushed under political pressure".
Design centralizzato vs decentralizzato: dove fallisce ogni approccio
Il bypass di Moore è la superficie visibile. Sotto c'è un problema architetturale che nessuna patch risolve. Confrontare i due paradigmi con i dati concreti serve a capire perché la Commissione ha scelto l'approccio più debole — e perché l'alternativa ha i propri limiti non dichiarati.
Approccio centralizzato: device trust come fondamenta di sabbia
L'architettura dell'app EU funziona così: il provider di identità (stato membro) emette una credential verificata. L'app la archivia sul dispositivo. Quando un sito richiede verifica età, l'app presenta la credential. Il sito si fida dell'app. L'app si fida del dispositivo.
Il punto di rottura è l'ultimo anello. Tutta la sicurezza dell'identità digitale è delegata all'integrità del sistema operativo di un hardware consumer. Su Android, la soluzione tecnica è Play Integrity — che richiede un OS certificato da Google, closed source, come condizione per la sicurezza. Su iOS, l'equivalente è DeviceCheck di Apple. La Commissione EU ha costruito il proprio sistema di identità digitale sopra un'infrastruttura di fiducia che appartiene a due aziende private americane — non come layer aggiuntivo, ma come fondamenta.
A questo si aggiunge il problema della trasferibilità della credential, segnalato dal criptografo Olivier Blazy: "My nephew can take my phone, unlock my app and use it to prove he is over 18." La credential è legata al dispositivo fisico, non all'identità biologica. Chiunque abbia accesso al telefono sbloccato ha accesso alla verifica età. La biometrica che dovrebbe proteggerla era — come dimostrato — un boolean flag.
Tibor Jager dell'Università di Wuppertal aggiunge un'altra dimensione: l'app è bypassabile con VPN. Un funzionario CE ha confermato la cosa, precisando però che "it is not aimed at policing people online". Il sistema non ha pretesa di essere impermeabile — ma viene presentato come soluzione alla protezione dei minori.
Il precedente Discord 2025 è illuminante: circa 70.000 utenti con dati ID governativi esposti tramite un vendor terzo usato per la verifica età. Centralizzare la verifica dell'identità su un intermediario crea un target ad alto valore. Il bypass di Moore è un attacco locale sul singolo dispositivo; una breach su infrastruttura centralizzata scala all'intera base utenti in un colpo solo.
Approccio decentralizzato con ZKP: l'architettura giusta con i propri vincoli
La Commissione era consapevole del problema. L'architettura ZKP (zero-knowledge proof) era "ready to activate on Android" al momento del lancio — ma non deployata. Per iOS la soluzione era ancora più arretrata: "Apple users will be issued a batch of single-use age tokens". Il paradigma ZKP risolve strutturalmente il problema che Blazy aveva identificato: una prova ">=18" dimostra matematicamente l'età senza rivelare la data di nascita, il nome, o qualsiasi altro attributo. Il sito riceve solo un bit — sì o no — senza imparare nulla sull'identità della persona.
I framework esistono già. Hyperledger Indy/Aries implementa SSI (Self-Sovereign Identity) con DID e Verifiable Credentials W3C, self-hostabile. Walt.id (Vienna) è open source, compatibile W3C VC, già usato in prototype testing EUDI. Non sono teorie accademiche — sono stack in produzione su casi reali.
Ma l'approccio decentralizzato ha un problema non risolto che raramente viene dichiarato: chi emette la credential iniziale? Per funzionare, lo ZKP richiede che qualcuno abbia prima verificato e certificato l'età in modo affidabile. Quella prima verifica richiede un'ancora di fiducia — che sia lo stato, una banca, o un provider di identità. Se quell'ancora è compromessa o centralizzata, il problema si sposta di un livello ma non scompare.
Anja Lehmann dell'HPI (Hasso-Plattner-Institut) segnala un rischio specifico degli approcci a pseudonimo — il modello ZKP più comune: de-anonimizzazione progressiva nel tempo. Un utente che usa lo stesso pseudonimo su molti siti nel corso di anni costruisce involontariamente un profilo cross-site correlabile. Non è il provider di identità che raccoglie dati — è la correlazione statistica degli pseudonimi che lo fa per lui.
DimensioneTrasferibilità credential
Design centralizzato (app EU attuale)Alta — chiunque acceda al dispositivo fisico può usarla
Design decentralizzato (ZKP/SSI)Bassa — prova crittografica legata alla chiave privata
DimensioneRischio breach di massa
Design centralizzato (app EU attuale)Alto — target unico, scala all'intera base utenti
Design decentralizzato (ZKP/SSI)Basso — nessun server centrale con dati aggregati
DimensioneVPN bypass
Design centralizzato (app EU attuale)Sì, confermato da funzionario CE
Design decentralizzato (ZKP/SSI)Dipende dall'implementazione del sito richiedente
DimensioneDipendenza da big tech
Design centralizzato (app EU attuale)Alta — Google Play Integrity + Apple DeviceCheck
Design decentralizzato (ZKP/SSI)Bassa — ma richiede standard aperti adottati da OS vendor
DimensioneAnchor di fiducia iniziale
Design centralizzato (app EU attuale)Stato membro + contractor (Scytáles / Deutsche Telekom)
Design decentralizzato (ZKP/SSI)Comunque necessaria per emissione credential primaria
DimensioneMaturità deployment (apr 2026)
Design centralizzato (app EU attuale)In produzione su 5 paesi pilota (con vulnerabilità note)
Design decentralizzato (ZKP/SSI)ZKP pronto su Android, token one-use su iOS
Dimensione
Design centralizzato (app EU attuale)
Design decentralizzato (ZKP/SSI)
Trasferibilità credential
Alta — chiunque acceda al dispositivo fisico può usarla
Bassa — prova crittografica legata alla chiave privata
Rischio breach di massa
Alto — target unico, scala all'intera base utenti
Basso — nessun server centrale con dati aggregati
VPN bypass
Sì, confermato da funzionario CE
Dipende dall'implementazione del sito richiedente
Dipendenza da big tech
Alta — Google Play Integrity + Apple DeviceCheck
Bassa — ma richiede standard aperti adottati da OS vendor
Anchor di fiducia iniziale
Stato membro + contractor (Scytáles / Deutsche Telekom)
Comunque necessaria per emissione credential primaria
Maturità deployment (apr 2026)
In produzione su 5 paesi pilota (con vulnerabilità note)
ZKP pronto su Android, token one-use su iOS
Il confronto mostra che ZKP è superiore su quasi tutte le dimensioni critiche — ma non è una soluzione completa. È un paradigma migliore con un problema di bootstrap non risolto e rischi di de-anonimizzazione nel lungo periodo che la ricerca accademica sta ancora quantificando.
La voce contraria: Durov vede il problema giusto, ma sbaglia la diagnosi
Pavel Durov ha commentato l'incidente con una tesi più radicale: l'app non è un esperimento mal riuscito — è uno strumento di sorveglianza travestito da protezione della privacy. Il suo scenario a tre passi: lancio di un'app "privacy-respecting" ma vulnerabile; viene bucata; la Commissione usa il bypass come pretesto per rimuovere le protezioni privacy e trasformare l'app in un sistema di sorveglianza estesa.
The EU bureaucrats needed an excuse to silently start turning their 'privacy-respecting' age verification app into a surveillance mechanism over all Europeans using social media. — Pavel Durov, t.me/durov/491
Questa è l'affermazione che vale la pena smontare con cura. Durov ha ragione su una cosa: qualsiasi sistema che richiede verifica di identità centralizzata crea infrastruttura di controllo, indipendentemente dall'intenzione dichiarata. La comunità Hacker News l'ha formulato con più precisione: "We shouldn't be further creating the apparatus of the surveillance state." Non è questione di cattive intenzioni — è questione di design permanente. Una volta che l'infrastruttura di identità digitale è in produzione, i suoi usi futuri non sono controllabili da chi l'ha progettata. Dove la tesi non regge è nell'implicazione che il fallimento fosse intenzionale: i documenti pubblici mostrano invece una timeline politica incompatibile con una timeline tecnica, con la scelta deliberata di privilegiare la prima.
La distinzione conta sul piano dei rimedi. "Sorveglianza by design" e "incompetenza frettolosa" richiedono risposte diverse. La prima richiede opposizione politica. La seconda richiede processi tecnici più rigorosi — revisione indipendente obbligatoria, nessun deploy in produzione prima di un security audit, separazione netta tra timeline di comunicazione politica e deployment tecnico. Confondere le due diagnosi porta a combattere il problema sbagliato.
Cosa cambia per chi gestisce servizi in Italia
L'Italia è uno dei 5 paesi pilota. Ma c'è un secondo livello normativo che agisce in parallelo: il Decreto Caivano ha assegnato ad AGCOM il mandato di definire le modalità tecniche di verifica età per i social network entro il 30 giugno 2026. Il framework si chiama "mini-portafoglio" di verifica età, basato su IT-Wallet. AGCOM ha dichiarato un approccio "tecnologicamente neutrale" con principio di "doppio anonimato", il Garante Privacy aveva già espresso rilievi in luglio 2024 sulla minimizzazione dei dati, e Garante e AGCOM hanno aperto un tavolo congiunto. La sovrapposizione tra framework italiano e app EU — che ora porta un precedente di sicurezza pesante — è un'incognita regolatoria attiva fino al 30 giugno.
Per chi gestisce un homelab con servizi rivolti al pubblico — forum, community, piattaforme con contenuti classificabili come non adatti ai minori — la domanda pratica è aperta: il framework AGCOM includerà obblighi di conformità per operatori indipendenti, o si limiterà ai "social network" nel senso stretto? La definizione normativa attuale non è conclusiva.
Il pattern di sicurezza che emerge da questo incidente — stato di autenticazione gestito client-side, rate limiting lato client, logica di sicurezza come flag booleani — è esattamente l'anti-pattern che chiunque implementi auth conosce come sbagliato. Se stai costruendo autenticazione per i tuoi servizi self-hosted, l'approccio server-side con Authentik che abbiamo analizzato mostra il principio corretto: tutta la logica di sessione e i controlli di autenticazione vivono sul server, il client non decide nulla. Gli errori dell'app EU — logica di sicurezza decentrata al client, secret in plain text su storage non protetto — non sono errori da multi-milioni di euro di budget. Sono errori da assenza di revisione indipendente. L'analisi sugli errori comuni a breach reali offre il quadro più diretto.
C'è poi un aspetto raramente discusso in questo contesto: l'effetto spiazzamento. I ban totali ai social per minori, secondo le ricerche citate da Help Net Security, rischiano di spingere i ragazzi verso piattaforme non verificate, meno sicure, fuori da qualsiasi framework normativo. "Absolute bans often bring more harm than benefit". Un sistema di verifica età che non funziona non protegge i minori — crea un'illusione di protezione che giustifica politicamente un framework che ha già fallito.
