« Zero‑knowledge » est devenu un mot trop tendre
À force d'être collé sur tout et n'importe quoi, le terme zero‑knowledge a perdu son tranchant. Beaucoup de produits annoncent « zero‑knowledge » alors qu'ils stockent encore une clé dérivable côté serveur, ou qu'ils chiffrent uniquement at rest avec une clé que l'éditeur peut récupérer.
Chez Servor, on a choisi le sens strict : nous ne devons pas pouvoir lire vos identifiants, même si nous le voulons. Pas par politique. Par mathématiques. Voici comment on s'y est pris, et pourquoi chaque brique a été choisie comme elle l'a été.
Les acteurs : KEK, DEK, et le navigateur
Trois clés se croisent dans le pipeline cryptographique de Servor :
- KEK (Key Encryption Key) : dérivée de votre phrase secrète via Argon2id. Elle ne sort jamais de votre navigateur.
- clé privée utilisateur : une paire X25519 générée à l'initialisation de votre compte. La clé privée est chiffrée par la KEK avant transmission.
- DEK (Data Encryption Key) : une clé AES‑256 par équipe, qui chiffre réellement les identifiants. La DEK est emballée pour chaque membre via X25519.
Avantage de cette indirection : ajouter un membre à une équipe ne demande pas de partager votre phrase secrète. On emballe la DEK avec la clé publique du nouveau membre, et c'est terminé.
Argon2id : pourquoi ces paramètres‑là
Argon2id est le standard de fait pour la dérivation de clé à partir d'un secret humain. Mais le diable est dans les paramètres. Ceux de Servor :
- mémoire = 64 Mo : assez pour rendre une attaque GPU massivement parallèle coûteuse, pas trop pour rester déverrouillable sur une machine modeste.
- itérations = 3 : le compromis entre coût pour l'attaquant et latence ressentie au déverrouillage.
- parallélisme = 4 : tire parti du multi‑threading sans fragmenter inutilement l'espace mémoire.
Ces valeurs se situent au‑dessus des recommandations publiques courantes pour un usage interactif. Elles sont un curseur, pas une garantie : si le coût du matériel continue de baisser, elles devront monter, et c'est le genre de paramètre qu'on relit périodiquement plutôt qu'on grave.
X25519 : l'emballage de la DEK
Une fois la KEK dérivée, on l'utilise pour déchiffrer la clé privée X25519 stockée chiffrée côté serveur. Cette clé privée sert ensuite à déballer la DEK de l'équipe.
Pourquoi X25519 et pas RSA ou P‑256 ? Trois raisons :
- vitesse : un emballage / déballage X25519 est d'un ordre de grandeur plus rapide qu'un RSA‑2048 équivalent, ce qui compte quand l'opération se fait dans un onglet ;
- simplicité : pas de format DER tortueux, pas de paramètres de courbe à valider, donc beaucoup moins de surface d'erreur d'implémentation ;
- résistance aux canaux auxiliaires : Curve25519 est construite pour qu'une implémentation correcte soit naturellement en temps constant.
L'enveloppe qu'on dérive est un HKDF(X25519(clé éphémère, clé publique du membre)) qui produit la clé AES servant à emballer la DEK. Une clé éphémère par opération : pas de réutilisation de nonce, jamais.
AES‑256‑GCM : le chiffrement applicatif
La DEK chiffre concrètement les identifiants avec AES‑256‑GCM. Chaque entrée a son IV 12 octets aléatoire et son tag d'authentification 16 octets. L'AAD inclut toujours l'identifiant logique de l'entité — l'ID du serveur, par exemple. Conséquence : impossible de recoller le chiffré d'un serveur sur un autre pour le faire déchiffrer dans le mauvais contexte.
Tous les buffers contenant des secrets ou des clés sont effacés après usage (Uint8Array.fill(0)), même si le ramasse‑miettes finirait par le faire. Belt and suspenders.
Ed25519 : signer l'exécution, pas seulement chiffrer le stockage
Chiffrer les identifiants ne suffit pas. Si le plan de contrôle pouvait fabriquer une commande, un attaquant qui le contrôle n'aurait pas besoin de lire quoi que ce soit — il lui suffirait d'exécuter.
C'est pourquoi la clé de coffre dérive aussi une paire Ed25519. Chaque commande est signée dans le navigateur, l'API la relaie telle quelle, et l'agent vérifie la signature sur la machine cible avant d'exécuter. Une option par serveur rend cette signature obligatoire. Corollaire opérationnel : le serveur ne peut jamais envelopper une commande signée dans un sudo ou un cd — la signature ne couvrirait plus ce qui s'exécute.
BIP39 : la phrase de récupération
Que se passe‑t‑il si vous oubliez votre phrase secrète ? On vous a fourni à l'inscription une phrase de récupération BIP39 de 24 mots, à imprimer ou à ranger dans 1Password, Bitwarden ou un coffre physique. Ces 24 mots dérivent un seed déterministe à partir duquel on peut reconstruire votre clé privée, et donc accéder aux DEK emballées à votre nom.
À l'inverse, perdre les deux — phrase secrète ET phrase de récupération — signifie perdre l'accès aux données chiffrées, définitivement. Par design. C'est la contrepartie assumée d'un vrai zero‑knowledge : pas de porte dérobée, pas de support qui « relit votre coffre », pas de petit secret gardé côté serveur.
Ce que Servor voit, ce qu'il ne voit pas
Concrètement, en cas de fuite de notre base de données :
- ce qui sort : du chiffré, avec son IV et son tag, pour chaque secret. Sans la KEK de l'utilisateur, c'est du bruit indistinguable de l'aléatoire.
- ce qui sort aussi : des métadonnées — noms d'équipes, hostnames, adresses e‑mail. Ce n'est pas rien, et il faut le dire.
- ce qui ne sort pas : aucun mot de passe, aucune clé SSH privée, aucun jeton stocké par l'utilisateur.
Formulé autrement, et sans emphase inutile : un plan de contrôle entièrement compromis ne permet ni de lire vos identifiants, ni de forger une exécution. Ce n'est pas une promesse d'invulnérabilité — c'est une réduction de ce qu'une compromission peut rapporter.
Le journal d'audit, c'est aussi de la sécurité
Une chose qu'on aime rappeler : le chiffrement n'est qu'une partie de la défense. Le journal d'audit chaîné par empreintes de Servor enregistre chaque accès au coffre et chaque exécution. Un attaquant qui aurait franchi l'authentification verrait ses actions immédiatement traçables — et le trigger PostgreSQL append‑only l'empêche de nettoyer ses traces. La double authentification est obligatoire, avec re‑vérification exigée sur les opérations sensibles.
Lire aussi : la discipline Plan‑Execute‑Verify de Servor pour comprendre comment ce journal s'intègre au reste du runtime opérationnel.
Pour les sceptiques
Toute modification touchant la cryptographie ou le chemin d'exécution est relue par deux personnes minimum, et rien de ce qui ressemble à un secret, une clé, un IV ou un payload chiffré n'entre dans les journaux. Si vous voulez challenger les choix, lancer un audit, ou simplement comprendre un détail d'implémentation : écrivez‑nous à contact@benode.fr. On répond toujours.