KEK e FEK spiegate: perché conta la crittografia per file

Risposta rapida. KEK (Key Encryption Key) e FEK (File Encryption Key) formano una gerarchia di chiavi a due livelli usata dalle app crittografate serie. La FEK, una chiave casuale, crittografa i dati; la KEK, derivata dalla tua password, crittografa («incapsula», in inglese wrap) la FEK. Questo schema, chiamato envelope encryption, è usato da Signal, BitLocker, AWS KMS e dalla File Protection di Apple e, nella sua forma da manuale, ogni file ha la propria FEK. Filarr usa i due livelli in modo diverso: una sola FEK casuale per account, con cui sono crittografati i tuoi file e le tue note, ciascuno con un valore casuale nuovo. Cambiare password significa solo incapsulare di nuovo quella FEK, e una copia rubata dei dati del server non apre nulla.

Quando un’app di note crittografate dice «i tuoi dati sono crittografati con AES-256», c’è una scelta architetturale nascosta che conta più del cifrario: quante chiavi ci sono, e come sono organizzate?

Il design ingenuo usa una sola chiave per tutto: la tua password, «stirata» in una chiave principale, crittografa ogni file. Il design migliore usa due livelli: una chiave dei dati casuale che crittografa il contenuto, incapsulata da una chiave derivata dalla tua password. Si chiama envelope encryption (crittografia a busta), e i due livelli hanno nomi precisi: KEK (Key Encryption Key) e FEK (File Encryption Key). Nello schema da manuale, ogni file ha persino la propria FEK.

Questo articolo spiega perché esiste il design a due livelli, come funziona passo dopo passo, da quali attacchi difende e come riconoscere un’app crittografata progettata correttamente.

Cosa sono la KEK e la FEK?

I termini vengono dai sistemi di gestione delle chiavi e dalla letteratura sui KMS cloud. Le definizioni:

FEK (File Encryption Key): una chiave simmetrica casuale (in genere da 256 bit) che crittografa il contenuto dei file. Nello schema da manuale, ogni file del sistema ha la propria FEK unica; alcuni design, tra cui quello di Filarr, usano una sola FEK per un intero account.
KEK (Key Encryption Key): una chiave principale, in genere derivata dalla password dell’utente, che crittografa le FEK. La KEK non crittografa mai direttamente il contenuto dei file.

Nello schema da manuale l’organizzazione è gerarchica: una KEK, molte FEK.

                Password dell’utente
                         │
                         ▼
                  KDF (PBKDF2 / Argon2id)
                         │
                         ▼
                  ╔══════════╗
                  ║   KEK    ║   ← vive solo in memoria
                  ╚══════════╝
                         │
                         │ crittografa ogni FEK
            ┌────────────┼────────────┐
            ▼            ▼            ▼
        ┌──────┐    ┌──────┐    ┌──────┐
        │ FEK1 │    │ FEK2 │    │ FEK3 │
        └──────┘    └──────┘    └──────┘
            │            │            │
            ▼            ▼            ▼
        ┌───────┐   ┌───────┐   ┌───────┐
        │file 1 │   │file 2 │   │file 3 │
        │cifrato│   │cifrato│   │cifrato│
        └───────┘   └───────┘   └───────┘

Quando salvi un file:

Si genera una nuova FEK casuale
Si crittografa il file con la sua FEK in AES-256-GCM
Si crittografa la FEK con la KEK in AES-256-GCM
Si conserva il file crittografato accanto alla FEK crittografata sul disco (o li si carica nel cloud)

Quando leggi un file:

Si usa la tua password per derivare di nuovo la KEK
Si decrittografa la FEK con la KEK
Si decrittografa il file con la FEK

La KEK vive solo nella memoria del processo e viene cancellata quando blocchi o chiudi l’app. Le FEK vivono crittografate sul disco. La password originale non viene mai conservata da nessuna parte.

Perché non usare un’unica chiave globale per tutto?

Il design a chiave unica sembra più semplice. Stiri la password in una chiave principale, crittografi ogni file con quella chiave principale, fatto. Perché aggiungere un livello?

Il design a chiave unica pone tre problemi concreti.

1. Il raggio d’impatto. Se un testo cifrato fa trapelare la chiave (per un bug, un side-channel o un riuso del nonce), ogni file crittografato con quella chiave è esposto. Con una FEK per file, come nello schema da manuale, la fuga della chiave di un file espone solo quel file.

2. La rotazione delle chiavi è impossibile. Con un’unica chiave globale, ruotare la chiave (perché si sospetta una compromissione) significa ricrittografare ogni file. È lento e rischioso. Con KEK/FEK puoi ruotare la KEK e incapsulare di nuovo le FEK senza mai decrittografare e ricrittografare il contenuto dei file.

3. La condivisione selettiva è impossibile. Se vuoi condividere un file con un altro utente, dovresti condividere la chiave principale globale, il che gli dà accesso a tutti i tuoi file, per sempre. Con una FEK per file, condividi una sola FEK crittografata con la chiave pubblica del destinatario. Ottiene esattamente un file.

Questi problemi non sono teorici. La storia dei disastri crittografici è in gran parte una storia di design «una chiave per tutto» falliti malamente.

