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. La FEK, une clé aléatoire, chiffre les données ; la KEK, dérivée de votre mot de passe, chiffre (« encapsule ») la FEK. Ce pattern, appelé envelope encryption, est utilisé par Signal, BitLocker, AWS KMS et File Protection d'Apple, et dans sa version de manuel chaque fichier reçoit sa propre FEK. Filarr utilise les deux niveaux autrement : une seule FEK aléatoire par compte, sous laquelle vos fichiers et vos notes sont chiffrés, chacun avec une valeur aléatoire nouvelle. Changer de mot de passe ne ré-encapsule que cette FEK, et une copie volée des données du serveur n'ouvre rien.

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 meilleur design utilise deux niveaux : une clé de données aléatoire qui chiffre le contenu, encapsulée par une clé dérivée de votre mot de passe. Ç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). Dans la version de manuel, chaque fichier a même sa propre FEK.

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 le contenu des fichiers. Dans la version de manuel, chaque fichier dans le système a sa propre FEK unique ; certains designs, dont celui de Filarr, utilisent une seule FEK pour tout un compte.
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.

Dans la version de manuel, 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 sur votre appareil : votre mot de passe dérive la KEK, la KEK vit uniquement en mémoire, et elle encapsule une seule FEK, la clé de votre compte, sous laquelle vos fichiers et vos notes sont chiffrés (détails plus bas).

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). Dans la version de manuel, chaque nouveau fichier reçoit une FEK fraîche ; chez Filarr, c'est chaque compte. Dans les deux cas, 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, salée par utilisateur, avec au moins les 210 000 itérations que l'OWASP recommande pour SHA-512 (600 000 est son chiffre pour SHA-256).
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 ?

Filarr utilise les deux niveaux, avec une différence par rapport à la version de manuel : la FEK est la clé de votre compte, pas celle d'un seul fichier.

Dérivation de KEK. Votre mot de passe est passé dans PBKDF2-SHA-512 (600 000 itérations, bien au-delà des 210 000 que l'OWASP recommande pour PBKDF2-SHA512) 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 compte, ou chaque profil local, reçoit une seule FEK aléatoire de 256 bits, tirée du RNG sécurisé de l'OS. La FEK n'est jamais dérivée de votre mot de passe.
Chiffrement de fichier. Vos fichiers et vos notes sont chiffrés en AES-256-GCM sous la FEK, avec une valeur aléatoire nouvelle (le nonce, ou IV) pour chacun et à chaque chiffrement. Deux formats vont plus loin et dérivent de la FEK une clé qui leur est propre, par HKDF avec un sel aléatoire : les gros fichiers importés sur le bureau, et les blocs synchronisés. 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 une seconde fois par votre phrase de récupération (24 mots pour un compte cloud). Pour un compte cloud, le serveur garde ces deux copies encapsulées, pour qu'un nouvel appareil puisse ouvrir vos données.
Isolation multi-profil. Chaque profil local Filarr a sa propre FEK et sa propre KEK, dérivée d'un mot de passe différent. La KEK du Profil A ne peut pas déchiffrer la 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 les blobs de fichiers chiffrés, et le serveur garde la FEK encapsulée. Une copie volée des données du serveur n'ouvre rien sans votre mot de passe ou votre phrase de récupération. La connexion ne donne pas non plus de quoi refaire la KEK : depuis le 16 octobre 2026, une app à jour envoie une clé dérivée de votre mot de passe avec un autre sel, pas le mot de passe lui-même. Pendant une transition d'environ deux mois, un compte qui ne s'est pas encore reconnecté, ou une ancienne version de l'app, envoie encore le mot de passe (sous HTTPS), et un serveur compromis pourrait l'y capter.

Face aux attaques décrites plus haut, cette architecture vous apporte deux choses. Un changement de mot de passe ne ré-encapsule que la FEK : il est instantané et ne touche aucun fichier (attaque 3). Une copie volée des données du serveur ne contient que du texte chiffré et des clés encapsulées, rien de lisible (attaque 4). Ce qu'elle ne vous apporte pas, c'est un rayon d'impact limité à un fichier : la FEK ouvre tout le compte, c'est pourquoi elle ne quitte jamais votre appareil en clair et n'est stockée qu'encapsulée (attaque 1). Le partage ne repose pas non plus sur des FEK par fichier : un lien de partage porte sa propre clé après le #, et un coffre partagé a sa propre clé, scellée pour chaque membre (attaque 2).

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

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