KEK et FEK expliqués : pourquoi le chiffrement par fichier compte

Réponse rapide. KEK (Key Encryption Key) et FEK (File Encryption Key) forment une hiérarchie de clés à deux niveaux utilisée par les apps chiffrées sérieuses. Chaque fichier reçoit sa propre FEK aléatoire ; la FEK est ensuite chiffrée (« encapsulée ») par une seule KEK dérivée de votre mot de passe. Ce pattern, appelé envelope encryption, limite le rayon d'impact de toute compromission à un seul fichier. Utilisé par Signal, BitLocker, AWS KMS, File Protection d'Apple, et Filarr.

Quand une app de notes chiffrée annonce « vos données sont chiffrées en AES-256 », il y a un choix architectural caché qui compte plus que le chiffre : combien y a-t-il de clés, et comment sont-elles organisées ?

Le design naïf utilise une clé pour tout — votre mot de passe, étiré en clé maître, chiffre chaque fichier. Le bon design utilise deux niveaux : une clé unique par fichier, encapsulée par une clé maître. Ça s'appelle l'envelope encryption (chiffrement par enveloppe), et les deux niveaux ont des noms précis : KEK (Key Encryption Key) et FEK (File Encryption Key).

Cet article explique pourquoi le design à deux niveaux existe, comment il fonctionne étape par étape, contre quelles attaques il défend, et comment reconnaître une app chiffrée bien conçue.

Que sont KEK et FEK ?

Les termes viennent des systèmes de gestion de clés et de la littérature des KMS cloud. Les définitions :

FEK (File Encryption Key) : une clé symétrique aléatoire (typiquement 256 bits) qui chiffre un seul fichier. Chaque fichier dans le système a sa propre FEK unique.
KEK (Key Encryption Key) : une clé maître, typiquement dérivée du mot de passe de l'utilisateur, qui chiffre les FEK. La KEK elle-même ne chiffre jamais directement le contenu des fichiers.

L'arrangement est hiérarchique : une seule KEK, plusieurs FEK.

                Mot de passe utilisateur
                         │
                         ▼
                  KDF (PBKDF2 / Argon2id)
                         │
                         ▼
                  ╔══════════╗
                  ║   KEK    ║   ← vit en mémoire uniquement
                  ╚══════════╝
                         │
                         │ chiffre chaque FEK
            ┌────────────┼────────────┐
            ▼            ▼            ▼
        ┌──────┐    ┌──────┐    ┌──────┐
        │ FEK1 │    │ FEK2 │    │ FEK3 │
        └──────┘    └──────┘    └──────┘
            │            │            │
            ▼            ▼            ▼
        ┌──────┐    ┌──────┐    ┌──────┐
        │fich.1│    │fich.2│    │fich.3│
        │chiffré│   │chiffré│   │chiffré│
        └──────┘    └──────┘    └──────┘

Quand vous sauvegardez un fichier :

Générer une FEK aléatoire fraîche
Chiffrer le fichier avec sa FEK en AES-256-GCM
Chiffrer la FEK avec la KEK en AES-256-GCM
Stocker le fichier chiffré à côté de la FEK chiffrée sur le disque (ou uploader vers le cloud)

Quand vous lisez un fichier :

Utiliser votre mot de passe pour redériver la KEK
Déchiffrer la FEK avec la KEK
Déchiffrer le fichier avec la FEK

La KEK vit uniquement en mémoire processus et est effacée quand vous verrouillez l'app ou la fermez. Les FEK vivent chiffrées sur disque. Le mot de passe original n'est jamais stocké nulle part.

Pourquoi ne pas utiliser une seule clé globale pour tout ?

Le design à clé unique semble plus simple. Vous étirez votre mot de passe en clé maître, chiffrez chaque fichier avec cette clé maître, c'est fini. Pourquoi ajouter un niveau ?

Trois problèmes concrets avec le design à clé unique.

1. Rayon d'impact. Si un texte chiffré fuite la clé (via un bug, un canal auxiliaire, ou une réutilisation de nonce), tous les fichiers chiffrés avec cette clé sont exposés. Avec des FEK par fichier, fuiter la clé d'un fichier n'expose que ce fichier-là.

2. La rotation de clé est impossible. Avec une clé globale unique, faire tourner la clé (pour cause de compromission suspectée) signifie rechiffrer tous les fichiers. C'est lent et risqué. Avec KEK/FEK, vous pouvez faire tourner la KEK et ré-encapsuler les FEK sans jamais déchiffrer ni rechiffrer le contenu des fichiers.

3. Le partage sélectif est impossible. Si vous voulez partager un fichier avec un autre utilisateur, il faudrait partager la clé maître globale — ce qui leur donne accès à tous vos fichiers, pour toujours. Avec des FEK par fichier, vous partagez une seule FEK chiffrée avec la clé publique du destinataire. Ils obtiennent exactement un fichier.