Cosa significa envelope encryption?

«Envelope encryption» è il nome dello schema KEK/FEK nel settore della sicurezza cloud. La metafora: ogni file è sigillato in una busta con una sua chiave dei dati (FEK), e quella busta viene poi messa in un’altra busta sigillata con una chiave di crittografia delle chiavi (KEK).

AWS KMS, Google Cloud KMS, Azure Key Vault e HashiCorp Vault implementano tutti l’envelope encryption. La KEK gestita nel cloud non lascia mai un modulo di sicurezza hardware; all’applicazione vengono restituite solo le FEK (crittografate con quella KEK).

Filarr usa lo stesso schema sul tuo dispositivo: la tua password deriva la KEK, la KEK vive solo in memoria e incapsula una sola FEK, la chiave del tuo account, con cui sono crittografati i tuoi file e le tue note (dettagli più sotto).

Come vengono generate davvero la KEK e la FEK?

Le due metà usano metodi di generazione diversi perché hanno requisiti diversi.

Generazione della FEK: casualità crittograficamente sicura. Una FEK è un valore casuale da 256 bit estratto dal generatore di numeri casuali sicuro del sistema operativo (crypto.randomBytes in Node, getRandomValues nei browser, /dev/urandom su Linux, BCryptGenRandom su Windows). Nello schema da manuale, ogni nuovo file riceve una FEK nuova; in Filarr la riceve ogni account. In entrambi i casi la FEK non è mai derivata da nulla: è pura casualità.

Generazione della KEK: funzione di derivazione della chiave. La KEK è derivata dalla password dell’utente tramite una funzione lenta, progettata per resistere agli attacchi a forza bruta. Due funzioni sono usate comunemente:

PBKDF2-SHA-512, con un sale per utente, con almeno le 210.000 iterazioni che l’OWASP raccomanda per SHA-512 (600.000 è la sua cifra per SHA-256).
Argon2id con almeno 64 MB di costo in memoria, 3 iterazioni e 4 corsie di parallelismo. È la buona pratica attuale (RFC 9106).

Argon2id è preferito per i nuovi design perché è memory-hard, il che rende la forza bruta su GPU e ASIC molto più costosa che con PBKDF2. Molte app crittografate usano ancora PBKDF2 per compatibilità con le librerie esistenti, a volte accanto ad Argon2id per una difesa in profondità.

Da quali attacchi difende il design KEK/FEK?

Un buon modo per valutare qualsiasi architettura crittografica è passare in rassegna scenari d’attacco precisi.

Attacco 1: la chiave di un file viene esposta. Un bug dell’applicazione scrive per un attimo una FEK in un log sul disco. Un attaccante con accesso al disco legge il log. Con una FEK per file, come nello schema da manuale: cosa ottiene: il contenuto di un file. Cosa non ottiene: la chiave principale, nessun altro file. Il design a chiave unica fallisce questo test in modo catastrofico.

Attacco 2: un utente condivide un file. Con una FEK per file, condividere significa crittografare una FEK con la chiave pubblica del destinatario. Il destinatario ottiene l’accesso a un file, nient’altro. Con un’unica chiave globale, non puoi condividere nulla senza condividere tutto.

Attacco 3: l’utente cambia la password. Con KEK/FEK, derivi una nuova KEK dalla nuova password e incapsuli di nuovo ogni FEK con la nuova KEK. Nessun contenuto dei file viene toccato. L’operazione è veloce (qualche millisecondo) e atomica. Con una chiave unica, devi ricrittografare ogni file da zero: un processo distruttivo, lento e soggetto a errori.

Attacco 4: il server cloud viene compromesso. L’attaccante legge tutti i blob crittografati sul disco. Cosa ottiene: testo cifrato + FEK crittografate. Cosa non ottiene: la KEK (sta solo nella memoria del tuo dispositivo), quindi non può decrittografare le FEK, e di conseguenza non può decrittografare nulla.

Attacco 5: recupero forense di un file eliminato. Con una FEK per file, come nello schema da manuale, puoi «distruggere» un file eliminando solo la sua FEK. Il contenuto crittografato del file diventa illeggibile per sempre, anche se i byte restano sul disco. Con una chiave unica, eliminare solo i metadati di un file lo lascia comunque decrittografabile: una cancellazione sicura richiede di sovrascrivere i byte.

In ogni scenario, il design a due livelli si comporta meglio del design a chiave unica.

Questo schema ha altri nomi?

Sì. Lo stesso schema architetturale compare in molti posti con nomi diversi:

Envelope encryption: AWS, Google Cloud, Azure
Key wrapping: terminologia del NIST
DEK + KEK: «Data Encryption Key» invece di «File Encryption Key»
Chiave principale + chiavi dei file: la File Protection di Apple in iOS / macOS
Vault key + record key: 1Password
VMK + FVEK: Microsoft BitLocker (Volume Master Key + Full Volume Encryption Key)

È sempre lo stesso schema: una chiave principale che crittografa chiavi dei dati, e sono le chiavi dei dati a toccare davvero i dati. I nomi cambiano, ma la struttura resta costante.

