Discord e Twitch, verifica età aggirata con metadati falsi: scoperto bypass

La verifica dell’età online sta progressivamente diventando un requisito per piattaforme social e servizi di streaming, con l’obiettivo di conformarsi alle normative sulla tutela dei minori e alla gestione dei contenuti sensibili. L’adozione di sistemi biometrici basati su riconoscimento facciale si è diffusa rapidamente a partire dal 2021, quando fornitori come k-ID e FaceAssure hanno iniziato a fornire le loro soluzioni di verifica, accessibili tramite appositi pacchetti SDK. Discord, Twitch, Snapchat e altre piattaforme hanno deciso di affidarsi proprio a queste soluzioni.

Secondo dati di settore, oltre il 40% dei servizi con contenuti soggetti a restrizioni utilizza oggi soluzioni di age verification automatizzata basate su machine learning. Tuttavia, la crescente complessità di tali sistemi ha aperto nuovi scenari di vulnerabilità, come dimostra il recente bypass individuato nella pipeline di verifica dell’età di k-ID.

Architettura del sistema di verifica dell’età usato da Discord, Twitch e Snapchat

Un gruppo di ricercatori indipendenti ha analizzato il sistema di verifica dell’età proposto dal provider k-ID spiegando come esso adotti un modello di verifica che evita la trasmissione di immagini o video del volto dell’utente ai server centrali.

Al posto dei dati biometrici grezzi, il client invia una serie di metadati derivati dall’analisi del volto, includendo parametri numerici e segnali temporali generati localmente. L’approccio, pur riducendo il rischio di esposizione di dati personali, introduce un punto debole: la fiducia implicita nei dati forniti dal client.

La componente di analisi facciale è delegata al partner tecnologico FaceAssure, che genera una serie di vettori numerici rappresentanti caratteristiche biometriche e pattern di comportamento durante la scansione. I risultati sono poi normalizzati e inviati al server k-ID per la decisione finale sull’età dell’utente.

Replica della crittografia e costruzione del payload

L’analisi delle richieste di verifica legittime ha evidenziato la presenza di un blocco cifrato composto da encrypted_payload, auth_tag, timestamp e vettore di inizializzazione. Il sistema impiega la modalità AES-GCM (uno schema di cifratura autenticata che assicura sia la riservatezza sia l’integrità dei dati), utilizzando una chiave generata tramite HKDF (una funzione di derivazione di chiavi) basata su hash SHA-256 e ottenuta a partire da nonce (valore casuale monouso), timestamp (momento temporale) e transaction_id (identificativo della transazione).

Replicando localmente questo schema di derivazione, i ricercatori hanno accertato che è possibile generare payload crittografati indistinguibili da quelli prodotti dall’applicazione ufficiale. L’assenza di un meccanismo di attestazione hardware o firma lato client rende il sistema vulnerabile alla simulazione completa del processo di cifratura.

Manipolazione dei dati di previsione

Superata la fase crittografica, il controllo prosegue analizzando le strutture chiamate prediction arrays. I valori rappresentano misurazioni grezze prodotte dal modello di riconoscimento facciale, cioè dati non ancora elaborati che descrivono le caratteristiche del volto rilevate dal sistema. Tali dati sono convertiti in una stima dell’età attraverso una mappatura numerica e poi uniformati tramite una normalizzazione statistica.

Ricostruendo matematicamente questo meccanismo, i ricercatori si sono dimostrati in grado di generare sequenze di dati compatibili con i parametri attesi e quindi considerate valide dal server remoto.

Implicazioni di sicurezza e prospettive

La studio da poco pubblicato dimostra che un sistema basato esclusivamente su metadati client-side è esposto a manipolazioni avanzate. In assenza di un canale di attestazione sicuro, il server non dispone di strumenti per distinguere tra dati generati da un dispositivo reale ed eventuali payload costruiti ad arte.

Le contromisure possibili includono l’introduzione di verifiche hardware (ad esempio tramite WebAuthn o attestazioni Trusted Platform Module), la firma crittografica dei dati biometrici a livello di SDK e l’analisi comportamentale server-side basata su modelli dinamici non replicabili facilmente.

Il bypass descritto, come scrivono gli autori dell’indagine, appare oggi “temporaneamente risolto dai fornitori” attraverso aggiornamenti lato server e modifiche nei controlli di coerenza, ma il principio di fondo resta valido: l’affidamento su metadati generati lato client introduce un vettore di attacco intrinseco. L’evoluzione dei sistemi di age verification dovrà necessariamente integrare elementi di verifica indipendenti dal dispositivo utente per garantire robustezza e affidabilità nel lungo periodo.

Verifica dell’età in Europa: obbligo già attivo, strumenti ancora in fase di transizione

In Europa la verifica dell’età è già un obbligo operativo che però si colloca in una fase di transizione tecnologica. In Italia, dal 12 novembre 2025, la delibera AGCOM 96/25/CONS impone ai siti con contenuti per adulti di verificare la maggiore età secondo le linee guida del DSA e del GDPR, adottando il principio del doppio anonimato, per cui il verificatore non conosce il sito visitato e il sito non conosce l’identità dell’utente.

Sul piano tecnico, i servizi possono utilizzare app dedicate, wallet digitali eIDAS/EUDI, token crittografici o QR code che generano una prova di età monouso.

Parallelamente, la Commissione Europea ha sviluppato un’app di age verification pensata come mini portafoglio compatibile con l’EU Digital Identity Wallet previsto entro il 2026: il sistema genera una prova crittografica di maggiore età senza esporre dati anagrafici, utilizza credenziali firmate (ad esempio token con firma ES256), flussi OAuth2 con PKCE e cifratura AES-GCM, con integrazione futura di zero-knowledge proof.

L’app è però ancora in fase pilota, disponibile solo come progetto open source su GitHub, non pubblicata sugli store ufficiali, installabile manualmente e in sperimentazione.

Ciò evidenzia che il quadro normativo è già attivo mentre la soluzione tecnica europea definitiva non è ancora distribuita. Restano inoltre criticità strutturali legate all’interoperabilità e alla dipendenza tecnologica: l’uso della remote attestation tramite Play Integrity API implica la compatibilità solo con dispositivi Android certificati ed esclude sistemi alternativi, rendendo l’integrità del dispositivo parte del modello di sicurezza e introducendo implicazioni per la sovranità digitale.