Ces problèmes ne sont pas théoriques. L'histoire des désastres cryptographiques est en grande partie une histoire de designs « une clé pour tout » qui échouent mal.

Que signifie « envelope encryption » ?

« Envelope encryption » est le nom du pattern KEK/FEK dans l'industrie de la sécurité cloud. La métaphore : chaque fichier est scellé dans une enveloppe avec sa propre clé de données (FEK), et cette enveloppe est ensuite placée dans une autre enveloppe scellée par une clé de chiffrement de clé (KEK).

AWS KMS, Google Cloud KMS, Azure Key Vault, et HashiCorp Vault implémentent tous l'envelope encryption. La KEK gérée côté cloud ne quitte jamais un module de sécurité matériel ; seules les FEK (chiffrées sous cette KEK) sont renvoyées à l'application.

Filarr utilise le même pattern localement : le mot de passe utilisateur dérive la KEK, la KEK vit uniquement en mémoire, et les FEK sont stockées chiffrées à côté des fichiers.

Comment KEK et FEK sont-elles réellement générées ?

Les deux moitiés utilisent des méthodes de génération différentes parce qu'elles ont des besoins différents.

Génération de FEK : aléatoire cryptographiquement sûr. Une FEK est une valeur aléatoire de 256 bits tirée du générateur de nombres aléatoires sécurisé du système (crypto.randomBytes dans Node, getRandomValues dans les navigateurs, /dev/urandom sur Linux, BCryptGenRandom sur Windows). Chaque nouveau fichier reçoit une FEK fraîche. La FEK n'est jamais dérivée de quoi que ce soit ; c'est de l'aléatoire pur.

Génération de KEK : fonction de dérivation de clé. La KEK est dérivée du mot de passe de l'utilisateur via une fonction lente conçue pour résister au brute-force. Deux fonctions sont couramment utilisées :

PBKDF2-SHA-512 avec 600 000+ itérations, salée par utilisateur. Le minimum acceptable en 2026 (recommandation OWASP).
Argon2id avec au moins 64 Mo de coût mémoire, 3 itérations, 4 voies de parallélisme. La meilleure pratique actuelle (RFC 9106).

Argon2id est préféré pour les nouveaux designs parce qu'il est memory-hard, ce qui rend le brute-force GPU et ASIC dramatiquement plus coûteux que PBKDF2. Beaucoup d'apps chiffrées utilisent encore PBKDF2 pour la compatibilité avec les bibliothèques existantes, parfois aux côtés d'Argon2id pour la défense en profondeur.

Contre quelles attaques le design KEK/FEK défend-il ?

Une bonne façon d'évaluer une architecture cryptographique est de dérouler des scénarios d'attaque spécifiques.

Attaque 1 : la clé d'un fichier est exposée. Un bug dans l'application logue brièvement une FEK sur disque. Un attaquant avec accès au disque lit le log. Ce qu'il obtient : le contenu d'un fichier. Ce qu'il n'obtient pas : la clé maître, aucun autre fichier. Le design à clé unique échoue catastrophiquement à ce test.

Attaque 2 : un utilisateur partage un fichier. Avec des FEK par fichier, partager signifie chiffrer une FEK vers la clé publique du destinataire. Le destinataire obtient l'accès à un fichier, rien de plus. Avec une clé globale unique, vous ne pouvez rien partager sans tout partager.

Attaque 3 : l'utilisateur change son mot de passe. Avec KEK/FEK, vous redérivez une nouvelle KEK depuis le nouveau mot de passe et ré-encapsulez chaque FEK avec la nouvelle KEK. Aucun contenu de fichier n'est touché. L'opération est rapide (millisecondes) et atomique. Avec une clé unique, vous devez rechiffrer chaque fichier de zéro — un processus destructeur, lent et sujet aux erreurs.

Attaque 4 : le serveur cloud est compromis. L'attaquant lit tous les blobs chiffrés sur disque. Ce qu'il obtient : texte chiffré + FEK chiffrées. Ce qu'il n'obtient pas : la KEK (elle est uniquement en mémoire de votre appareil) — donc il ne peut pas déchiffrer les FEK, donc il ne peut rien déchiffrer.

Attaque 5 : récupération forensique d'un fichier supprimé. Avec des FEK par fichier, vous pouvez « broyer » un fichier en supprimant juste sa FEK. Le contenu du fichier chiffré devient définitivement illisible, même si les octets restent sur le disque. Avec une clé unique, supprimer juste les métadonnées d'un fichier le laisse déchiffrable — la suppression sécurisée requiert d'écraser les octets.

