Cifrare un disco VPS con LUKS

La cifratura non è un'impostazione di privacy generica. Risponde a una sola domanda: qualcuno può leggere questi blocchi senza la chiave? Tutto il resto — chi sa che hai noleggiato il server, se il traffico è riconducibile a te, se un tribunale può ordinare qualcosa — vive altrove.

Su un VPS, LUKS difende concretamente da:

• Hardware dismesso o guasto. Le unità NVMe vengono sostituite. La cancellazione sicura su un dispositivo guasto non è sempre possibile — a volte è talmente morto che il controller non accetta più comandi, e lascia comunque il rack.
• Un'immagine offline. Un volume copiato mentre il server è spento — durante un sequestro, una migrazione, un errore — è testo cifrato e resta testo cifrato.
• Backup e snapshot che viaggiano. Tutto ciò che lascia la macchina esce cifrato se viene prelevato dal livello a blocchi sotto il tuo controllo, e dovrebbe essere cifrato lato client se viene prelevato da sopra quel livello.
• Blocchi residui. Quando distruggi un server, gli extent sottostanti vengono prima o poi riutilizzati. La cifratura trasforma ciò che resta in rumore anziché in dati.

Non difende invece una macchina in esecuzione. Mentre il tuo server è acceso, la chiave master risiede nella memoria del kernel, e chiunque sia in grado di estrarre quella memoria legge il tuo disco a prescindere dalla passphrase. Su infrastruttura noleggiata, questo significa l'operatore dell'hypervisor. Lo diciamo nella nostra informativa sulla privacy e lo ripetiamo qui: nessuna funzione di cifratura del disco di alcun provider cambia questo fatto, inclusa la nostra, e qualsiasi provider che affermi il contrario sta descrivendo marketing, non crittografia.

Prima di toccare un terminale, scegli il modello. Differiscono enormemente per impegno richiesto, e la maggior parte delle persone ha bisogno solo del primo.

1. Un volume dati cifrato. Il sistema si avvia normalmente e senza cifratura; un unico albero di directory — una maildir, un database, un archivio — vive dentro un contenitore LUKS che apri manualmente dopo ogni avvio. Dieci minuti di lavoro, nessuna modalità di ripristino, nessun rischio di restare tagliati fuori. Se ciò a cui tieni è un singolo insieme di dati e non l'intera macchina, fermati qui: ottieni gran parte del beneficio con quasi nessuna fragilità. È lo schema che consigliamo nella pagina sul server di posta anonimo.

2. Un volume root cifrato con sblocco remoto. Tutto tranne /boot è cifrato, e ogni avvio si ferma nell'initramfs finché non ti colleghi via SSH e non fornisci la passphrase. È il modello su cui si costruisce il resto di questa guida. Costa un'ora la prima volta e un comando SSH per ogni riavvio, ed è l'unico modello in cui sono coperti anche log, cache dei pacchetti, cronologia della shell e swap — i punti in cui i dati trapelano senza che nessuno l'abbia deciso.

3. Una root cifrata che si sblocca da sola verso un key server che controlli. Come il modello 2, ma Clevis recupera il materiale di sblocco da un server Tang su una macchina in un'altra giurisdizione, così i riavvii non sono presidiati. Il compromesso è preciso e vale la pena capirlo: ora il server può decifrarsi da solo finché il tuo key server dice di sì, il che significa che hai spostato il segreto invece di eliminarlo — ma hai anche guadagnato un interruttore di emergenza remoto. Approfondito più avanti.

Molti host pubblicizzano la “cifratura dei dati a riposo” come una semplice casella da spuntare. Vale la pena essere precisi su cosa significhi di solito questa frase, perché dietro si nascondono due cose molto diverse.

La cifratura con una chiave detenuta dal provider protegge da un'unità rubata e nient'altro. Se il provider può avviare il tuo server senza chiederti nulla, il provider può anche decifrarlo senza chiederti nulla — e lo stesso vale per chiunque possa costringere il provider a farlo. È un controllo reale contro il furto e uno puramente decorativo contro un procedimento legale.

La cifratura con una chiave che detieni tu è la versione che conta davvero, e per costruzione impedisce il riavvio non presidiato. Non è un difetto da eliminare con qualche accorgimento: è la proprietà che fa il lavoro.

