Cifratura delle memorie

1. Di cosa parliamo

Per cifratura di una memoria si intende la trasformazione dei dati scritti su un supporto, tramite uno o più algoritmi crittografici, in modo che risultino illeggibili a chi non possiede la chiave. Si può applicare a tre livelli diversi, e la scelta del livello conta quanto quella dello strumento.

• Cifratura a blocchi dell’intero disco (Full Disk Encryption, FDE). Lavora sotto il filesystem, settore per settore: tutto ciò che viene scritto, compresi nomi dei file, struttura delle cartelle e spazio di scambio, esce cifrato. È il livello di BitLocker, LUKS e GELI, e copre anche i volumi fisici su cui poggia un gestore di volumi logici.
• Cifratura a livello di filesystem o di cartella. Cifra il contenuto dei file, e spesso i nomi, ma lascia visibile una parte dei metadati: dimensioni, date, numero di file, nomi dei volumi. In cambio permette chiavi diverse per utenti o dataset diversi. È il livello della cifratura nativa di ZFS, di fscrypt su ext4, di gocryptfs.
• Cifratura nell’hardware (Self-Encrypting Drive). La esegue il controller del disco. È comoda e veloce, ma è una scatola chiusa: nel 2018 due ricercatori dell’università Radboud mostrarono che diversi SSD diffusi si potevano sbloccare senza conoscere la password. BitLocker, che fino ad allora si fidava del disco quando questo dichiarava di sapersi cifrare, dal 2019 non lo fa più in automatico.

Il costo in prestazioni, sui processori degli ultimi quindici anni, è piccolo: le istruzioni AES sono integrate nella CPU. La latenza di cui ci si preoccupava una volta oggi si nota solo su hardware molto vecchio o molto economico.

2. Da cosa protegge, e da cosa no

È il punto su cui si fa più confusione, e conviene chiarirlo prima di scegliere uno strumento.

La cifratura delle memorie protegge i dati a riposo. Finché il volume è chiuso, chi ha in mano il disco ha in mano rumore. Nel momento in cui inserisco la passphrase, il sistema operativo vede tutto in chiaro, e con lui ogni programma che gira con i miei permessi: un malware, un’estensione del browser, un software che invia telemetria. Per quei rischi servono altri strumenti (aggiornamenti, isolamento, privilegi minimi, attenzione a ciò che si installa).

Riletti così, i rischi classici di una fuga di dati si dividono in due gruppi.

C’è poi un rischio che la cifratura crea invece di togliere: perdere la chiave. Un disco cifrato di cui si è dimenticata la passphrase, o il cui header è danneggiato, è perso per sempre. Cifrare senza un backup è scambiare un rischio con un altro.

3. Il vero problema: le chiavi

Tutti i sistemi seri usano AES, quasi sempre in modalità XTS. Nessuno di quelli descritti qui è stato battuto attaccando l’algoritmo. Si rompono altrove.

La passphrase e la funzione di derivazione. I dati sono cifrati con una chiave casuale, la master key, che a sua volta è custodita cifrata con una chiave ricavata dalla nostra passphrase. La funzione che compie questo passaggio (KDF) serve a rendere costoso ogni tentativo di indovinarla. PBKDF2, la più vecchia, costa solo tempo di calcolo, e chi dispone di schede grafiche o hardware dedicato prova miliardi di combinazioni. Argon2id costa anche memoria, e questo toglie gran parte del vantaggio a chi attacca. Con una passphrase debole, la differenza tra le due è la differenza tra un disco aperto e uno chiuso.

Il chip TPM. Molti sistemi affidano la chiave a un chip sulla scheda madre, che la rilascia da solo se l’avvio non è stato manomesso. È comodo, perché il computer si avvia senza chiedere nulla, e per lo stesso motivo è debole: chi ruba il portatile ruba anche il chip. Su diversi modelli la chiave viaggia in chiaro tra chip e processore e si può leggere con pochi euro di attrezzatura. Un PIN richiesto prima dell’avvio chiude questo varco.

La memoria. A macchina accesa o sospesa la chiave sta nella RAM. Nel 2008 un gruppo di Princeton dimostrò che la si può recuperare raffreddando i moduli e leggendoli su un’altra macchina (cold boot attack). La difesa è semplice: spegnere, o ibernare su disco cifrato, invece di sospendere.

