Un portatile rubato, un disco dismesso senza wipe, un backup finito nelle mani sbagliate: in tutti questi casi la differenza tra un incidente trascurabile e una violazione di dati seria sta in una sola cosa, la crittografia del disco. Su Linux lo standard di riferimento si chiama LUKS (Linux Unified Key Setup) e su Ubuntu si gestisce con lo strumento cryptsetup. In questa guida pratica configuriamo un volume cifrato LUKS2 da zero, passo dopo passo, con cifrario AES-256 in modalità XTS e derivazione della chiave Argon2id.

L’obiettivo è concreto: al termine avrai un disco (o una partizione) completamente cifrato, sbloccabile con passphrase o file di chiave, con backup dell’header, montaggio automatico al boot e una procedura di ri-crittografia testata. Tutti i comandi sono verificati su Ubuntu 24.04 LTS e versioni successive, ma valgono per qualsiasi distribuzione basata su cryptsetup 2.7 o superiore. Tempo stimato: circa 35 minuti, esclusa la ri-crittografia di dischi molto grandi.

Una premessa che ripeteremo più volte perché è quella che fa perdere i dati a chi sbaglia: l’header LUKS contiene il materiale necessario a sbloccare il volume. Se si corrompe e non hai un backup, i dati sono persi per sempre. Non esiste recupero. La cifratura funziona, ed è proprio questo il problema quando la usi senza rete di sicurezza.

Cos’è LUKS e perché cifrare il disco nel 2026

LUKS è il formato standard per la crittografia dei dischi a blocchi su Linux. Non è un algoritmo di cifratura: è uno strato di gestione delle chiavi costruito sopra il sottosistema dm-crypt del kernel. In pratica LUKS definisce come l’header del volume memorizza i parametri crittografici (cifrario, modalità, dimensione della chiave) e fino a più chiavi utente, ognuna in uno spazio chiamato keyslot. La chiave master che cifra davvero i dati resta una sola; le passphrase la proteggono in copie multiple.

Il default di LUKS2 nel 2026 è solido e non richiede tuning per la maggior parte degli utenti: cifrario aes-xts-plain64 con chiave da 512 bit. Attenzione al numero: in modalità XTS la chiave da 512 bit corrisponde a AES-256, perché XTS usa due chiavi AES separate da 256 bit ciascuna. La derivazione della passphrase passa per Argon2id, la funzione vincitrice della Password Hashing Competition, progettata per resistere sia ad attacchi su GPU sia ad attacchi side-channel. Questo è il cambiamento crittografico più importante rispetto a LUKS1, che usava PBKDF2.

Perché farlo nel 2026? Tre motivi pratici. Primo, la crittografia del disco è l’unica difesa contro l’accesso fisico: un firewall non serve a niente se qualcuno smonta il tuo SSD e lo collega a un’altra macchina. Secondo, è un requisito di conformità sempre più esplicito. Il Regolamento DORA e la direttiva NIS2 trattano la protezione dei dati a riposo come misura tecnica attesa, e il GDPR la cita come esempio di misura adeguata all’articolo 32. Terzo, il costo prestazionale è quasi nullo su qualsiasi CPU moderna grazie all’accelerazione hardware AES-NI: parliamo di pochi punti percentuali di overhead, non di un dimezzamento delle prestazioni.

Una distinzione utile rispetto ad altri strumenti: LUKS è la cifratura nativa di Linux, integrata nel kernel e nel processo di boot. Soluzioni come VeraCrypt sono multipiattaforma e lavorano in user space tramite container, scelta migliore se devi spostare dati cifrati tra Linux, Windows e macOS. Per cifrare il disco di sistema di un server o di un portatile Ubuntu, LUKS è la risposta corretta.

LUKS1 vs LUKS2: header JSON, Argon2id e 32 keyslot

Da diversi anni LUKS2 è il formato predefinito quando crei un nuovo volume su Ubuntu, ma capire le differenze ti aiuta a non commettere errori e a sapere quando, eccezionalmente, conviene ancora LUKS1 (per esempio con bootloader datati che non supportano LUKS2). La tabella seguente riassume i punti che contano nella pratica.

