PDF protetti con AES-256 violabili in pochi millisecondi: ecco perché

Un documento PDF protetto con AES-256 dovrebbe offrire una sicurezza estremamente elevata, soprattutto quando l’utente sceglie una password robusta. Eppure, alcuni programmi molto diffusi generano chiavi crittografiche così prevedibili da permettere il recupero del contenuto senza conoscere alcuna password. Nel caso più clamoroso, una chiave teoricamente lunga 256 bit dipende da appena 9 bit di informazione casuale: bastano 512 tentativi per individuarla.

La scoperta arriva dai ricercatori di V12, che hanno pubblicato un’analisi delle implementazioni crittografiche di MuPDF, Foxit PDF Reader, OpenPDF e iText. I risultati mettono in discussione un presupposto apparentemente scontato: utilizzare un algoritmo sicuro non significa produrre documenti altrettanto sicuri.

Il problema assume particolare importanza considerando l’evoluzione della protezione dei PDF. Dalle prime implementazioni basate su RC4 (fallaci ormai da molto tempo…) si è passati ad AES-128 e successivamente ad AES-256, con meccanismi di derivazione delle chiavi progressivamente più resistenti agli attacchi. Le novità in termini di sicurezza confermate nelle specifiche PDF 2.0 rappresentano uno degli sviluppi più importanti. Ma una debolezza nella generazione dei numeri casuali può vanificare anche le protezioni più sofisticate.

Perché AES-256 può diventare inutile anche con una password sicura

Per comprendere la vulnerabilità bisogna distinguere due elementi che spesso si confondono: la password del documento e la chiave utilizzata per cifrarne il contenuto.

Nei PDF che adottano le revisioni moderne della protezione AES-256, il programma genera una file encryption key di 32 byte, corrispondenti a 256 bit. È questa chiave a proteggere i dati del documento. La password, combinata con valori casuali chiamati salt, permette invece di ricavare una seconda chiave utilizzata per proteggere quella principale.

La revisione 6 (le ultime modifiche sul formato PDF alle quali abbiamo fatto riferimento in apertura) rende il procedimento di derivazione dalla password deliberatamente oneroso dal punto di vista computazionale, così da rallentare gli attacchi per tentativi. La revisione 5 utilizzava invece una procedura meno resistente.

Tutta questa complessità diventa però irrilevante se la chiave principale nasce da un generatore prevedibile: un attaccante non ha bisogno di indovinare la password perché può ricostruire direttamente la chiave del documento e utilizzarla per decifrare i dati.

Non si tratta quindi di una vulnerabilità matematica di AES-256: l’algoritmo continua a offrire la sicurezza prevista, purché riceva chiavi generate correttamente. Il difetto riguarda il software che prepara quelle chiavi.

MuPDF: una chiave AES-256 con appena 512 combinazioni possibili

Il caso più sorprendente riguarda MuPDF, noto motore open source per la visualizzazione e l’elaborazione dei documenti.

Secondo V12, le versioni precedenti alla 1.28.5 utilizzavano un generatore pseudocasuale appartenente alla famiglia drand48, inizializzato tramite l’ora corrente espressa in secondi Unix.

Un generatore pseudocasuale non produce numeri realmente casuali: parte da uno stato iniziale, chiamato seed, e applica una sequenza deterministica di operazioni. Se qualcuno riesce a ricostruire il seed, può riprodurre gli stessi valori.

Nel codice esaminato, la funzione fz_srand48() inizializza uno stato di 48 bit con i 16 bit meno significativi che assumono sempre il valore esadecimale 0x330e; i restanti 32 bit derivano dal timestamp. Successivamente, il generatore applica una formula lineare, utilizzando un moltiplicatore e un incremento fissi. Il difetto decisivo emerge osservando come MuPDF utilizza i numeri generati: per produrre ciascun byte della chiave, conserva soltanto i bit dalla posizione 17 alla 24.

In pratica, dei 48 bit dello stato iniziale soltanto 25 possono influenzare la chiave: poiché 16 sono costanti, rimangono appena 9 bit di entropia effettiva. Il risultato è impressionante: 2⁹ significa soltanto 512 possibilità.

Timestamp distanti esattamente 512 secondi, o da un multiplo di tale intervallo, producono la stessa sequenza di byte. Il tempo effettivo di creazione del documento non serve quindi per restringere ulteriormente la ricerca: tutte le possibilità si possono vagliare in modo diretto!

Il difetto risulta corretto nella versione 1.28.5 di MuPDF, rilasciata il 25 settembre 2026. L’aggiornamento, tuttavia, non modifica retroattivamente le chiavi dei documenti già generati.

Foxit PDF Reader: la chiave dipende dall’ora di creazione

Il secondo caso coinvolge Foxit PDF Reader 2026.1.3.36551. Qui il problema assume una forma differente, ma il risultato rimane grave: la chiave AES-256 deriva da informazioni largamente prevedibili.

Secondo l’analisi di V12, il programma calcola una funzione SHA-256 combinando tre elementi: un timestamp Unix a 32 bit, una sequenza di 32 byte non inizializzati e la stringa costante there. Se gli elementi in ingresso sono prevedibili, lo sarà anche il risultato. Così, i ricercatori di V12 hanno scoperto che, nel caso di Foxit PDF Reader, la chiave dipendeva sostanzialmente dall’ora di creazione del PDF, con una precisione di un secondo.

