Zero-knowledge maximaliste · bêta privée

Vos noms de secrets
sont aussi chiffrés.

La plupart des gestionnaires de secrets B2B chiffrent rigoureusement le contenu des mots de passe et laissent pourtant en clair, sur leur serveur, les noms, les types et les URLs associées. Si la base de données fuite, l'attaquant lit la carte complète de votre activité sans avoir à déchiffrer la moindre valeur. Aegirex applique le zero-knowledge à toutes les métadonnées : noms, kinds, URIs sont chiffrés depuis le navigateur via OpenPGP SEIPDv2. Le serveur ne stocke qu'un blob opaque.

Rejoindre la bêta privée Lire le threat model

OpenPGP SEIPDv2 ChaCha20-Poly1305 / AES-256 Noms chiffrés Types chiffrés URLs chiffrées Rotation automatisée

01 / Le problème

Ce que la plupart des coffres laissent en clair.

Quand on parle de gestionnaire « zero-knowledge », on pense immédiatement à la valeur du mot de passe. Pourtant, autour de cette valeur, gravitent des métadonnées au moins aussi parlantes : le nom du secret, le type, le domaine concerné, l'arborescence de dossiers. Beaucoup de produits chiffrent uniquement la valeur et exposent le reste à leur serveur, pour des raisons d'ergonomie. Le coût est rarement explicité.

Ce qu'un dump de base peut révéler sans déchiffrer la moindre valeur

Imaginez qu'un attaquant accède à une copie complète de la base de données d'un éditeur dont seul le contenu password est chiffré. Sans même attaquer la cryptographie, il peut reconstruire votre cartographie interne :

un secret nommé « Production AWS - racine - root account » dans un dossier « DevOps / Cloud », propriété d'un compte CTO ;
un secret nommé « SAP HANA - prod EMEA » partagé avec quatre comptes finance ;
un secret nommé « Compte bancaire BNP - SCI X » partagé entre deux dirigeants ;
un secret nommé « Mandataire judiciaire - dossier Y » d'un cabinet d'avocat ;
des URLs en clair pointant vers les outils internes : jira.entreprise.com, vpn.entreprise.com, kibana.entreprise.com.

L'attaquant n'a déchiffré aucun mot de passe. Il connaît pourtant déjà votre stack, vos partenaires, vos dossiers sensibles, et a tout ce qu'il faut pour cibler une attaque de phishing très convaincante sur les bonnes personnes. C'est exactement ce qu'on appelle une fuite « zero-knowledge inutile ».

Le nom raconte tout

Le nom est la première ligne d'info : il désigne l'application, le compte, parfois l'environnement. Une convention de nommage interne diligente l'expose d'autant plus. Sans chiffrement, il devient l'index de votre organisation.

Le type catégorise le risque

Type credential, type certificat, type clé API, type seed TOTP : chacun renseigne sur la sensibilité et sur les pivots possibles. Un attaquant trie en quelques secondes pour isoler les certificats et les clés API.

L'URL trahit l'écosystème

Les URLs principales et alternatives décrivent l'ensemble de votre stack technique et de vos relations partenaires. Elles permettent à un attaquant de cartographier votre périmètre sans une seule requête réseau côté victime.

02 / Notre approche

Une enveloppe cryptographique par entité.

Chaque secret et chaque dossier porte deux colonnes opaques côté serveur. Le contenu plaintext, contenant le nom, le type et les références de template, est sérialisé en JSON puis chiffré côté navigateur via OpenPGP en mode SEIPDv2, avec la même clé que celle qui sert au chiffrement du payload. Le serveur ne déchiffre jamais ces blobs.

Plaintext

Champs métadonnées

Le plaintext sérialisé contient le schéma (metadata/v1 pour un secret, folder_metadata/v1 pour un dossier), le nom, le kind (credential, api_key, certificate, note, totp ou org_template) et la référence éventuelle vers un template d'organisation. Aucun de ces champs n'est lu ni manipulé par le serveur.

Chiffrement

OpenPGP SEIPDv2 dans le navigateur

Le plaintext est chiffré en OpenPGP RFC 9580, en mode SEIPDv2, avec un cipher symétrique AES-256-GCM ou ChaCha20-Poly1305 au choix du client. L'opération a lieu dans le navigateur de l'utilisateur via OpenPGP.js v6, audité par Cure53. Aucune dérivée serveur n'intervient.

Stockage

Deux colonnes opaques côté serveur