Noi forniamo solo la seconda opzione, non configurata, e lasciamo decidere a te. Ciò che deteniamo è più limitato ed è documentato: le password di root dei server sono memorizzate cifrate in AES-256-CBC a livello di riga, non conserviamo flow log né catture di pacchetti, e un warrant canary firmato viene pubblicato a cadenza regolare. Niente di tutto ciò sostituisce una chiave tua — è solo la parte di cui possiamo essere ritenuti responsabili nel frattempo.

I valori predefiniti sono validi. Vale la pena modificarne due.

Cifrario. aes-xts-plain64 con una chiave a 512 bit è il valore predefinito ed è la scelta giusta — i 512 bit sono due chiavi da 256 bit, quindi si tratta di AES-256 in modalità XTS, e ogni CPU su cui giriamo dispone di AES-NI. Su una macchina priva di accelerazione AES preferiresti xchacha20,aes-adiantum-plain64, ma non è il caso del nostro hardware, e probabilmente nemmeno del tuo.

Derivazione della chiave. LUKS2 usa di default Argon2id, che è deliberatamente memory-hard. Al momento della formattazione cryptsetup fa un benchmark della macchina e sceglie un costo di memoria in base alla RAM che riesce a vedere — ed ecco la trappola che genera la maggior parte delle segnalazioni del tipo “il mio server cifrato non si avvia”: l'initramfs ha meno memoria utilizzabile del sistema in esecuzione, e se hai formattato il volume in un ambiente di ripristino con più RAM di quanta ne abbia il piano di destinazione, lo sblocco può fallire o essere interrotto all'avvio. Fissala esplicitamente. Un GiB di memoria per Argon2 è un costo notevole per un attaccante ed è comodamente alla portata di un S1 da 4 GB:

cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 --hash sha256 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 \
  /dev/vda2

--pbkdf-memory è espresso in KiB, quindi 1048576 equivale a 1 GiB. Verifica in seguito cosa è stato effettivamente scritto nell'header con cryptsetup luksDump /dev/vda2 — la sezione dello slot di chiave riporta i valori di memoria e il numero di iterazioni che verranno usati, e leggerli una volta costa meno di un avvio fallito.

La passphrase. Argon2 guadagna tempo contro una passphrase debole; non la salva. Usa una frase diceware di almeno sei parole. È l'unico segreto del sistema, e nessuna funzione di derivazione della chiave compensa una passphrase scadente.

Un avvio Linux con root cifrata ha un problema dell'uovo e della gallina: il kernel e l'initramfs devono caricarsi prima che qualcosa possa chiedere una passphrase, ma entrambi risiedono sul disco che stai cercando di sbloccare. La risposta standard è una piccola partizione /boot non cifrata che contiene il kernel, l'initramfs e il bootloader. Tutto il resto va dentro LUKS.

L'initramfs a quel punto si ferma e chiede la passphrase. Su un laptop la digiti e basta. Su un server a tremila chilometri di distanza, ti serve una delle due cose seguenti:

• La console. Ogni server nella tua dashboard ha una console noVNC, e funziona — ma i tasti premuti attraversano la nostra infrastruttura, che è esattamente la parte che la tua chiave dovrebbe escludere. Va bene per un recupero occasionale, sbagliata come abitudine.
• Un server SSH dentro l'initramfs. dropbear-initramfs pesa circa 200 KB, attiva la rete, resta in ascolto sulla porta che scegli, accetta una delle tue chiavi pubbliche e ti porta dritto al prompt di sblocco. La passphrase è cifrata end-to-end dal tuo laptop fino all'initramfs. Questa è la risposta giusta.

Due dettagli traggono facilmente in inganno. Il Dropbear dell'initramfs ha una propria chiave host, quindi il suo fingerprint è diverso da quello del tuo demone SSH abituale — è normale, non è un attacco man-in-the-middle, e merita un proprio file known_hosts piuttosto che l'abitudine di digitare sempre yes. E il nome dell'interfaccia deve essere corretto: le schede di rete virtio su Debian 13 di solito compaiono come ens3 o enp1s0, non eth0. Controlla con ip -br link prima di scrivere la configurazione, perché sbagliare significa un initramfs senza rete e un viaggio obbligato alla console.