A differenza di MuPDF, non esistono soltanto 512 combinazioni possibili; lo spazio di ricerca risulta però limitato a un insieme di timestamp plausibili. Conoscendo approssimativamente la data di generazione del documento, l’attaccante può ridurre ulteriormente il lavoro.

V12 ha sviluppato un programma Rust multithread che, su un processore AMD Ryzen 9 7950X utilizzando 32 thread, esamina circa 370-376 milioni di timestamp al secondo.

Nei test pubblicati, il recupero di una chiave generata 10 anni prima ha richiesto 0,84 secondi; una ricerca estesa dall’epoca Unix fino al momento della prova si è conclusa in 4,85 secondi.

I ricercatori hanno anche scoperto che usando l’opzione /Perms, prevista dalla struttura crittografica dei PDF moderni, un aggressore può verificare le chiavi senza conoscere la password.

OpenPDF e iText: numeri casuali ricavati dal tempo e dalla memoria Java

L’indagine prende in esame anche due librerie Java ampiamente conosciute nella generazione e manipolazione di PDF: OpenPDF 3.0.5 e iText 9.7.1.

Entrambe, secondo V12, fanno passare la generazione dei valori crittografici attraverso una classe chiamata IVGenerator, che utilizza un generatore inizializzato con due informazioni: il timestamp in millisecondi restituito da System.currentTimeMillis() e la quantità di memoria libera nella JVM ottenuta mediante Runtime.getRuntime().freeMemory(). I valori sono convertiti in una stringa separata dal simbolo + e utilizzati per inizializzare il generatore.

Il problema non consiste soltanto nell’impiego di ARC4, algoritmo ormai inadatto a nuove applicazioni crittografiche. La questione principale è la qualità del seed: orario e memoria libera non rappresentano sorgenti affidabili di casualità crittografica.

Un attaccante può formulare ipotesi sui valori iniziali, confrontare i salt generati con quelli presenti nel file e, quando trova una corrispondenza, ricostruire i byte successivi o precedenti del flusso necessari a ottenere la chiave.

Rispetto a MuPDF e Foxit, la quantità variabile di memoria libera amplia sensibilmente lo spazio di ricerca. V12 non presenta per queste due librerie una dimostrazione di recupero universale con tempi paragonabili agli altri casi. La debolezza individuata resta comunque significativa: il generatore non possiede le proprietà richieste a una sorgente crittografica robusta.

Quali PDF sono a rischio e cosa fare per proteggerli

In primis bisogna sottolineare che un PDF creato da un software vulnerabile può conservare una chiave debole anche quando viene letto successivamente con un visualizzatore aggiornato. Allo stesso modo, un documento cifrato correttamente da un altro programma non diventa automaticamente vulnerabile soltanto perché qualcuno lo visualizza con Foxit o MuPDF.

La misura immediata consiste nell’aggiornare le applicazioni e le librerie coinvolte, verificando che le rispettive versioni includano correzioni specifiche.

Per MuPDF la ricerca identifica la versione 1.28.5 come corretta; per gli altri prodotti citati, l’articolo di V12 non documenta una versione risolutiva equivalente.

Se un’organizzazione ha prodotto documenti riservati mediante le implementazioni interessate dalle varie problematiche, dovrebbe valutare una nuova cifratura utilizzando software aggiornato e un generatore crittograficamente sicuro (CSPRNG). In Java, per esempio, la classe SecureRandom costituisce il riferimento standard per ottenere valori adatti a impieghi crittografici, a condizione che il provider e la configurazione siano affidabili.

Non basta modificare la password mantenendo la stessa chiave del file: è necessario generare una nuova chiave casuale e cifrare nuovamente il contenuto; soltanto così si elimina la dipendenza dal materiale crittografico prevedibile.

È opportuno ricordare anche che le restrizioni PDF sulla stampa, sulla copia e sulla modifica non equivalgono a un controllo degli accessi realmente inviolabile. Chi dispone della chiave necessaria a decifrare il documento può potenzialmente estrarne il contenuto, indipendentemente dalle limitazioni applicate dal lettore.

La lezione della chiave AES a 9 bit: conta come nasce, non soltanto quanto è lunga

La ricerca V12 mostra un errore ricorrente nella progettazione della sicurezza: attribuire all’algoritmo crittografico proprietà che dipendono, in realtà, dall’intera implementazione.

AES-256 dispone teoricamente di uno spazio di 2 elevato alla 256 chiavi. Ma se un’applicazione produce soltanto 512 chiavi differenti, la sicurezza effettiva non corrisponde a quella suggerita dalla lunghezza nominale.

Per chi sviluppa software, la verifica deve quindi comprendere anche la provenienza dei numeri casuali, l’inizializzazione dei generatori, l’eventuale riutilizzo degli stati e la presenza di valori prevedibili nei dati pubblici del file.

V12 dichiara di aver comunicato i problemi ai produttori e ha pubblicato su GitHub strumenti dimostrativi per MuPDF e Foxit. L’aspetto più preoccupante riguarda però i documenti già distribuiti: correggere un programma impedisce nuove generazioni vulnerabili, ma non restituisce segretezza alle vecchie chiavi.