L’avvio. Qualcosa deve pur partire in chiaro per chiedere la passphrase. Chi ha accesso fisico per pochi minuti può sostituire quel pezzo con uno che la registra: è l’attacco della evil maid, descritto da Joanna Rutkowska nel 2009. Lo si contrasta con l’avvio verificato (Secure Boot con chiavi proprie, misure del TPM) e, più banalmente, non lasciando il dispositivo incustodito.

Il recupero. Ogni sistema prevede una chiave di emergenza. Dove viene conservata decide chi altri può aprire il disco. È il punto su cui Windows e macOS vanno guardati con più attenzione.

Sulla costruzione delle passphrase rimando alla sezione Password della documentazione di Tutanum.

4. Windows: BitLocker

BitLocker è la soluzione integrata di Microsoft, presente da Windows Vista. Cifra i volumi con AES in modalità XTS a 128 bit per impostazione predefinita (256 bit se lo si imposta tramite criteri) e si appoggia al TPM.

I problemi non stanno nell’algoritmo.

• È codice chiuso. Nessuno, fuori da Microsoft, può verificare che faccia soltanto ciò che dichiara. Non esiste alcuna prova pubblica di una backdoor, ed è corretto dirlo; ma l’assenza di prove, quando la verifica è impossibile, vale poco.
• La chiave di recupero finisce nel cloud. Sui computer non gestiti da un’azienda, accedendo con un account Microsoft la chiave di ripristino viene caricata automaticamente su quell’account. Non serve nessuna backdoor: nel gennaio 2026 Forbes ha documentato un caso in cui Microsoft ha consegnato all’FBI, su mandato, le chiavi di tre portatili. L’azienda ha confermato di farlo quando riceve un ordine valido, e di ricevere una ventina di richieste l’anno.
• Di default si sblocca da solo. Con il solo TPM, senza PIN, il disco si apre a chiunque accenda il computer e sappia aggirare la schermata di accesso o intercettare la chiave.
• Il sistema che lo ospita. Windows raccoglie telemetria che non si disattiva del tutto. Cifrare il disco di un sistema che comunica i miei dati al produttore protegge dal ladro, non dal produttore.

Se si deve usare Windows: abilitare il PIN all’avvio, salvare la chiave di recupero su carta o su una chiavetta e cancellarla dall’account online, portare la cifratura a 256 bit. Oppure usare VeraCrypt (sezione 8).

5. macOS: FileVault

FileVault cifra il volume con XTS-AES-128, con chiave a 256 bit. Sui Mac con chip T2 o Apple silicon la cifratura è eseguita dall’hardware, e le chiavi sono custodite nella Secure Enclave, un processore separato che non le espone al sistema operativo. Su queste macchine il disco è cifrato comunque: attivare FileVault serve a legare lo sblocco alla password dell’utente.

L’integrazione è migliore di quella di Windows e le politiche sulla privacy sono più restrittive. Restano due obiezioni di fondo. La prima è la stessa: è codice chiuso, su hardware chiuso, e la fiducia richiesta è totale. La seconda riguarda il recupero: al momento dell’attivazione viene proposto di affidare lo sblocco all’account iCloud. Chi accetta ha consegnato una via d’accesso a un terzo, esattamente come su Windows. Conviene scegliere la chiave di recupero locale e conservarla offline.

6. GNU/Linux: LUKS

Su GNU/Linux lo standard è LUKS (Linux Unified Key Setup), che si appoggia al sottosistema dm-crypt del kernel. Lavora a blocchi, sotto qualunque filesystem: ext4, XFS, Btrfs. È più «grezzo» delle soluzioni commerciali nel senso che lascia vedere i pezzi, ma è anche l’unico dei tre di cui si può leggere ogni riga.

L’header. All’inizio del volume c’è un’intestazione che contiene i parametri e gli slot in cui la master key è custodita, cifrata con le diverse passphrase. È il punto delicato: se viene sovrascritto, per errore o da un malware con privilegi di root, il contenuto è irrecuperabile. Va detto con precisione, perché spesso lo si confonde: distruggere l’header non espone i dati, li rende inaccessibili a tutti, proprietario compreso. È un danno alla disponibilità, non alla riservatezza. Si previene con una copia dell’header conservata altrove.