Come capire se un’app di note usa la crittografia per file?

Quando valuti un’app di note o di archiviazione di file crittografata, cerca questi segnali:

Una documentazione dell’architettura che parli di key wrapping, envelope encryption o chiavi per file. Un’app seria spiega pubblicamente com’è organizzata la sua crittografia. Se la documentazione dice solo «AES-256», è un’affermazione di marketing, non un’architettura.
Rapporti di audit indipendenti. I revisori indicheranno esplicitamente se vengono usate chiavi per file. La presenza di «KEK e FEK» in un rapporto di audit è un forte segnale positivo.
La possibilità di condividere in modo selettivo. Se l’app permette di condividere singoli file senza dare al destinatario l’accesso a tutta la tua cassaforte, usa quasi certamente chiavi distinte da quella principale per ciò che condivide (chiavi per file o chiavi per condivisione). Un design con un’unica chiave, senza chiavi dedicate alla condivisione, non può fare condivisione selettiva.
Un cambio password veloce. Se cambiare la password principale richiede pochi secondi e non obbliga a ricrittografare l’intera libreria, il design usa il key wrapping (la KEK viene aggiornata; FEK e file restano intatti).
Il codice sorgente pubblico. Con un codice sorgente pubblico puoi verificare direttamente l’architettura. Cerca termini come wrapKey, wrappedFek, unwrapKey, kekId, keyEncryptionKey.

Come implementa Filarr la KEK e la FEK?

Filarr usa entrambi i livelli, con una differenza rispetto allo schema da manuale: la FEK è la chiave del tuo account, non la chiave di un singolo file.

Derivazione della KEK. La tua password passa attraverso PBKDF2-SHA-512 (600.000 iterazioni, ben oltre le 210.000 raccomandate dall’OWASP per PBKDF2-SHA512) per produrre una KEK da 256 bit. La KEK vive solo nella memoria del processo; non viene mai scritta in chiaro sul disco.
Generazione della FEK. Ogni account, o ogni profilo locale, riceve una FEK casuale da 256 bit dal generatore casuale sicuro del sistema operativo. La FEK non è mai derivata dalla tua password.
Crittografia dei file. I tuoi file e le tue note sono crittografati in AES-256-GCM con la FEK, con un valore casuale nuovo (il nonce, o IV) per ogni file e per ogni crittografia. Due formati vanno un passo oltre e derivano dalla FEK una chiave propria, con HKDF e un sale casuale: i file di grandi dimensioni importati sul desktop e i blocchi sincronizzati. Leggi cos’è AES-256-GCM per capire perché questa modalità conta.
Incapsulamento della FEK. La FEK è crittografata con la KEK in AES-256-GCM, e una seconda volta con la tua frase di recupero (24 parole per un account cloud). Per un account cloud, il server conserva entrambe le copie incapsulate, così che un nuovo dispositivo possa aprire i tuoi dati.
Isolamento tra profili. Ogni profilo locale di Filarr ha la propria FEK e la propria KEK, derivata da una password diversa. La KEK del profilo A non può decrittografare la FEK del profilo B, anche se entrambi appartengono allo stesso utente.
Caricamento nel cloud. Quando la sincronizzazione cloud è attiva, Filarr carica i blob crittografati dei file, e il server conserva la FEK incapsulata. Una copia rubata dei dati del server non apre nulla senza la tua password o la tua frase di recupero. Nemmeno l’accesso all’account consegna ciò che serve per ricostruire la KEK: dal 16 ottobre 2026 un’app aggiornata invia una chiave derivata dalla tua password con un sale diverso, non la password stessa. Durante una transizione di circa due mesi, un account che non si è ancora ricollegato, o una vecchia versione dell’app, invia ancora la password (via HTTPS), dove un server compromesso potrebbe intercettarla.

Rispetto agli attacchi descritti sopra, questa organizzazione ti dà due cose. Un cambio di password incapsula di nuovo solo la FEK, quindi è istantaneo e non tocca nessun file (attacco 3). Una copia rubata dei dati del server restituisce testo cifrato e chiavi incapsulate, nulla di leggibile (attacco 4). Quello che non ti dà è un raggio d’impatto limitato a un file: la FEK apre l’intero account, ed è per questo che non lascia mai il tuo dispositivo in chiaro ed è sempre conservata solo incapsulata (attacco 1). Nemmeno la condivisione si basa su FEK per file: un link di condivisione porta con sé una chiave tutta sua dopo il #, e una cassaforte condivisa ha una sua chiave, sigillata per ogni membro (attacco 2).

Leggi l’architettura di sicurezza completa di Filarr per i parametri esatti e il modello di minaccia.

Per approfondire

NIST SP 800-38F — Methods for Key Wrapping: lo standard dell’envelope encryption
RFC 9106 — Argon2 password hashing: la KDF moderna
OWASP Password Storage Cheat Sheet: le raccomandazioni attuali
Cos’è AES-256-GCM e perché conta
La crittografia zero-knowledge spiegata
Crittografia end-to-end vs zero-knowledge
Cos’è il software local-first?
L’architettura di sicurezza di Filarr