CaratteristicaLUKS1LUKS2
Formato headerBinario, struttura rigidaJSON, estensibile e leggibile
KDF predefinitoPBKDF2Argon2id (resistente a GPU e ASIC)
Keyslot disponibili8Fino a 32
Cifrario predefinitoaes-xts-plain64, 256 bitaes-xts-plain64, 512 bit (AES-256)
Backup ridondante dell’headerNoSì, due copie su disco
Token e metadatiNon supportatiToken JSON (es. sblocco con TPM, FIDO2)
Ri-crittografia onlineLimitataSì, con ripresa dopo interruzione
Compatibilità GRUBAmpia, anche versioni datateRichiede GRUB recente per /boot cifrato

Il passaggio a Argon2id è la ragione di sicurezza principale per cui dovresti usare LUKS2. PBKDF2 difende dagli attacchi a forza bruta aumentando il numero di iterazioni, ma è un calcolo che le GPU eseguono in parallelo con grande efficienza. Argon2id aggiunge un costo in memoria deliberatamente alto: per ogni tentativo di passphrase l’attaccante deve allocare centinaia di megabyte di RAM, il che rende l’attacco massivo su schede grafiche economicamente proibitivo. È la stessa famiglia di funzioni che consigliamo per l’hashing delle password lato server, applicata qui alla protezione della chiave del disco.

L’header JSON di LUKS2 introduce anche i token, metadati che descrivono metodi di sblocco alternativi alla passphrase. Sono il fondamento dello sblocco tramite chip TPM o chiave hardware FIDO2, tecniche che vedremo nella sezione avanzata. LUKS2 mantiene inoltre due copie dell’header sul disco, una ridondanza che riduce (ma non elimina) il rischio di perdita per corruzione di un singolo settore.

Prerequisiti: versioni, hardware AES-NI e backup

Prima di toccare un disco, mettiamo in fila gli strumenti e una verifica di sicurezza non negoziabile. Questa guida richiede:

  • Ubuntu 24.04 LTS o successiva (o qualsiasi distribuzione con kernel 5.15+). I comandi sono identici su Debian 12, Fedora 40+ e derivate.
  • cryptsetup 2.7.x o superiore. La serie 2.7 è quella stabile più diffusa nel 2026; il ramo 2.8.x ha introdotto mitigazioni aggiuntive per scenari di macchine virtuali confidenziali. Verificheremo la versione nel primo passo.
  • Privilegi di root tramite sudo. Tutti i comandi che toccano i dispositivi a blocchi li richiedono.
  • Un disco o una partizione di test dedicati. Non usare per esercizio un disco con dati che non puoi perdere.
  • CPU con AES-NI (qualsiasi processore Intel o AMD degli ultimi quindici anni). Non è obbligatoria ma rende l’overhead trascurabile.

La verifica di sicurezza che precede tutto: identifica con certezza il dispositivo corretto. Il comando luksFormat distrugge in modo irreversibile qualsiasi dato presente sul disco indicato. Confondere /dev/sdb con /dev/sda significa cancellare il sistema operativo. Esegui sempre lsblk prima di formattare e leggi la dimensione, il punto di montaggio e l’etichetta per confermare di star puntando al disco giusto.

# Elenca tutti i dischi con dimensione e punto di montaggio
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,LABEL

# Output di esempio
NAME   SIZE TYPE MOUNTPOINT LABEL
sda    476G disk
├─sda1 512M part /boot/efi
└─sda2 475G part /          ubuntu-root
sdb     32G disk                       <- disco di test, nessun mount

In questo esempio il sistema è su sda e il nostro disco di test è sdb da 32 GB, senza punto di montaggio. Da qui in avanti useremo /dev/sdb come dispositivo di destinazione. Sostituiscilo con il tuo identificativo reale a ogni comando.

Step 1 e 2: installare cryptsetup e verificare il supporto

Su Ubuntu il pacchetto cryptsetup è spesso già presente, ma installarlo esplicitamente garantisce anche gli script di integrazione con initramfs necessari per il montaggio al boot. Lo strumento cryptsetup-bin contiene il binario, mentre cryptsetup porta con sé gli hook di sistema.

# Step 1: installazione
sudo apt update
sudo apt install -y cryptsetup

# Step 2: verifica della versione e del supporto kernel
cryptsetup --version
# Output atteso: cryptsetup 2.7.x

# Conferma che il kernel esponga dm-crypt
sudo modprobe dm_crypt
lsmod | grep dm_crypt
# Output: dm_crypt ... presente