LUKS1 e LUKS2. LUKS2, predefinito dal 2019, aggiunge un header ridondante, più slot, il supporto ad Argon2id e ai token hardware. LUKS1 conosce solo PBKDF2. Chi ha un volume creato anni fa farebbe bene a controllare: nel 2023 lo sviluppatore Matthew Garrett ha raccomandato pubblicamente di convertire le vecchie chiavi ad Argon2id, dopo che era stato riferito il caso di un disco cifrato aperto dagli inquirenti.

# che formato e che KDF usa il mio volume?
cryptsetup luksDump /dev/sdX2

# copia di sicurezza dell'header (da conservare fuori dal disco)
cryptsetup luksHeaderBackup /dev/sdX2 --header-backup-file header.img

# convertire uno slot esistente ad Argon2id
cryptsetup luksConvertKey /dev/sdX2 --pbkdf argon2id

# creare un volume nuovo
cryptsetup luksFormat --type luks2 --pbkdf argon2id /dev/sdX2

La questione di GRUB. Per anni il boot loader più diffuso non ha saputo aprire i volumi LUKS2. La segnalazione su Savannah è rimasta aperta a lungo; il supporto è arrivato nel 2021 con la versione 2.06, grazie alle patch di Patrick Steinhardt, ma limitato a PBKDF2. Argon2 è stato integrato solo a fine 2025 ed è uscito con GRUB 2.14 nel gennaio 2026, e ancora oggi alcuni utenti segnalano che le chiavi create con i parametri predefiniti non si aprono su tutte le macchine.

Per molto tempo ho letto in questo ritardo una volontà precisa. Guardando la storia delle patch, la spiegazione più semplice è un’altra: una funzione che per progetto richiede un gigabyte di memoria è difficile da far girare nell’ambiente ridotto di un boot loader, e GRUB è mantenuto da pochissime persone. Non è un’assoluzione: che un componente da cui dipende la sicurezza di milioni di macchine sia sviluppato con queste risorse è già il problema.

Nella pratica il nodo si aggira in due modi:

• /boot in chiaro, tutto il resto in LUKS2. È la configurazione predefinita di quasi tutte le distribuzioni: il kernel parte da una partizione non cifrata e apre lui il volume, con Argon2id. Il punto debole è che kernel e initramfs sono modificabili da chi ha accesso fisico; lo si chiude firmando l’immagine di avvio (Unified Kernel Image con Secure Boot).
• /boot cifrato, aperto da GRUB. Fino alla 2.14 richiedeva LUKS1 o LUKS2 con PBKDF2 per quella partizione, da cui gli schemi misti con due volumi. Oggi è possibile con Argon2id, ma va provato sul proprio hardware prima di affidarcisi.

Le vulnerabilità. GRUB e il kernel accumulano ogni anno decine di CVE, e scorrerne l’elenco fa impressione. Ma un elenco di CVE corrette misura quanto un software viene esaminato, non quanto è insicuro. Quelle che contano qui sono le falle nella catena di avvio, come BootHole (2020) e la serie del 2022 in GRUB, perché permettono di aggirare Secure Boot e quindi di preparare un attacco evil maid. La lezione è concreta: un boot loader non aggiornato vanifica una cifratura perfetta.

7. ZFS e il mondo BSD

Un’alternativa è spostare la cifratura dentro il filesystem. ZFS, nato in Sun per Solaris e oggi sviluppato come OpenZFS, è nativo su FreeBSD e disponibile su GNU/Linux. Offre controllo dell’integrità di ogni blocco, compressione, deduplicazione a livello di blocco (utile in pochi casi, e avida di memoria) e soprattutto snapshot immutabili: una fotografia del filesystem che nessun processo può modificare, e che per questo è una difesa reale contro ransomware ed errori. Gli snapshot di LVM, per confronto, nascono scrivibili e vanno resi di sola lettura esplicitamente.

Dal 2019 OpenZFS ha una cifratura nativa, per singolo dataset:

zfs create -o encryption=aes-256-gcm -o keyformat=passphrase pool/data00

I vantaggi sono reali: chiavi diverse per dataset diversi, ereditarietà, la possibilità di replicare un dataset cifrato su un server remoto che non possiede la chiave. Ma i limiti vanno conosciuti.