Se la macchina deve tornare operativa da sola — dopo un aggiornamento del kernel, un riavvio dell'host, un'interruzione di corrente — digitare una passphrase non è praticabile. Clevis vincola uno slot di chiave LUKS a una policy esterna, e Tang è un piccolo server di scambio chiavi che ne implementa la versione utile più semplice.

# on a small server you control, elsewhere
apt install -y tang
systemctl enable --now tangd.socket

# on the encrypted VPS
apt install -y clevis clevis-luks clevis-initramfs
clevis luks bind -d /dev/vda2 tang '{"url":"http://tang.internal:7500"}'
update-initramfs -u -k all

All'avvio, l'initramfs esegue uno scambio McCallum-Relyea con Tang e recupera la chiave senza che il server Tang la venga mai a conoscere né veda la passphrase. Vale la pena precisare bene le proprietà in gioco:

• Il VPS si decifra da solo solo finché riesce a raggiungere Tang. Spegni Tang, o ruota le sue chiavi, e il riavvio successivo si blocca del tutto. È un vero interruttore di emergenza remoto — insolito e utile.
• Tang non dovrebbe stare sulla rete internet pubblica. Raggiungilo via WireGuard o come servizio onion di Tor; trattiamo la parte relativa al tunnel nella guida a WireGuard.
• Metti Tang in una giurisdizione diversa da quella dei dati. Le nostre pagine sulle giurisdizioni esistono proprio per questo tipo di separazione.
• Mantieni una passphrase in un altro slot di chiave. Clevis è un livello di comodità, non l'unico modo per accedere.

Renditi conto di cosa hai costruito: una macchina non presidiata detiene la propria chiave per procura, quindi un avversario che sequestra il VPS mentre è in esecuzione, o che riesce a raggiungere il tuo server Tang, ottiene i dati. È un indebolimento reale rispetto a una passphrase che tieni in testa. Scegli questa strada quando la disponibilità conta più dell'ultimo grado di segretezza, e non per abitudine.

Una root cifrata copre gran parte della superficie, ma alcuni percorsi scrivono al di fuori di essa o le sopravvivono.

• Swap. Qualsiasi cosa in RAM può finire su disco tramite il paging — chiavi, corpi di messaggi, buffer decifrati. Se lo swap vive dentro il volume cifrato come file di swap, è coperto. Una partizione di swap separata non lo è, a meno che tu non la aggiunga a /etc/crypttab con una chiave casuale che cambia a ogni avvio: cryptswap /dev/vda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256. Su un VPS il file di swap è più semplice e non c'è motivo di preferire la partizione.
• /tmp. Montalo come tmpfs (tmpfs /tmp tmpfs defaults,nosuid,nodev,size=512M 0 0) così non tocca mai il disco. Anche più veloce.
• Ibernazione. Scrive tutta la RAM, chiave master inclusa, sul dispositivo di swap. Non abilitarla. Sulle nostre immagini è disattivata di default.
• Il /boot non cifrato. Kernel, immagini initramfs e configurazione di GRUB sono leggibili e, cosa più importante, scrivibili da chiunque abbia accesso offline al disco. LUKS ti dà la riservatezza, non l'integrità dell'avvio. Se il tuo modello di minaccia include qualcuno che manomette il bootloader, la sola cifratura non se ne accorgerà — registra gli hash di /boot dopo ogni aggiornamento del kernel e verificali dall'esterno, oppure accetta consapevolmente questo margine scoperto.
• Snapshot esistenti e volumi vecchi. Cifrare oggi non fa nulla per un'immagine presa ieri. Se il server ha mai girato non cifrato con dati a cui tieni, considera quei dati come esposti e ruota tutto ciò che ne deriva.

Il sovraccarico è abbastanza piccolo da non dover guidare la decisione, ma non è pari a zero. Misura prima di speculare:

cryptsetup benchmark

Sui nostri nodi EPYC, aes-xts con chiave a 512 bit ottiene benchmark nell'ordine di pochi gigabyte al secondo per core — ben al di sopra di quanto un singolo volume NVMe possa mai richiedere. Il costo che si manifesta davvero è la latenza e il carico CPU sulle piccole scritture casuali, non il throughput.

Due flag di LUKS2 contano su NVMe, dove le code di lavoro dm-crypt del kernel aggiungono latenza invece di eliminarla. Impostale e rendile permanenti nell'header:

