Sécurité — AES-256-GCM, zero-knowledge, modèle de menace
Comment Filarr protège vos données : fichiers chiffrés sur votre disque, architecture KEK/FEK, sync cloud optionnelle avec chiffrement de bout en bout.
Architecture KEK / FEK
Filarr utilise un système à deux niveaux de clés. Chaque fichier est chiffré avec sa propre File Encryption Key (FEK) en AES-256-GCM. La FEK est elle-même protégée par une Key Encryption Key (KEK) dérivée en PBKDF2-SHA-512, 600 000 itérations — exactement la même dérivation pour votre mot de passe et pour votre phrase de récupération. Si une FEK est compromise, seul ce fichier est exposé — pas le reste de vos données.
Quelle dérivation, pour quelle clé
Un produit qui se vend sur le chiffrement doit pouvoir dire lequel, où, et avec quels paramètres. Voici la table complète, relue dans le code des trois surfaces — bureau, web et mobile.
| Chemin | Dérivation | Paramètres | Surfaces |
|---|---|---|---|
| Mot de passe du compte → KEK | PBKDF2-SHA-512 | 600 000 itérations, sel de 16 octets, AES-GCM-256 | Bureau, web, mobile |
| Phrase de récupération → KEK | PBKDF2-SHA-512 | 600 000 itérations — exactement la même fonction que ci-dessus | Bureau, web, mobile |
| Clé du coffre local, au repos | Aucune — clé aléatoire de 256 bits | Scellée par le trousseau du système (DPAPI, Keychain, Keystore) | Bureau, mobile |
| Contenu d’un fichier | Aucune — chiffré sous sa FEK | AES-256-GCM, IV de 96 bits, tag de 128 bits | Toutes |
| Fichier synchronisé par blocs (delta) | HKDF-SHA-256 | Dérivée de la FEK, sel de 16 octets, contexte « filarr-delta-v4 », sortie 32 octets | Bureau, web |
| Clé de garde (mise sous séquestre) | Argon2id | m = 19 Mio, t = 2, p = 1, sortie de 32 octets | Bureau, web, mobile |
| Filarr Send protégé par mot de passe | Argon2id | m ≤ 64 Mio, t ≤ 10, p = 1 — borné par le serveur | Bureau, web, mobile |
| Déverrouillage par passkey (WebAuthn PRF) | HKDF-SHA-256 | Domaine séparé, versioné | Bureau, web |
| Appairage d’un appareil | HKDF-SHA-256 sur ECDH P-256 | Clés publiques non compressées de 65 octets, secret de 32 octets | Bureau, web, mobile |
Deux points qui se perdent souvent. La FEK qui chiffre vos fichiers est tirée au hasard, jamais dérivée d’un mot de passe : le mot de passe ne protège que son enveloppe. Et le déverrouillage par passkey n’existe que sur le bureau et le web — sur mobile, le second facteur est un code TOTP. La clé des fichiers synchronisés par blocs est dérivée de la FEK, jamais du mot de passe non plus. Son contexte reste « filarr-delta-v4 » même dans la dernière version du manifeste : le contexte de dérivation n’est volontairement pas versionné avec la disposition des données, sinon changer l’un rendrait l’autre illisible.
Votre mot de passe reste chez vous
Tout le chiffrement et le déchiffrement se font sur votre machine, et votre mot de passe ne quitte jamais votre appareil. Deux protections distinctes cohabitent, et il est utile de savoir laquelle fait quoi. Ce qui quitte la machine — la copie de votre clé qui rend le multi-appareil possible — est protégé par une clé dérivée de votre mot de passe en PBKDF2-SHA-512, 600 000 itérations : sans ce mot de passe, cette copie est inexploitable, y compris pour nous. Ce qui reste sur le disque est chiffré en AES-256-GCM avec une clé tirée au hasard et scellée par le coffre-fort du système d’exploitation — DPAPI sur Windows, le trousseau sur macOS, Keystore sur Android, Keychain sur iOS. Ce modèle protège un disque volé ou une image de sauvegarde ; il ne protège pas contre quelqu’un qui a déjà la main sur votre session ouverte. Réserve honnête : sur une machine Linux dépourvue de trousseau fonctionnel, Filarr se replie sur un fichier à permissions restreintes, et la protection contre le vol de disque ne s’applique alors plus. Quand la sync cloud est activée, nos serveurs (Cloudflare R2) ne reçoivent que des blobs chiffrés.
Double authentification (TOTP)
Optionnelle depuis Paramètres > Sécurité dans l'application. Compatible avec toute app TOTP standard (Authy, Google Authenticator, 1Password, Bitwarden). Au login : mot de passe, puis code à 6 chiffres. 8 codes de secours à usage unique sont générés à l'activation pour ne pas vous bloquer en cas de perte de votre appareil TOTP.
Le secret TOTP est stocké côté serveur (c'est nécessaire pour vérifier les codes) mais ne donne aucun accès à vos fichiers — il protège uniquement la connexion à votre compte. Votre mot de passe reste la seule clé qui déverrouille le chiffrement de vos données.
- TOTP RFC 6238 (SHA-1, 6 chiffres, période 30 s)
- Toutes les apps TOTP : Authy, Google Authenticator, 1Password, Bitwarden
- 8 codes de secours à usage unique, hashés côté serveur
- Rate-limité à 10 tentatives / 15 min / IP
Modèle de menace
Puisque vos données en clair ne quittent jamais votre machine — et que la copie de votre clé stockée chez nous est inutilisable sans votre mot de passe — le modèle de menace de Filarr est fondamentalement différent de celui d’un service cloud classique. Les principales menaces sont l’accès physique à votre appareil, la perte de votre mot de passe, et un mot de passe trop faible qui serait vulnérable au brute-force si nos serveurs étaient compromis (raison pour laquelle nous recommandons fortement un gestionnaire de mots de passe).
- Accès physique à l’appareilProtégé par le chiffrement AES-256-GCM
- Perte du mot de passeRécupérable via phrase de récupération uniquement
- Malware sur l’appareilClés en mémoire uniquement pendant l’utilisation
- Vol de disque durChiffré AES-256-GCM, clé scellée par le trousseau du système
- Attaque par force brutePBKDF2-SHA-512, 600 000 itérations
- Prise de contrôle de compte en ligneProtégé par 2FA TOTP optionnel
Ce que ça change concrètement
Le chiffrement n’a de valeur que s’il vous protège dans les situations qui arrivent vraiment.
Votre ordinateur est volé
Vos fichiers sont chiffrés avec AES-256-GCM. Sans votre mot de passe vault, ils sont illisibles — même avec un accès total au disque. Le voleur récupère un disque chiffré, pas vos documents.
Une fuite de données chez l’hébergeur
Filarr ne stocke que des blobs chiffrés sur nos serveurs. Vos fichiers sont chiffrés sur votre appareil avant l’upload. Même si notre stockage est compromis, les attaquants récupèrent du texte chiffré illisible.
Une demande légale pour vos données
Si Filarr reçoit une demande légale, nous ne pouvons transmettre que des blobs chiffrés — fichiers et copie chiffrée de votre clé. Sans votre mot de passe, rien n’est déchiffrable ; et nous ne voyons jamais votre mot de passe. Ce n’est pas une politique — c’est un fait technique.
Vous oubliez votre mot de passe
C’est le coût du chiffrement de bout en bout. Votre clé est protégée par un dérivé de votre mot de passe (PBKDF2-SHA-512, 600 000 itérations), et votre mot de passe ne nous est jamais transmis — si vous le perdez, nous ne pouvons pas récupérer vos données. Nous recommandons un gestionnaire de mots de passe et d’exporter une clé de secours depuis Paramètres > Sécurité.
Et si Filarr voulait lire vos données ?
Nous ne pouvons pas. Vos fichiers sont chiffrés avec une clé aléatoire, elle-même protégée par une clé dérivée de votre mot de passe via PBKDF2-SHA-512 avec 600 000 itérations. Nous stockons cette clé sous forme chiffrée pour permettre le multi-appareil, mais nous ne voyons jamais votre mot de passe — donc nous ne pouvons jamais la déverrouiller. Nos serveurs ne voient que des octets aléatoires.
Votre connexion tombe en plein travail
Filarr est local-first. Tout fonctionne hors ligne — notes, fichiers, graph, canvas. Les modifications se synchronisent automatiquement à la reconnexion. Aucune connexion requise pour accéder à vos fichiers.
Isolation multi-profil
Chaque profil dans Filarr a son propre ensemble de clés de chiffrement. Les données d’un profil « Perso » sont complètement isolées de celles d’un profil « Client A ». Même si un profil est compromis, les autres restent protégés.
Ce que nos serveurs savent quand même
Le chiffrement de bout en bout protège le CONTENU, pas le fait que vous vous en serviez. Nos serveurs voient donc certaines traces d’usage — jamais ce qui est écrit, jamais un nom de fichier, jamais un titre. Les voici, en entier, plutôt que dans une note de bas de page.
Les mentions
Que vous avez nommé quelqu’un, dans quel élément de quel coffre, et quand.
Jamais le texte de la note, ni son titre : votre appareil les résout avec vos clés.
L’édition à plusieurs
Quels appareils sont connectés à quelle note, et à quel moment.
Jamais ce qui s’y écrit : le relais rediffuse des octets chiffrés qu’il ne peut pas ouvrir. Cette fonction est éteinte par défaut.
Les notifications sur téléphone
Elles passent par les serveurs de Google, et portent le nom de la personne qui vous a nommé.
Jamais un titre ni un extrait — ce que nous n’avons pas ne peut pas devenir lisible ailleurs.
La synchronisation
Le nombre de fichiers, leur taille, la date de leur dernière modification.
Jamais leur nom, jamais leur contenu, jamais l’arborescence de vos dossiers.
Ce sur quoi nous travaillons encore
La synchronisation cloud est disponible avec chiffrement de bout en bout — vos fichiers sont chiffrés sur votre appareil avant l’upload. Le client desktop est désormais publié sur GitHub sous Business Source License 1.1 : vous pouvez lire le code et vérifier les claims cryptographiques directement, plutôt que de nous faire confiance sur parole. Un audit de sécurité indépendant est prévu. Il n’y a pas encore de certification SOC2 ou HIPAA.
Même garantie pour le partage de fichiers
Filarr Send applique le même chiffrement AES-256-GCM. La clé reste dans l’URL, jamais sur nos serveurs.