Se cryptsetup --version riporta una versione inferiore alla 2.4, alcune opzioni Argon2id avanzate potrebbero non essere disponibili e conviene aggiornare la distribuzione. Su una Ubuntu LTS aggiornata non avrai questo problema. La presenza del modulo dm_crypt conferma che il kernel può creare i dispositivi mappati su cui LUKS appoggia la cifratura.

Verifica anche la presenza dell’accelerazione hardware, perché determina le prestazioni del volume cifrato. La flag aes tra i flag della CPU indica il supporto AES-NI.

grep -m1 -o aes /proc/cpuinfo
# Output: aes  (AES-NI disponibile)

Step 3: eseguire il benchmark crittografico

Prima di cifrare conviene misurare quanto è veloce la tua macchina con i cifrari disponibili. Il comando cryptsetup benchmark non tocca alcun disco: gira solo in memoria e ti dà due informazioni preziose, la velocità di cifratura/decifratura dei cifrari e il costo della funzione di derivazione della chiave.

cryptsetup benchmark

# Output di esempio (i numeri variano in base alla CPU)
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha256     1850431 iterations per second for 256-bit key
PBKDF2-sha512     1290877 iterations per second for 256-bit key
argon2id          4 iterations, 1048576 memory, 4 threads (CPU)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-xts        256b      3650.4 MiB/s      3720.9 MiB/s
        aes-xts        512b      3110.2 MiB/s      3180.5 MiB/s
    serpent-xts        256b       520.1 MiB/s       540.3 MiB/s
    twofish-xts        256b       380.7 MiB/s       395.2 MiB/s

Due letture dell’output. La riga aes-xts 512b mostra la velocità del default LUKS2 (AES-256): valori sopra i 3000 MiB/s confermano che AES-NI è attivo e che la cifratura non sarà il collo di bottiglia, perché è molto più veloce di qualsiasi SSD SATA e in linea con NVMe di fascia media. Il confronto con serpent-xts e twofish-xts (privi di accelerazione hardware) spiega da solo perché AES resta la scelta predefinita: è un ordine di grandezza più rapido.

La riga argon2id mostra i parametri che cryptsetup ha calibrato per la tua macchina: numero di iterazioni, memoria in kibibyte (1048576 = 1 GiB) e thread. Questi valori vengono scelti puntando a un tempo di derivazione di circa due secondi. È un compromesso deliberato: due secondi sono accettabili all’avvio per un utente legittimo, ma moltiplicati per miliardi di tentativi rendono la forza bruta impraticabile.

Step 4: preparare e azzerare il disco di destinazione

Questo passo è opzionale ma consigliato per i dischi nuovi o riutilizzati. Sovrascrivere il dispositivo con dati casuali prima di cifrarlo nasconde quanto spazio è effettivamente in uso: senza questo passaggio, un osservatore potrebbe distinguere i blocchi scritti (con dati cifrati) da quelli mai toccati. Con un volume pieno la differenza si annulla, ma partire da rumore casuale è la prassi pulita.

# Metodo veloce: una sola passata di dati casuali
sudo dd if=/dev/urandom of=/dev/sdb bs=1M status=progress

# Alternativa molto più rapida su dischi grandi: cifratura di zeri
# (si crea un mapping temporaneo che produce rumore ad alta velocità)
sudo cryptsetup open --type plain -d /dev/urandom /dev/sdb wipe_tmp
sudo dd if=/dev/zero of=/dev/mapper/wipe_tmp bs=1M status=progress
sudo cryptsetup close wipe_tmp

Il primo metodo legge direttamente da /dev/urandom ed è limitato dalla velocità del generatore di numeri casuali, in genere qualche centinaio di MiB/s. Il secondo è un trucco classico: si apre un dispositivo cifrato temporaneo con una chiave usa e getta e si scrivono zeri, lasciando che sia AES (accelerato in hardware) a trasformarli in rumore alla massima velocità del disco. Su un disco da 32 GB il primo metodo richiede pochi minuti; su dischi da diversi terabyte il secondo è nettamente preferibile.

Step 5: creare il volume LUKS2 con luksFormat

È il cuore della procedura. luksFormat scrive l’header LUKS2 sul disco, genera la chiave master casuale e protegge quella chiave con la passphrase che inserisci nel primo keyslot. Specifichiamo i parametri esplicitamente anche se coincidono con i default: rende il comando documentato e riproducibile.

