LUKS: crittografia dell'intero disco su Linux — Guida completa (2026)

LUKS (Linux Unified Key Setup) è il formato standard di crittografia del disco per Linux, costruito sopra il modulo del kernel dm-crypt. È lo strato di crittografia usato per impostazione predefinita quando selezioni «cifra il disco» durante l’installazione su Fedora, Ubuntu, Debian e la maggior parte delle altre distribuzioni principali. Se usi Linux e ti sta a cuore la protezione dei dati, quasi certamente stai già usando LUKS — o dovresti farlo.

Questa guida tratta LUKS2, la versione attuale del formato (introdotta in cryptsetup 2.0.0, nel 2018). LUKS1 è ancora supportato per compatibilità ma non offre la derivazione della chiave Argon2id di LUKS2, la maggiore flessibilità dell’header e la robustezza migliorata. Le nuove installazioni dovrebbero sempre usare LUKS2.

Come funziona LUKS

LUKS crea una struttura su disco composta da:

1. Un header che contiene i metadati: l’algoritmo di cifratura, la configurazione della funzione di derivazione della chiave (KDF) e fino a 32 slot di chiave. L’header occupa i primi megabyte della partizione LUKS.
2. Slot di chiave: ogni slot contiene una copia cifrata in modo indipendente della chiave master, cifrata con una chiave derivata da una passphrase dell’utente (o da un keyfile). Questo permette a più passphrase o chiavi di sbloccare lo stesso volume — utile per una chiave di recupero accanto a una passphrase quotidiana.
3. L’area dati principale: i dati effettivamente cifrati, che usano la chiave master attraverso lo strato del dispositivo a blocchi dm-crypt.

L’implicazione critica: l’header LUKS è il singolo punto di rottura per il recupero dei dati. Se l’header viene corrotto o sovrascritto, i dati cifrati sono irrecuperabili — indipendentemente dal fatto che tu conosca la passphrase. Il backup dell’header non è opzionale.

Creare un container LUKS2

Cifrare una partizione o un dispositivo a blocchi

# Formatta una partizione come LUKS2 con AES-XTS-512 e KDF Argon2id
sudo cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha256 \
  --pbkdf argon2id \
  --pbkdf-memory 1048576 \
  --pbkdf-time 5000 \
  /dev/sdX2

Ti verrà richiesta una passphrase. L’opzione --pbkdf-memory 1048576 alloca 1 GB di memoria per la derivazione Argon2id, rendendo gli attacchi a forza bruta significativamente più difficili. L’opzione --pbkdf-time 5000 punta a 5 secondi di tempo di sblocco, aumentando ulteriormente il costo degli attacchi a forza bruta. Regola questi parametri in base alla memoria che il tuo ambiente di sblocco (initramfs) può fornire.

Aprire (decifrare) e usare il container

# Apre il container LUKS, creando un dispositivo /dev/mapper/cryptdata
sudo cryptsetup open /dev/sdX2 cryptdata

# Crea un filesystem
sudo mkfs.ext4 /dev/mapper/cryptdata
# oppure btrfs: sudo mkfs.btrfs /dev/mapper/cryptdata

# Monta
sudo mount /dev/mapper/cryptdata /mnt/data

Chiudere il container

sudo umount /mnt/data
sudo cryptsetup close cryptdata

Critico: backup e ripristino dell’header

Il backup dell’header LUKS è il passaggio operativo più importante di questa guida. Senza di esso, la corruzione dei primi megabyte della tua partizione cifrata significa la perdita permanente dei dati.

Creare un backup dell’header

sudo cryptsetup luksHeaderBackup /dev/sdX2 \
  --header-backup-file luks-header-backup-$(date +%Y%m%d).bin

Conserva questo file di backup in almeno due posizioni: una copia offline (unità USB in un luogo fisicamente separato) e una copia su cloud con crittografia indipendente. Una buona opzione è conservarlo in un container VeraCrypt o su Proton Drive — il backup di per sé non contiene i dati, ma chiunque abbia il backup e la tua passphrase può accedere al volume.

Ripristinare un header danneggiato

sudo cryptsetup luksHeaderRestore /dev/sdX2 \
  --header-backup-file luks-header-backup-20260612.bin

Questo sovrascrive l’header attuale con il backup. Se il backup è precedente all’aggiunta di uno slot di chiave, quello slot sparirà dopo il ripristino.

Gestire gli slot di chiave

LUKS2 supporta fino a 32 slot di chiave per header. Usalo per mantenere una passphrase primaria robusta e una chiave di recupero separata conservata offline.

Aggiungere uno slot di chiave

# Aggiunge una nuova passphrase (chiede prima la passphrase esistente)
sudo cryptsetup luksAddKey /dev/sdX2

# Aggiunge un keyfile
sudo cryptsetup luksAddKey /dev/sdX2 /path/to/keyfile.bin

Rimuovere uno slot di chiave

# Rimuove per passphrase (chiede quale rimuovere)
sudo cryptsetup luksRemoveKey /dev/sdX2