• I metadati restano in chiaro: nomi dei dataset e degli snapshot, proprietà, dimensioni. Per questo conviene dare nomi che non dicano nulla (data00, data01) invece di root e home. Chi vuole nascondere anche questo mette ZFS sopra un volume cifrato a blocchi.
• La derivazione della chiave usa PBKDF2, non Argon2: la passphrase deve essere lunga.
• Ci sono bug aperti. L’uso combinato di cifratura nativa, snapshot e replica ha una storia di segnalazioni di corruzione dei dati; nel 2025 ne sono stati corretti almeno due. È una funzione da usare con una versione recente e con backup verificati.
• L’usura delle memorie. ZFS scrive sempre in nuove posizioni, e su SSD economici questo accorcia la vita del supporto. Si riduce con i parametri giusti (dimensione dei blocchi, frequenza delle scritture sincrone), ma richiede dischi di qualità.

Sui BSD la cifratura a blocchi classica è un’altra cosa, e non va confusa con la precedente. Su FreeBSD è GELI, costruita sul framework GEOM, che può anche autenticare i dati oltre a cifrarli; il più vecchio GBDE è ormai un residuo storico. Su OpenBSD, che ZFS non lo ha, si usa la disciplina CRYPTO di softraid. La combinazione più solida su FreeBSD è ZFS sopra GELI: tutto il disco cifrato a blocchi, metadati compresi, con sopra le funzioni di ZFS.

Per l’avvio da ZFS su GNU/Linux esiste ZFSBootMenu, che sostituisce GRUB e permette anche di avviare da uno snapshot precedente. Di queste scelte discuto nella documentazione di Tutanum, nelle sezioni su filesystem, boot loader e crittografia.

8. Gli strumenti multipiattaforma

VeraCrypt. È il successore di TrueCrypt, abbandonato dai suoi autori anonimi nel 2014 con un messaggio mai chiarito. Funziona su Windows, macOS e GNU/Linux, cifra contenitori, partizioni e (su Windows) il disco di sistema, e offre i volumi nascosti: un secondo volume dentro il primo, la cui esistenza non si può dimostrare. Il sorgente è pubblico e chiunque può compilarlo; la licenza è mista (Apache 2.0 per il codice nuovo, la vecchia licenza TrueCrypt per quello ereditato), ed è per questo che alcune distribuzioni non lo includono. Non è quindi software proprietario, ma nemmeno pienamente libero.

Sul sospetto che dipenda da algoritmi dell’NSA: SHA-2 è stato effettivamente progettato dall’agenzia, ma è pubblico, studiato da vent’anni e mai violato. E VeraCrypt non obbliga a usarlo: permette di scegliere Whirlpool, BLAKE2s o Streebog come funzione di hash, e Serpent, Twofish o Camellia, anche in cascata, al posto di AES. L’assenza di SHA-3 non è un indizio: in questo impiego non darebbe nulla in più. Il codice è stato esaminato da Quarkslab nel 2016 e dal Fraunhofer SIT, per conto dell’ufficio federale tedesco per la sicurezza informatica, nel 2020; i difetti trovati sono stati in gran parte corretti.

BestCrypt. Sviluppato dalla finlandese Jetico, cifra volumi e contenitori con AES, Twofish, Serpent e altri, con accelerazione hardware e autenticazione a due fattori. È un buon prodotto ed è proprietario: vale quanto detto per BitLocker.

PGPdisk. Era il modulo per i dischi virtuali della suite commerciale PGP, oggi di Broadcom dopo il passaggio per Symantec. Lo cito perché capita di trovarlo nominato insieme a GnuPG, con cui non ha a che fare.

GnuPG. È l’implementazione libera dello standard OpenPGP, nata nel 1997 per sostituire il PGP di Phil Zimmermann. Cifra file e messaggi, non dischi: è lo strumento giusto per un archivio da spedire o per un backup da depositare su un server altrui. Il progetto ha ricevuto finanziamenti dal governo tedesco, e in oltre vent’anni di codice pubblico non è emersa alcuna backdoor. Per chi trova GnuPG troppo complesso, age fa una cosa sola, cifrare file, con molte meno occasioni di sbagliare.

Sui telefoni, infine, la cifratura è ormai attiva di default su Android e iOS, file per file, con le chiavi legate al codice di sblocco e a un chip dedicato. Lì il punto debole è quasi sempre un codice di quattro o sei cifre.

9. Backdoor: che cosa sappiamo davvero

Il sospetto verso governi e aziende non è paranoia. Ha precedenti documentati, e conviene conoscerli per distinguere ciò che è provato da ciò che è solo plausibile.