sudo cryptsetup luksFormat \
  --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha256 \
  --pbkdf argon2id \
  --use-random \
  /dev/sdb

# Avviso e conferma richiesti dallo strumento
WARNING!
========
This will overwrite data on /dev/sdb irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdb: ********************
Verify passphrase: ********************

Nota che la conferma richiede YES in maiuscolo: è una barriera deliberata contro le formattazioni accidentali. La passphrase che inserisci qui è l’unica via per recuperare i dati: se la dimentichi, non esiste backdoor. Usa una frase lunga e ad alta entropia, idealmente una sequenza di parole casuali memorizzabile (passphrase tipo diceware) piuttosto che una password corta e complicata. Per la teoria su entropia e robustezza, vedi la nostra guida alla sicurezza delle password.

Verifichiamo subito il risultato con luksDump, che mostra l’header in chiaro (i metadati, non la chiave): è il modo per confermare che cifrario, KDF e keyslot siano quelli attesi.

sudo cryptsetup luksDump /dev/sdb

# Estratto dell'output
LUKS header information
Version:        2
Epoch:          3
Cipher name:    aes
Cipher mode:    xts-plain64
Keyslots:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        PBKDF:      argon2id
        Time cost:  4
        Memory:     1048576
        Threads:    4

Step 6: aprire e formattare il filesystem

Il volume esiste ma è cifrato e non utilizzabile finché non lo “apri”. luksOpen chiede la passphrase, ricostruisce la chiave master e crea un dispositivo mappato sotto /dev/mapper/. Quel dispositivo si comporta come un disco normale: tutto ciò che ci scrivi viene cifrato in modo trasparente prima di toccare il supporto fisico.

# Apertura del volume con nome logico "datavault"
sudo cryptsetup open /dev/sdb datavault
Enter passphrase for /dev/sdb: ********************

# Ora esiste il dispositivo mappato
ls -l /dev/mapper/datavault

# Creazione del filesystem sul dispositivo mappato, NON sul disco grezzo
sudo mkfs.ext4 -L datavault /dev/mapper/datavault

Punto critico da non sbagliare: il filesystem va creato su /dev/mapper/datavault, mai su /dev/sdb. Formattare il disco grezzo sovrascriverebbe l’header LUKS appena creato e distruggerebbe il volume. La regola mnemonica è semplice: dopo luksFormat, tutto il lavoro si fa sul dispositivo /dev/mapper/<nome>, mai più sul dispositivo fisico.

Step 7: montare, usare e smontare il volume

Con il filesystem creato, montare il volume è identico a montare qualsiasi disco. Creiamo un punto di montaggio, lo colleghiamo e verifichiamo che la scrittura funzioni.

sudo mkdir -p /mnt/datavault
sudo mount /dev/mapper/datavault /mnt/datavault

# Test di scrittura e lettura
echo "dati riservati" | sudo tee /mnt/datavault/test.txt
cat /mnt/datavault/test.txt

# Verifica dello spazio
df -h /mnt/datavault

# Chiusura ordinata: prima smonta, poi chiudi il volume LUKS
sudo umount /mnt/datavault
sudo cryptsetup close datavault

L’ordine di chiusura conta. Devi sempre smontare il filesystem (umount) prima di chiudere il volume LUKS (cryptsetup close). Se inverti i due passi otterrai un errore “device is busy” perché il filesystem sta ancora usando il dispositivo mappato. Dopo cryptsetup close il dispositivo sotto /dev/mapper/ sparisce e i dati tornano inaccessibili senza la passphrase: questo è esattamente lo stato in cui il disco offre protezione.

Step 8: aggiungere e gestire le passphrase nei keyslot

LUKS2 offre fino a 32 keyslot, e questo abilita scenari reali: una passphrase principale per l’amministratore, una secondaria per un collega, una di emergenza conservata in cassaforte. Ogni keyslot protegge una copia della stessa chiave master, quindi revocare un keyslot non richiede di ri-cifrare i dati.

# Aggiungere una nuova passphrase (richiede una esistente per autorizzare)
sudo cryptsetup luksAddKey /dev/sdb
Enter any existing passphrase: ********************
Enter new passphrase: ********************
Verify passphrase: ********************

# Cambiare una passphrase esistente in uno slot
sudo cryptsetup luksChangeKey /dev/sdb

# Vedere quali keyslot sono occupati
sudo cryptsetup luksDump /dev/sdb | grep -A1 Keyslots