Le serveur stocke deux colonnes par entité : encrypted_metadata qui contient le message PGP armuré, et metadata_envelope qui contient un wrapper JSON minimal (version, algorithme et copie du ciphertext). Aucun champ intermédiaire ne décrit le contenu en clair.

Partage

Re-chiffrement direct pour le destinataire

Quand un secret est partagé, le plaintext est re-chiffré directement vers la clé publique du destinataire. Il n'existe pas de clé symétrique intermédiaire à protéger en transit, ni de « clé maître » serveur visible par un attaquant. Moins de surface, plus de coût en re-émission de blobs : un choix architectural assumé.

Décryptage côté navigateur et côté extension

Au moment de l'affichage, le navigateur récupère les enveloppes opaques, les déchiffre via un SharedWorker qui isole la clé privée du contexte de la page, et cache le plaintext en sessionStorage pour la durée de l'onglet. Le cache est vidé automatiquement au verrouillage du coffre, au logout et à la fermeture de l'onglet. L'extension navigateur suit le même modèle dans un cache browser.storage.session dédié.

03 / Comparatif factuel

Métadonnées chiffrées par éditeur.

Le tableau ci-dessous décrit, pour plusieurs éditeurs reconnus du marché, la façon dont les principales métadonnées sont stockées selon leur documentation publique. La qualité globale des produits cités n'est pas remise en cause : la comparaison porte uniquement sur ce périmètre précis. Les informations sont datées du 2026-06-16 et peuvent évoluer rapidement.

Éditeur	Nom du secret	Type / kind	URL / URI
Aegirex	Chiffré côté navigateur (OpenPGP SEIPDv2)	Chiffré côté navigateur	Chiffré côté navigateur
Bitwarden	Selon documentation publique : nom de l'élément stocké en clair dans la base pour les fonctions de recherche et d'autofill côté serveur.	Type (login, card, identity, secure note) visible côté serveur.	URLs associées visibles côté serveur.
1Password	Métadonnées chiffrées dans la spécification publique. Parité de posture sur ce champ précis.	Chiffré dans la spécification publique.	Chiffré dans la spécification publique.
Proton Pass	Métadonnées chiffrées côté navigateur dans la documentation publique.	Chiffré côté navigateur.	Chiffré côté navigateur.
Dashlane	Selon documentation publique : nom de l'item stocké en clair côté serveur pour la recherche cross-device et l'autofill.	Type d'item visible côté serveur.	Domaines associés visibles côté serveur.
NordPass	Selon documentation publique : nom et type exposés côté serveur pour la recherche et l'autofill assistés par le service.	Type exposé côté serveur.	Domaines associés exposés côté serveur.
Passbolt v5.4 et supérieur	Métadonnées chiffrées (envelope dédiée introduite en v5.4). Parité de posture avec Aegirex.	Chiffré.	Chiffré.

Sources : documentation produit publique et whitepapers des éditeurs consultés à la date indiquée. La présence d'un secret avec un nom non chiffré côté serveur n'est pas un défaut de cryptographie ; il s'agit d'un choix produit, motivé par les fonctions de recherche serveur et d'autofill assisté. Aegirex et Passbolt font le choix inverse : confidentialité maximale, recherche côté client après déchiffrement local. Si une information vous semble inexacte, contactez legal@aegirex.eu et cette page sera corrigée.

04 / Trade-off documenté

Le coût UX assumé.

Chiffrer les noms a un coût visible côté ergonomie. Nous préférons documenter ce coût plutôt que de le diluer dans la promesse marketing. La posture est explicitée dans le threat model d'Aegirex, section consacrée aux compromis assumés.

Coût technique

La recherche serveur n'est plus possible

Aucune requête SQL LIKE ou ORDER BY sur le nom ne peut être formulée par le serveur : il ne dispose que d'un blob opaque. Toute opération de filtrage, de tri ou de recherche sur le nom doit avoir lieu après déchiffrement, donc côté client. C'est un renoncement explicite à des optimisations classiques.

Mitigation

Scan client après déchiffrement local

Aegirex pratique le scan client : le SharedWorker déchiffre les enveloppes en batch au chargement du coffre, alimente un cache sessionStorage et permet une recherche instantanée par filtre local sur le plaintext déchiffré. Pour un coffre individuel de 500 entrées, la latence perçue reste inférieure à 250 millisecondes au premier chargement et nulle ensuite.

Limite haute

Coffres très volumineux