# Rimuove per numero di slot (slot 1 in questo esempio)
sudo cryptsetup luksKillSlot /dev/sdX2 1

Visualizzare gli slot di chiave attivi

sudo cryptsetup luksDump /dev/sdX2 | grep -A3 "Keyslot"

Sblocco automatico basato su TPM

Le installazioni moderne su sistemi con un chip TPM2 possono configurare lo sblocco automatico senza passphrase all’avvio, pur proteggendo la chiave contro la rimozione del disco. È adatto a desktop e server dove l’inserimento della passphrase all’avvio è operativamente poco pratico.

Su Fedora e Ubuntu con systemd-cryptenroll:

# Registra il TPM2 per lo slot 0 (richiede la passphrase esistente)
sudo systemd-cryptenroll --tpm2-device=auto /dev/sdX2

# Facoltativamente, vincola ai valori PCR (aggiunge l'imposizione del measured boot)
sudo systemd-cryptenroll --tpm2-device=auto \
  --tpm2-pcrs=0+7 \
  /dev/sdX2

Il PCR 0 copre le misurazioni del firmware; il PCR 7 copre lo stato di Secure Boot. Vincolarsi a questi PCR significa che il TPM rilascerà la chiave solo se lo stato del firmware e di Secure Boot è invariato rispetto al momento della registrazione — proteggendo contro un bootloader modificato.

Limitazione: lo sblocco automatico tramite TPM protegge dalla rimozione del disco, ma non da un aggressore che avvia il sistema normalmente (dovrebbe conoscere la passphrase di uno slot di chiave separato, o compromettere il bootloader senza cambiare i valori PCR). Per un laptop con un modello di minaccia ad alto rischio, un TPM protetto da PIN o un approccio basato solo su passphrase può essere più appropriato. Vedi la guida al rafforzamento di Linux per l’inquadramento più ampio del modello di minaccia.

Benchmark delle prestazioni

Su un moderno SSD NVMe con una CPU che supporta le istruzioni hardware AES-NI (tutti i processori x86-64 da circa il 2010), AES-XTS-512 attraverso dm-crypt aggiunge circa il 2–8% di overhead per i carichi di lavoro sequenziali. L’overhead degli I/O casuali da 4K può essere maggiore — fino al 10–15% su alcuni carichi di lavoro.

Testa il tuo hardware specifico:

sudo cryptsetup benchmark

Questo esegue test di temporizzazione per tutte le combinazioni di cifrari disponibili. Sulla maggior parte dell’hardware moderno, AES-XTS-512 con chiave a 512 bit (256 bit per chiave XTS) raggiunge un throughput sequenziale di 3–8 GB/s — ben oltre la capacità della maggior parte dei dispositivi di archiviazione.

Implicazione pratica: su un laptop moderno con un’unità NVMe, non noterai l’overhead di LUKS durante il normale utilizzo desktop. Potresti notarlo nei carichi di lavoro che spostano centinaia di gigabyte di dati in modo sequenziale (copie di file grandi, montaggio video).

LUKS2 vs VeraCrypt vs BitLocker

Per un confronto dettagliato tra VeraCrypt e LUKS, vedi la guida a VeraCrypt. Per il panorama più ampio della crittografia, incluso l’approccio di Tails alla crittografia del disco, vedi il confronto Qubes vs Tails vs Whonix.

FAQ

D: Se dimentico la mia passphrase LUKS, i dati sono irrecuperabili? R: Sì — è così per progetto. Se nessuno slot di chiave ha una passphrase valida e non esiste alcun keyfile, la chiave master è inaccessibile e i dati non possono essere decifrati. Ecco perché mantenere uno slot per la chiave di recupero (con una seconda passphrase robusta, conservata offline) è essenziale. Scrivi la passphrase di recupero su carta e conservala in un luogo fisicamente sicuro.

D: Come aggiungo la crittografia LUKS a una partizione esistente non cifrata senza perdita di dati? R: Lo strumento cryptsetup-reencrypt supporta la cifratura sul posto dei dati esistenti. È stabile a partire da cryptsetup 2.4.0 ma richiede una preparazione attenta: un backup completo prima di iniziare, un’alimentazione ininterrotta durante il processo e spazio libero alla fine della partizione per l’header. Prima fai una prova su dati non critici.

D: La crittografia LUKS protegge un sistema Linux in ibernazione? R: In parte. Se anche la partizione di swap è cifrata con LUKS (cosa che deve essere, separatamente oppure come volume logico all’interno del container LUKS), allora l’immagine di ibernazione su disco è cifrata. Tuttavia, la chiave di decifratura deve essere caricata al momento della ripresa, cosa che tipicamente richiede la passphrase. Se il tuo sistema riprende automaticamente da un TPM senza passphrase, l’immagine di ibernazione è protetta dall’accesso offline al disco ma non da un attacco a sistema in esecuzione. Vedi la guida al rafforzamento di Linux per la configurazione della crittografia dello swap.