# Revocare (cancellare) il keyslot numero 1
sudo cryptsetup luksKillSlot /dev/sdb 1

Attenzione a luksKillSlot: cancella lo slot indicato senza chiedere quale passphrase corrisponda. Prima di rimuovere uno slot, assicurati di sapere quale passphrase stai eliminando e di averne almeno un’altra funzionante. Cancellare l’ultimo keyslot rende il volume permanentemente inaccessibile, perché senza alcuna passphrase non c’è modo di ricostruire la chiave master. Lo strumento ti avvisa se stai per rimuovere l’ultimo slot, ma non fare affidamento solo su quel controllo.

Step 9: backup e ripristino dell’header LUKS

Questo è il passo che separa chi usa LUKS con criterio da chi un giorno perderà i dati. L’header contiene i keyslot e i metadati: un settore corrotto, un comando sbagliato o un firmware difettoso possono danneggiarlo. Se succede e non hai un backup, nessuna passphrase potrà più sbloccare il volume. Il backup dell’header è la tua polizza assicurativa.

# Creare il backup dell'header su file
sudo cryptsetup luksHeaderBackup /dev/sdb \
  --header-backup-file ~/datavault-header.img

# Proteggi il file: contiene i keyslot cifrati
chmod 600 ~/datavault-header.img

# Ripristino dell'header in caso di corruzione
sudo cryptsetup luksHeaderRestore /dev/sdb \
  --header-backup-file ~/datavault-header.img

Due avvertenze fondamentali. Primo: conserva il backup dell’header su un supporto diverso e in luogo sicuro, non sullo stesso disco che stai cifrando. Un backup dell’header che vive sul disco fallito non serve a nulla. Secondo: il file dell’header è sensibile quanto il disco stesso. Contiene i keyslot, quindi chiunque lo ottenga può tentare un attacco a forza bruta offline sulle tue passphrase con tutta la potenza di calcolo che vuole. Trattalo come un segreto e considera di cifrarlo a sua volta (per esempio con GPG) prima di archiviarlo.

Un dettaglio di sicurezza che molti ignorano: se cambi o revochi una passphrase dopo aver fatto il backup, il vecchio backup dell’header contiene ancora il keyslot della passphrase rimossa. Per una revoca davvero efficace devi aggiornare anche il backup, altrimenti la passphrase che credevi cancellata resta valida tramite la copia dell’header.

Step 10: montaggio automatico con crypttab e fstab

Finora abbiamo aperto e montato il volume a mano. Per un disco dati che deve essere disponibile a ogni avvio, configuriamo lo sblocco automatico con il file /etc/crypttab (che gestisce l’apertura LUKS) e /etc/fstab (che gestisce il montaggio del filesystem). Identifichiamo il disco tramite UUID, perché i nomi come /dev/sdb possono cambiare tra un boot e l’altro.

# Ricava l'UUID del dispositivo fisico cifrato
sudo blkid /dev/sdb
# /dev/sdb: UUID="a1b2c3d4-...." TYPE="crypto_LUKS"

# /etc/crypttab  (nome_logico  sorgente  chiave  opzioni)
datavault  UUID=a1b2c3d4-....  none  luks

# Ricava l'UUID del filesystem interno (a volume aperto)
sudo blkid /dev/mapper/datavault

# /etc/fstab
/dev/mapper/datavault  /mnt/datavault  ext4  defaults  0  2

Con la chiave impostata a none, al boot il sistema chiederà la passphrase in modo interattivo. Dopo aver modificato crypttab bisogna rigenerare l’initramfs perché lo sblocco al boot funzioni: sudo update-initramfs -u. Prova sempre la configurazione con un riavvio controllato e tieni a portata di mano un supporto di ripristino: un errore in fstab con un volume cifrato può bloccare l’avvio del sistema. Per il root cifrato vale la stessa logica di hardening del server: piccoli errori di configurazione hanno conseguenze grandi, quindi si testa in ambiente controllato.

Step 11: sblocco con file di chiave e detached header

Inserire la passphrase a ogni avvio non è pratico sui server. La soluzione è un file di chiave: un file di byte casuali registrato in un keyslot, che crypttab può leggere automaticamente. La sicurezza si sposta allora sulla protezione di quel file.

# Genera un file di chiave da 4096 byte casuali
sudo dd if=/dev/urandom of=/root/datavault.key bs=512 count=8
sudo chmod 600 /root/datavault.key

