En juin 2026, trois événements ont relancé le débat sur les garanties réelles des gestionnaires « zero-knowledge » : une étude académique d'ETH Zurich et Aalto University cartographie 25 attaques exploitables si le serveur est compromis, une fuite chez LastPass transite par un CRM tiers, et un chercheur de DEF CON 33 démontre le détournement d'autofill par clickjacking. Voici l'impact concret de ces trois événements sur l'architecture ARDNTECH, sans rhétorique marketing.
Publié le 23 juin 2026 par ARDNTECH EI · Analyse interne à partir des divulgations publiques
Un vol de jetons OAuth chez Klue (outil d'intelligence commerciale intégré à Salesforce) a permis d'accéder aux données de contact de clients LastPass. Les coffres chiffrés n'ont pas été exposés. Le risque réel est le phishing ciblé à partir d'une liste de contacts volée chez un sous-traitant périphérique, pas le compromis du noyau cryptographique.
Enseignement : le zero-knowledge protège les coffres, pas les métadonnées détenues par des tiers.
Matteo Scarlata et ses coauteurs (relayés par Ars Technica) cartographient 25 attaques montrant que les garanties « zero-knowledge » de Bitwarden, Dashlane et LastPass se dégradent si le serveur est compromis et que certaines fonctionnalités opt-in sont actives : récupération de compte, partage via distribution de clés publiques, rétrocompatibilité cryptographique (downgrade KDF).
Enseignement : un ZK formellement correct doit résister au scénario d'un serveur compromis, pas seulement à un administrateur honnête.
Marek Tóth démontre que l'autofill de 11 gestionnaires peut être déclenché par un overlay invisible. Un seul clic sur un faux bandeau cookies suffit à remplir les champs d'une page contrôlée par l'attaquant. La surface touchée est la logique d'injection DOM de l'extension, pas le coffre serveur.
Enseignement : l'extension navigateur est une surface d'attaque distincte du serveur, à durcir indépendamment.
L'étude cible trois familles de fonctionnalités qui, sur serveur compromis, affaiblissent les garanties ZK. Voici leur correspondance dans l'architecture ARDNTECH.
| Vecteur de l'étude | Architecture ARDNTECH | Verdict |
|---|---|---|
|
Récupération de compte
Copie de la clé de coffre stockée côté serveur, utilisable si le serveur est compromis |
Le wrap est produit côté client (Argon2id) à partir d'un code de récupération que seul l'utilisateur détient. Le serveur stocke des wraps opaques : il ne peut pas re-dériver la clé. Consommation avec scrub immédiat. | Sain |
|
Downgrade cryptographique
Forcer un client à utiliser un algorithme plus faible lors du wrap de récupération |
Bloqué côté serveur : un composant d'inspection parse l'armure réelle (SKESK v6, S2K Argon2id, AEAD présent, coûts plancher). Un client trafiqué qui downgrade est rejeté et contraint à une réactivation. | Neutralisé |
|
Substitution de clé publique au partage
Le serveur sert sa propre clé à la place de celle du destinataire |
Le serveur expose la clé publique + empreinte du destinataire. Un correctif de juin 2026 (repo extensions) couvre la vérification côté client. Point résiduel : s'assurer qu'un changement de clé d'un contact connu déclenche une alerte explicite. | En vérification |
|
Clés de récupération admin (type LastPass)
Un admin de groupe peut re-chiffrer le coffre d'un utilisateur côté serveur |
ARDNTECH ne dispose pas de mécanisme « break-glass admin » côté serveur qui re-chiffrerait la clé de coffre d'un utilisateur vers une clé admin. Le partage d'équipe passe uniquement par la clé publique de l'équipe et son empreinte. | Sain par conception |
Synthèse : un serveur ARDNTECH compromis ne permet pas de déchiffrer les wraps de récupération - ils sont opaques, dérivés côté client d'un secret que le serveur ne détient pas, et le downgrade KDF est refusé à l'enregistrement. Ce sont précisément les scénarios exploités dans d'autres gestionnaires par l'étude ETH/Aalto. Ils sont fermés ici par des choix architecturaux documentés dans le modèle de menace.
La recherche de Tóth vise la logique d'injection DOM des extensions. L'autofill et l'autologin sont les surfaces concernées. Le coffre serveur n'est pas en cause - c'est l'extension qui remplit les champs qui peut être trompée. Les points suivants sont en cours d'audit dans l'extension ARDNTECH.
visibility:hidden, taille proche de zéro ou élément recouvert (hit-testing du point de clic).window.top === window.self ou même origine.z-index maîtrisé, revérification de visibilité au moment du clic.Un noyau cryptographique sain peut être contourné par la stack SaaS périphérique. Les coffres LastPass n'ont pas bougé, mais une liste de contacts a été volée chez un intégrateur CRM tiers.
Les sous-traitants actuels de ARDNTECH (Scaleway, Brevo, Stancer, HIBP, Bugsink) sont cadrés dans le registre publié sur la page Confiance. Le zero-knowledge protège les coffres, pas une liste de contacts dans un CRM tiers non répertorié.
Rotation des jetons d'intégrations tierces, scopes minimaux, révocation immédiate en cas d'incident. Les accès aux systèmes périphériques ne doivent pas permettre de reconstituer une cartographie des clients.
Zero-knowledge vérifiable, hébergé en France, code source AGPLv3. La bêta privée est accessible sur inscription.