Dans chaque scénario, le design à deux niveaux se comporte mieux que le design à clé unique.

Existe-t-il d'autres noms pour ce pattern ?

Oui. Le même pattern architectural apparaît dans beaucoup d'endroits sous différents noms :

Envelope encryption — AWS, Google Cloud, Azure
Key wrapping — terminologie NIST
DEK + KEK — « Data Encryption Key » au lieu de « File Encryption Key »
Master key + file keys — File Protection d'Apple sur iOS / macOS
Vault key + record keys — 1Password
VMK + FVEK — Microsoft BitLocker (Volume Master Key + Full Volume Encryption Key)

Tous le même pattern : une clé maître qui chiffre des clés de données, où les clés de données touchent réellement les données. Le nommage diffère mais la structure est constante.

Comment savoir si une app de notes utilise du chiffrement par fichier ?

Quand vous évaluez une app de notes chiffrée ou de stockage, cherchez ces signaux :

Documentation d'architecture qui mentionne key wrapping, envelope encryption, ou clés par fichier. Une app sérieuse explique sa structure de chiffrement publiquement. Si la doc dit juste « AES-256 », c'est une affirmation marketing, pas une architecture.
Rapports d'audit indépendants. Les auditeurs notent explicitement si des clés par fichier sont utilisées. La présence de « KEK et FEK » dans un rapport d'audit est un signal positif fort.
Capacité de partage sélectif. Si l'app supporte le partage de fichiers individuels sans donner au destinataire l'accès à tout votre coffre, elle utilise presque certainement des clés par fichier. Les designs à clé unique ne peuvent pas faire de partage sélectif.
Changement de mot de passe rapide. Si changer votre mot de passe maître prend quelques secondes et ne requiert pas de rechiffrer toute votre bibliothèque, le design utilise du key wrapping (la KEK est mise à jour ; les FEK et fichiers ne sont pas touchés).
Open source. Avec du code source public, vous pouvez vérifier l'architecture directement. Cherchez des termes comme wrapKey, wrappedFek, unwrapKey, kekId, keyEncryptionKey.

Comment Filarr implémente KEK/FEK ?

L'architecture de Filarr est de l'envelope encryption manuel avec les paramètres de meilleure pratique actuels.

Dérivation de KEK. Votre mot de passe est passé dans Argon2id (coût mémoire 64 Mio, 3 itérations, parallélisme 4) et PBKDF2-SHA-512 (600 000 itérations) pour produire une KEK de 256 bits. La KEK vit uniquement en mémoire processus ; elle n'est jamais écrite sur disque en clair.
Génération de FEK. Chaque fichier dans votre workspace reçoit une FEK aléatoire de 256 bits du RNG sécurisé de l'OS. Les FEK ne sont jamais dérivées d'autre chose et ne sont jamais réutilisées entre fichiers.
Chiffrement de fichier. Le fichier est chiffré avec sa FEK en AES-256-GCM avec un nonce aléatoire frais par chiffrement. Voir qu'est-ce que l'AES-256-GCM pour comprendre pourquoi ce mode compte.
Encapsulation de FEK. La FEK est chiffrée avec la KEK en AES-256-GCM et stockée à côté du fichier chiffré (localement) ou uploadée avec le blob chiffré (sync cloud).
Isolation multi-profil. Chaque profil Filarr a sa propre KEK dérivée d'un mot de passe différent. La KEK du Profil A ne peut pas déchiffrer les FEK du Profil B — même si les deux appartiennent au même utilisateur.
Upload cloud. Quand la sync cloud est activée, Filarr uploade le blob de fichier chiffré et la FEK chiffrée. Le serveur voit les deux ; sans votre KEK (qui ne quitte jamais votre appareil), il ne peut déchiffrer ni l'un ni l'autre.

Le résultat : une seule compromission de clé (une FEK enregistrée, une fuite par canal auxiliaire) expose un fichier. La KEK ne quitte jamais votre machine en clair. Les changements de mot de passe sont instantanés parce qu'ils ne ré-encapsulent que les FEK, pas le contenu des fichiers.

Lire l'architecture de sécurité complète de Filarr pour les paramètres exacts, le modèle de menace et les rapports d'audit.

Pour aller plus loin

NIST SP 800-38F — Méthodes pour le Key Wrapping — le standard de l'envelope encryption
RFC 9106 — Hash de mot de passe Argon2 — le KDF moderne
OWASP Password Storage Cheat Sheet — recommandations actuelles
Qu'est-ce que l'AES-256-GCM et pourquoi ça compte
Le chiffrement zero-knowledge expliqué
End-to-end vs zero-knowledge
Qu'est-ce que le local-first ?
L'architecture de sécurité de Filarr