# Registra il file di chiave in un nuovo keyslot
sudo cryptsetup luksAddKey /dev/sdb /root/datavault.key

# In /etc/crypttab usa il file al posto di "none"
datavault  UUID=a1b2c3d4-....  /root/datavault.key  luks

Il file di chiave va conservato su un volume già protetto, tipicamente il disco di sistema cifrato: mettere la chiave di un disco dati in chiaro sullo stesso disco non protetto annullerebbe la cifratura. Una variante avanzata è l’header separato (detached header), in cui i metadati LUKS non risiedono sul disco dati ma su un dispositivo distinto, per esempio una chiavetta USB. Senza quella chiavetta il disco appare come rumore casuale indistinguibile, senza nemmeno la firma crypto_LUKS.

# Creare un volume con header separato su un altro dispositivo
sudo cryptsetup luksFormat --type luks2 \
  --header /mnt/usb/datavault.hdr /dev/sdb

# Aprirlo richiede di indicare l'header
sudo cryptsetup open --header /mnt/usb/datavault.hdr /dev/sdb datavault

Step 12: ri-crittografia con cryptsetup reencrypt

A volte serve cambiare la chiave master vera e propria, non solo una passphrase: dopo il sospetto di una compromissione, o per migrare i parametri crittografici di un vecchio volume. cryptsetup reencrypt ri-cifra l’intero contenuto sul posto, senza decifrarlo a plaintext intermedio, e può riprendere se l’operazione viene interrotta.

# Backup dell'header PRIMA di iniziare (obbligatorio)
sudo cryptsetup luksHeaderBackup /dev/sdb \
  --header-backup-file ~/pre-reencrypt.img

# Ri-crittografia con nuova chiave master
sudo cryptsetup reencrypt /dev/sdb
Enter passphrase: ********************
Progress: 64.2%, ETA 00:03, ... written

# In caso di interruzione, riprendere con
sudo cryptsetup reencrypt --resume-only /dev/sdb

La ri-crittografia è un’operazione lunga e a rischio per definizione: sposta ogni blocco del disco. Esegui sempre un backup dell’header prima di iniziare e, se possibile, un backup completo dei dati. Per un disco da diversi terabyte parliamo di ore. Una interruzione di corrente durante reencrypt senza UPS è lo scenario in cui i metadati di avanzamento (che LUKS2 salva nell’header) e l’opzione --resume-only ti salvano: ecco perché si ri-cifra solo su LUKS2 e mai senza copia dell’header.

6 errori comuni da evitare con LUKS

La maggior parte delle perdite di dati con LUKS non dipende da debolezze della cifratura, ma da errori operativi. Ecco i sei più frequenti e come prevenirli.

  • Nessun backup dell’header. È l’errore numero uno. Un header corrotto senza backup significa dati persi al 100%. Esegui luksHeaderBackup subito dopo luksFormat e dopo ogni modifica ai keyslot.
  • Formattare il dispositivo sbagliato. Confondere /dev/sdb con /dev/sda cancella il sistema. Esegui lsblk e conferma dimensione ed etichetta prima di ogni luksFormat.
  • Creare il filesystem sul disco grezzo. mkfs va eseguito su /dev/mapper/<nome>, mai sul dispositivo fisico, altrimenti distruggi l’header appena scritto.
  • Passphrase debole. AES-256 è inattaccabile, ma una passphrase corta no. La forza dell’intero sistema è quella della passphrase più debole tra i keyslot attivi.
  • File di chiave su volume non cifrato. Tenere il file di chiave in chiaro accanto al disco che dovrebbe proteggere vanifica la cifratura. La chiave va su un supporto già protetto.
  • Dimenticare di rigenerare l’initramfs. Dopo aver modificato crypttab per il volume di root, saltare update-initramfs -u può rendere il sistema non avviabile.

Risoluzione dei problemi: 8 casi frequenti

Una raccolta dei messaggi di errore più comuni con LUKS e cryptsetup, con la causa e la soluzione pratica.