cryptsetup refresh cryptroot \
  --perf-no_read_workqueue --perf-no_write_workqueue --persistent

Il terzo flag, --allow-discards, inoltra il TRIM al dispositivo sottostante. Mantiene bassa l'amplificazione di scrittura per tutta la vita del volume, al costo di rivelare quali blocchi sono inutilizzati — il che lascia trapelare a chiunque legga il dispositivo grezzo la dimensione e la forma approssimativa dei tuoi dati. Abilitalo per un server per uso generico; lascialo disattivato se il fatto stesso che un volume sia pieno al 3% è sensibile. Non esiste una risposta universalmente giusta, solo una decisione che dovresti prendere consapevolmente.

L'header LUKS occupa circa 16 MB all'inizio della partizione e contiene le copie cifrate della chiave master. Danneggialo — un dd digitato male, uno strumento di partizionamento che riscrive premurosamente l'inizio del dispositivo — e ogni byte che segue è perduto. Non esiste un servizio di recupero. Non ne abbiamo una copia.

# back it up, off the server, before you put data on the volume
cryptsetup luksHeaderBackup /dev/vda2 \
  --header-backup-file luks-header-$(date +%F).img

# add a second passphrase while you still have the first
cryptsetup luksAddKey /dev/vda2

# see what is in the header
cryptsetup luksDump /dev/vda2

Due cose su questo backup. È sensibile quanto il disco: contiene gli slot di chiave, quindi un header vecchio ripristinato dopo che hai cambiato la passphrase accetterà volentieri quella vecchia. Conservalo come conservi la passphrase, e distruggi le copie superate quando la ruoti. In secondo luogo, LUKS2 mette a disposizione 32 slot di chiave — usane almeno due, con quello di riserva impostato su una lunga passphrase casuale conservata in un posto diverso da quello della passphrase quotidiana. La modalità di guasto che questo previene è banale e comune: ruoti la passphrase, la digiti male in modo identico due volte, e lo scopri al riavvio successivo invece che al login successivo.

Prevedi anche una via per rientrare. La modalità di ripristino avvia il server dalla nostra ISO con le tue chiavi SSH iniettate e il volume cifrato intatto, il che significa che puoi eseguire cryptsetup open /dev/vda2 rescue && mount /dev/mapper/rescue /mnt e riparare un crypttab danneggiato o un initramfs difettoso senza perdere i dati. Provalo una volta, deliberatamente, mentre non c'è alcun problema in corso.

La cosa più utile che una guida come questa possa fare è segnare i propri confini.

• Non protegge un server in esecuzione. La chiave master resta nella memoria del kernel dallo sblocco fino allo spegnimento. L'accesso alla memoria a livello di hypervisor la vanifica. La cifratura della memoria — AMD SEV-SNP ed equivalenti — è l'unica tecnologia che cambia davvero le cose, e oggi non la offriamo; un provider che sostiene che la tua VM in esecuzione le sia opaca, senza SEV, si sbaglia oppure mente.
• Non ti rende anonimo. Un disco cifrato a Zürich ha comunque un IP, una traccia di fatturazione e una sessione SSH partita da qualche parte. È un problema diverso, e abbiamo raccontato i modi in cui va storto in gli errori che ti deanonimizzano.
• Non cambia ciò che un tribunale può ordinare. La giurisdizione regola la coercizione; la cifratura regola la leggibilità. In alcune giurisdizioni puoi essere obbligato a rivelare personalmente una passphrase. La nostra guida alle procedure legali spiega cosa facciamo e cosa non facciamo.
• Non sopravvive a una passphrase persa. Per progettazione, e vale la pena ripeterlo, perché il ticket di supporto che ci chiede aiuto in merito arriva circa una volta al mese, e la risposta è sempre la stessa.
• Non autentica la catena di avvio. Riservatezza non è integrità. /boot è leggibile e modificabile offline.

Ciò che fa davvero è eliminare un'intera classe di esposizione — tutto ciò che accade a un disco quando non è in funzione, che è la maggior parte di ciò che accade ai dischi. Vale un'ora del tuo tempo. Combinala con una registrazione no-KYC, un pagamento in Monero e una giurisdizione scelta di proposito, e ogni livello copre un cedimento diverso. Nessuno di essi li copre tutti.