Già violata l'app UE per la verifica dell’età: cos'è successo

Un’app pensata per verificare l’età degli utenti senza esporre dati personali dovrebbe rappresentare uno dei punti più avanzati nella tutela della privacy digitale europea. Secondo diverse analisi della Commissione europea, oltre il 70% dei minori accede regolarmente a servizi digitali che richiederebbero un controllo dell’età. Così, la presidente Ursula von der Leyen ha dichiarato senza mezzi termini: l’app UE per verificare l’età è pronta ed è sviluppata per proteggere i più piccoli.

Peccato però che i controlli esercitati dall’applicazione europea, secondo quanto riportato dal ricercatore di sicurezza Paul Moore, possano essere bypassati meno di 2 minuti intervenendo sui file di configurazione locali, in particolare su quelli conservati nella directory locale shared_prefs.

Azzeramento del PIN dell’app di verifica dell’età: conservati i dati del profilo utente

L’idea è semplice: l’app prevede l’impostazione di un PIN scelto dall’utente che è crittografato e salvato nelle preferenze. Quel PIN, tuttavia, non risulta legato in modo crittograficamente forte al contenitore che conserva le credenziali di verifica dell’età. Se un attaccante con accesso fisico al dispositivo riesce a modificare il file delle preferenze, può eliminare i valori del PIN cifrato, riavviare l’app, impostare un nuovo codice e ottenere accesso alle credenziali già emesse con il profilo precedentemente in uso.

Se nel telefono c’è già una credenziale valida (ad esempio se il proprietario è maggiorenne), l’attaccante può usarla come se fosse sua.

Il punto debole è la mancanza di qualunque collegamento tra il segreto locale usato per lo sblocco e il materiale sensibile custodito nel wallet. In un disegno robusto, il cambio del PIN dovrebbe richiedere una re-derivazione sicura delle chiavi, oppure l’invalidazione dell’accesso ai dati già presenti, oppure ancora l’utilizzo di un fattore custodito nell’Android Keystore o in uno storage hardware protetto.

Se invece il PIN risiede in un semplice file di configurazione, la sua rimozione diventa un gioco da ragazzi.

Rate limiting e biometria: se vivono nello stesso file, valgono poco

La seconda parte della dimostrazione è ancora più istruttiva. Moore sostiene che il contatore dei tentativi falliti e il flag che abilita la biometria siano memorizzati nello stesso spazio di configurazione locale.

Anche qui, basta azzerare il contatore per annullare il meccanismo di rate limiting e impostare a false il parametro booleano relativo a UseBiometricAuth per far saltare il controllo biometrico.

Quando una misura di protezione dipende da un valore modificabile dallo stesso attore che si vuole fermare, quella misura ha un valore del tutto “cosmetico”.

Un contatore anti brute force serio richiede un archivio resistente alla manomissione, o almeno una logica server side, o una chiave di stato firmata e verificabile. Lo stesso vale per la scelta tra PIN e biometria: se la decisione resta un semplice interruttore nelle preferenze, si ha davanti un castello di carte che cade il primo alito di vento.

Le immagini biometriche in PNG sono il problema più pesante sul piano della privacy

L’analisi di Moore tocca un’altra area ancora più delicata: la gestione delle immagini usate durante l’attivazione dell’app di verifica dell’età.

Secondo il ricercatore, il flusso NFC estrae il volto dal DG2 del documento elettronico e lo scrive su disco come PNG lossless; la cancellazione scatterebbe solo in caso di successo, mentre un errore, un crash, un annullamento o una scansione interrotta potrebbero lasciare il file nel dispositivo. Per i selfie il quadro sarebbe peggiore: immagini salvate nello storage esterno all’applicazione e non rimosse affatto, quindi conservate nel tempo.

La Commissione insiste, a ragione, sull’uso di meccanismi privacy-preserving e di zero-knowledge proof per attestare il superamento di una soglia di età senza consegnare l’identità completa alla piattaforma. Quell’obiettivo resta valido e tecnicamente sensato.

Il problema è che una soluzione del genere vive su più livelli: protocolli di presentazione, emittenti di credenziali, conservazione locale, onboarding documentale, liveness, face match, gestione dei segreti e UX di recupero. Se la parte crittografica a valle è ben fatta ma l’acquisizione o la protezione locale a monte è debole, l’utente perde comunque controllo sui dati più delicati, cioè proprio quelli biometrici e documentali raccolti per ottenere la credenziale.

Che cosa dovrebbe cambiare prima di una distribuzione dell’app

Le correzioni da fare sono tante: il PIN dell’app di verifica dovrebbe sbloccare materiale legato a chiavi custodite dal sistema; le preferenze che governano tentativi di accesso e biometria devono usare protezioni adeguate contro la manomissione. Le immagini di onboarding dovrebbero restare in memoria il meno possibile, essere cifrate a livello applicativo quando la persistenza è inevitabile e cancellate in modo affidabile.

Il valore dell’open source, in fondo, si misura proprio qui. Il codice pubblico consente a ricercatori indipendenti di verificare le promesse e di trovare incoerenze prima che diventino problemi distribuiti su larga scala.

La dimostrazione di Moore non liquida l’idea europea di una prova dell’età con una condivisione di dati minimale; mostra però che la sicurezza reale non si ottiene proclamando l’adozione di “massimi standard di privacy” quando, come evidente, ci sono molteplici punti critici ancora da affrontare.