Sintomo / erroreCausaSoluzione
No key available with this passphrasePassphrase errata o keyslot revocatoRiprova; verifica i keyslot con luksDump; prova una passphrase di emergenza
Device /dev/mapper/x is busyFilesystem ancora montatoEsegui umount prima di cryptsetup close; usa lsof per trovare i processi
Device already exists or activeNome di mapping già in usoScegli un altro nome o chiudi il mapping esistente con cryptsetup close
Cannot read device ... headerHeader corrotto o dispositivo sbagliatoRipristina con luksHeaderRestore dal backup
Boot bloccato dopo modifica a crypttabUUID errato o initramfs non aggiornatoAvvia da live USB, correggi crypttab, esegui update-initramfs -u
Prestazioni di I/O molto basseAES-NI non attivo o cifrario lentoVerifica grep aes /proc/cpuinfo; usa aes-xts, non serpent/twofish
Requested offset is beyond real sizeHeader separato non corrispondente al discoIndica l’header corretto con --header
Cannot wipe device headerPermessi insufficienti o disco protetto in scritturaUsa sudo; controlla che il disco non sia in sola lettura

Per il caso più temuto, l’header danneggiato, la sequenza di recupero è: avvia da supporto live, collega il backup dell’header, esegui luksHeaderRestore sul dispositivo, poi prova ad aprire il volume. Se non hai un backup dell’header, l’unica speranza residua è che la chiave master sia ancora caricata in un sistema attivo (recuperabile da utenti esperti con dmsetup), ma è uno scenario eccezionale e non una procedura su cui contare. La lezione resta una sola: fai il backup dell’header.

Tecniche avanzate: TPM, FIDO2, LVM e TRIM

Una volta padroneggiate le basi, LUKS2 si presta a configurazioni più sofisticate che migliorano sicurezza o usabilità.

Sblocco automatico con TPM 2.0

Il chip TPM presente sulle macchine moderne può conservare un segreto e rilasciarlo solo se lo stato di boot non è stato manomesso. Con systemd-cryptenroll puoi legare un keyslot LUKS2 al TPM, così il disco si sblocca automaticamente all’avvio sulla macchina autorizzata, senza passphrase, ma resta cifrato se il disco viene spostato altrove. Le versioni recenti di Ubuntu offrono una variante sperimentale di cifratura del disco completa con sblocco basato su TPM direttamente dall’installer. Il compromesso da capire: lo sblocco automatico via TPM protegge dal furto del disco, non da chi accende il tuo portatile già configurato.

# Legare un keyslot LUKS2 al TPM 2.0
sudo systemd-cryptenroll --tpm2-device=auto /dev/sdb

# Sblocco con chiave hardware FIDO2 (es. token compatibile)
sudo systemd-cryptenroll --fido2-device=auto /dev/sdb

LUKS sotto LVM e gestione del TRIM

L’installer di Ubuntu propone uno schema LVM-on-LUKS: un unico volume LUKS che contiene un gruppo LVM, dentro cui vivono le partizioni logiche (root, swap, home). Il vantaggio è un solo header da sbloccare e la flessibilità di LVM per ridimensionare i volumi. È la configurazione consigliata per i sistemi desktop e server con cifratura completa.

Sugli SSD esiste un compromesso noto con il TRIM (l’opzione discard). Abilitarlo migliora le prestazioni e la longevità del disco, ma rivela quali blocchi sono inutilizzati, una piccola fuga di informazioni sul pattern di utilizzo. Per la maggior parte degli utenti il guadagno prestazionale supera il rischio teorico; per ambienti ad alta sensibilità si lascia disattivato. La scelta si esprime nelle opzioni di crypttab con discard o la sua assenza.

Verso la crittografia post-quantistica

Una nota di prospettiva. AES-256, il cifrario simmetrico di LUKS, è considerato resistente anche agli attacchi quantistici: l’algoritmo di Grover dimezza la sicurezza effettiva, lasciando comunque 128 bit, ben oltre la soglia pratica. Il punto debole quantistico riguarda la crittografia asimmetrica, non la cifratura simmetrica del disco. In altre parole, un volume LUKS cifrato oggi con AES-256 non è tra i bersagli della transizione post-quantistica, a differenza di TLS e firme digitali. Per il quadro completo vedi il nostro approfondimento sulla crittografia e i suoi sviluppi.

Checklist finale del progetto completo

Riassumiamo l’intero progetto in una sequenza verificabile. Se hai seguito tutti i passi, dovresti poter spuntare ogni voce.