Au-delà de plusieurs milliers de secrets dans une même organisation, le coût du déchiffrement batch devient sensible. Pour les organisations concernées, une stratégie de chargement paresseux par dossier et un index local persistant entre sessions sont en préparation. Cette limite ne concerne pas la grande majorité des usages B2B.

Posture

Threat model section 5.1

La section consacrée à la confidentialité avancée du threat model décrit ce compromis dans le détail, l'inscrit dans la matrice STRIDE/LINDDUN et liste les contre-mesures. Le compromis fait partie du contrat produit explicite. Aucun discours commercial ne le minore.

05 / Rotation

Rotation des clés de métadonnées.

Le chiffrement des métadonnées n'a de valeur dans la durée que s'il est accompagné d'une procédure de rotation. Une révocation d'accès, un départ d'employé, une suspicion de compromission imposent de réémettre les blobs pour exclure la clé qui n'a plus à les déchiffrer.

Rotation déclenchée par révocation

Quand un partage est révoqué ou qu'un membre quitte une organisation, un job de rotation est créé automatiquement. Il liste tous les secrets et dossiers concernés. Les clients autorisés drainent le job, re-émettent les blobs sans la clé révoquée et confirment au serveur.

Rotation périodique d'organisation

Un administrateur peut déclencher une rotation périodique complète de l'organisation pour respecter une politique « tous les 90 jours » ou similaire. Le job ré-émet l'ensemble des enveloppes de métadonnées sans interruption du service.

Rotation on-demand et suspicion

Pour un secret ou un dossier précis, un administrateur peut demander une rotation immédiate, soit en mode préventif, soit en mode « suspicion de compromission ». Le motif est typé dans l'audit chain HMAC, ce qui distingue les rotations urgentes des rotations d'hygiène.

Audit chain dédié

Chaque étape (démarrage du job, traitement d'item, complétion, échec, expiration) est inscrite dans la chaîne HMAC-SHA-256 avec un kind dédié. La traçabilité de la rotation est opposable et vérifiable au même niveau que les autres événements critiques.

Parité avec la rotation Passbolt v5.6

La capacité de rotation des métadonnées a été livrée en parité avec la version 5.6 de Passbolt, qui propose un modèle similaire à clé symétrique partagée. Aegirex fait le choix d'une architecture sans clé symétrique partagée : chaque blob est chiffré directement pour la clé publique de chaque destinataire. Cela élimine la « master key » comme cible d'attaque, en échange d'un coût de re-émission par destinataire. Pour les vaults d'organisations inférieurs à 10 000 secrets, le surcoût est négligeable.

06 / Pour qui

Quatre situations où c'est non négociable.

Pour certaines organisations, le nom d'un secret n'est pas une métadonnée mais une donnée sensible à part entière. Voici quatre catégories professionnelles pour qui le chiffrement des noms est une condition d'éligibilité, pas une fonctionnalité bonus.

Banque et finance régulée

Le nom d'un compte « administration HSM Swift » ou « accès traders desk EUR » dans une fuite suffit à orienter une attaque ciblée vers des actifs hautement sensibles, sans qu'aucun mot de passe n'ait été révélé. La régulation prudentielle pousse à minimiser cette surface.

Cabinets d'avocats

Le secret professionnel couvre l'existence même de certaines relations clients et dossiers. Un nom de secret du type « Dossier dirigeant X - procédure pénale » laissé en clair côté serveur trahit l'existence d'une procédure, ce que la déontologie interdit de divulguer.

Secteur défense et collectivités sensibles

Les opérateurs d'importance vitale, les services de sécurité et certaines collectivités traitent par nature des informations dont la seule liste constitue un renseignement utile à un adversaire. Les métadonnées non chiffrées sont incompatibles avec le besoin de cloisonnement.

Journalistes d'investigation

Le nom d'une source, le titre d'une investigation en cours, l'URL d'un système de remontée d'alerte : autant d'informations qui, exposées côté serveur, mettent en danger des sources protégées par la loi sur la protection du secret des sources des journalistes.

07 / Démarrer

Zero-knowledge maximaliste,
par défaut et sans surcoût.

Le chiffrement complet des métadonnées est inclus dans toutes les offres Aegirex, y compris le plan gratuit. Aucun upsell, aucun module payant, aucune option à activer. Demandez l'accès à la bêta privée pour évaluer la posture sur une organisation pilote, ou lisez le threat model complet pour situer ce compromis dans l'architecture globale de la solution.