• Nel 1993 il governo statunitense propose il Clipper chip: cifratura per le telefonate con una copia della chiave depositata presso lo Stato. Il progetto fallì, ma l’idea del deposito delle chiavi non è mai stata abbandonata.
• Tra i documenti pubblicati da Edward Snowden nel 2013 c’è il programma Bullrun, con cui l’NSA lavorava per indebolire gli standard e i prodotti crittografici commerciali.
• Lo stesso anno emerse che il generatore di numeri casuali Dual_EC_DRBG, standardizzato dal NIST, conteneva con ogni probabilità una porta di servizio dell’NSA, e che la società RSA aveva ricevuto dieci milioni di dollari per farne l’opzione predefinita in un proprio prodotto. Il NIST lo ha ritirato nel 2014.

Da qui si ricavano tre cose. Primo: gli attacchi noti non hanno colpito AES o SHA-2, ma i generatori di numeri casuali, le implementazioni e la gestione delle chiavi. Secondo: la via più comoda non è una backdoor nascosta, è una copia della chiave ottenuta per via legale, come nel caso BitLocker. Terzo: l’unica difesa strutturale è poter leggere il codice, e non basta.

Su quest’ultimo punto bisogna essere onesti. Anche il software libero può contenere telemetria, e a volte l’ha contenuta; la differenza è che la si vede e la si può togliere. E il codice aperto non è sicuro perché è aperto: lo è se qualcuno lo legge, e i componenti critici, come si è visto con GRUB, sono spesso mantenuti da poche persone con pochi mezzi. Non è una questione di aperto contro chiuso presa in astratto: è una questione di chi può verificare, e di chi lo fa davvero. Ne parlo più a fondo in Come preferire il software libero al software proprietario.

10. E i computer quantistici?

Meno di quanto si teme, per i dischi. L’algoritmo quantistico di Grover dimezza la robustezza effettiva di una chiave simmetrica: AES-256 scende all’equivalente di 128 bit, che resta fuori portata. Il rischio serio riguarda la crittografia a chiave pubblica (RSA, curve ellittiche), cioè lo scambio di chiavi e le firme: quindi le comunicazioni, non i volumi cifrati con una passphrase. Per quella parte il NIST ha pubblicato nel 2024 i primi standard resistenti.

La conseguenza pratica è una sola: dove si può scegliere, usare chiavi a 256 bit.

11. Che cosa scegliere

Qualunque sia lo strumento, valgono le stesse regole.

1. Una passphrase lunga, di più parole, usata solo per il disco.
2. Una copia della chiave di recupero o dell’header, su carta o su un supporto separato, mai nel cloud del produttore.
3. Spegnere, non sospendere, quando il dispositivo esce dal proprio controllo.
4. Tenere aggiornati firmware e boot loader: sono la porta d’ingresso della cifratura.
5. Fare backup, cifrati anche quelli. La cifratura protegge la riservatezza; solo le copie proteggono dalla perdita.
6. Non considerarla una difesa dal malware. A sessione aperta, il disco è in chiaro.

12. Conclusioni

La crittografia è in continua evoluzione. Da una parte prosegue la corsa a rompere le chiavi, anche con i calcolatori quantistici; dall’altra, e conta di più, si lavora per ottenere le chiavi senza romperle: indebolendo uno standard, depositandone una copia in un servizio online, sfruttando un componente trascurato della catena di avvio.

Cifrare i propri dati resta la misura più efficace contro la perdita fisica di un dispositivo, ed è il primo passo per riprendersi la proprietà di ciò che si conserva. Ma è un primo passo: non sostituisce la scelta di un sistema che si possa ispezionare, né la cura con cui lo si amministra. Le possibilità sono queste. Sta a ciascuno decidere a chi affidare la propria chiave, e la risposta migliore resta: a nessuno.

Riferimenti

• Forbes, Microsoft Gave FBI BitLocker Encryption Keys (gennaio 2026)
• Microsoft, Configure BitLocker
• GNU GRUB, segnalazione 55093 sul supporto a LUKS2 e patch di Patrick Steinhardt, 2019
• GRUB 2.14 con Argon2 e la guida di mdleom per le versioni precedenti
• Ubuntu, Full Disk Encryption Howto 2019
• Klara Systems, OpenZFS Native Encryption
• OpenZFS, discussione sui problemi della cifratura nativa
• Proxmox Forum, Understanding and minimizing ZFS write amplification
• ZFSBootMenu, VeraCrypt, GnuPG