FaseComando chiaveEsito atteso
Verifica strumenticryptsetup --versionVersione 2.7.x o superiore
Benchmarkcryptsetup benchmarkaes-xts oltre 3000 MiB/s
Creazione volumeluksFormat --type luks2Header LUKS2, keyslot 0 attivo
Apertura e filesystemopen + mkfs.ext4Dispositivo in /dev/mapper
Backup headerluksHeaderBackupFile header in luogo sicuro
Montaggio automatico/etc/crypttab + fstabSblocco al boot funzionante
Gestione chiaviluksAddKey / luksKillSlotKeyslot multipli controllati

Domande frequenti su LUKS e la cifratura del disco

LUKS rallenta il computer?

Su qualsiasi CPU con AES-NI (tutte le Intel e AMD degli ultimi quindici anni) l’overhead è di pochi punti percentuali e impercettibile nell’uso quotidiano. Il benchmark dimostra che AES-XTS supera i 3000 MiB/s, più veloce di un SSD SATA e in linea con NVMe di fascia media. Senza accelerazione hardware il costo sale, ma resta accettabile per i carichi normali.

Posso cifrare un disco già pieno di dati senza perderli?

Sì, con cryptsetup reencrypt --encrypt è possibile cifrare sul posto un dispositivo esistente, ma è un’operazione lunga e a rischio. Esegui sempre un backup completo dei dati prima di iniziare e usa un gruppo di continuità per evitare interruzioni di corrente. Per i dati che puoi permetterti di copiare, creare un nuovo volume cifrato e trasferire i file è più semplice e sicuro.

Cosa succede se dimentico la passphrase?

Non esiste recupero. LUKS è progettato proprio perché senza una passphrase valida (o un file di chiave registrato in un keyslot) la chiave master non può essere ricostruita. È la ragione per cui si configurano più keyslot: una passphrase principale e almeno una di emergenza conservata in luogo sicuro. La forza di LUKS è anche il suo rischio.

LUKS protegge i dati mentre il computer è acceso?

No, e questo è un punto cruciale spesso frainteso. Quando il volume è aperto e montato, la chiave master è in RAM e i dati sono accessibili in chiaro al sistema. LUKS protegge i dati a riposo: disco spento, rubato o smontato. Per proteggere un sistema acceso servono altre misure (blocco schermo, controllo degli accessi e attenzione agli attacchi cold boot sulla RAM).

LUKS2 è compatibile con Windows o macOS?

LUKS è nativo di Linux. Su Windows esistono strumenti sperimentali per leggere volumi LUKS, ma non sono affidabili per l’uso quotidiano. Se ti serve cifratura interoperabile tra sistemi operativi, valuta VeraCrypt, che gira nativamente su tutte le piattaforme. Per i dischi Linux, LUKS resta la scelta corretta e meglio integrata.

Devo usare AES o un cifrario diverso?

Usa AES-256 (il default aes-xts-plain64 a 512 bit). È lo standard riconosciuto, beneficia dell’accelerazione hardware ed è considerato sicuro a lungo termine, anche contro gli attacchi quantistici noti. Cifrari come Serpent o Twofish sono robusti ma molto più lenti senza accelerazione dedicata, senza un reale vantaggio di sicurezza per l’uso comune.

Ogni quanto devo fare il backup dell’header?

Subito dopo la creazione del volume, e di nuovo dopo ogni modifica ai keyslot (aggiunta, cambio o revoca di passphrase). Un backup dell’header obsoleto può contenere keyslot che credevi rimossi, riaprendo passphrase revocate. Conserva i backup su un supporto separato e proteggili come segreti, perché consentono attacchi offline alle passphrase.

LUKS è vulnerabile? Ci sono falle note?

Il formato e gli algoritmi (AES-256, Argon2id) sono solidi. Le vulnerabilità storiche di cryptsetup hanno riguardato casi limite, come la gestione dei metadati durante la ri-crittografia, e sono state corrette nelle versioni successive; una segnalazione del 2025 ha riguardato debolezze dei metadati LUKS2 in scenari di macchine virtuali confidenziali, mitigate nel ramo 2.8.x. Mantenere cryptsetup aggiornato all’ultima versione stabile è la misura più efficace contro queste classi di problemi.

Fonti e riferimenti esterni

Ultimo aggiornamento: 16 giugno 2026. I comandi sono stati verificati su Ubuntu 24.04 LTS con cryptsetup 2.7.x. Verifica sempre la versione installata e mantieni un backup dell’header LUKS prima di qualsiasi operazione sui dischi.