Documentation & sécurité

1. Principes

Pas de compte coffre classique : vous ne créez pas chez nous un couple email / mot de passe pour déverrouiller le coffre. L'accès repose sur ce que vous détenez sur l'appareil : le mot de passe maître, un wallet optionnel pour la signature et la sync, et le stockage local (navigateur, extension ou app).

Chiffrement bout en bout (E2EE) : le contenu du coffre en clair est censé n'exister sur votre appareil que pendant l'usage normal. Ce qui quitte l'appareil pour la sauvegarde ou la sync est du chiffré. Nous n'exploitons pas une base centrale de coffres déchiffrés.

Ce qui reste sur l'appareil : clés dérivées et données déchiffrées tant que la session est ouverte ; délégations mises en cache (voir ci-dessous) ; fichiers d'import/export que vous enregistrez en local. Premium ou alias peuvent impliquer facturation ou email comme dans la politique de confidentialité—c'est distinct de la crypto du coffre.

2. Mot de passe maître & signature wallet

Mot de passe maître : votre secret pour la dérivation de clé. Il doit être fort et connu seulement de vous. Nous ne le recevons ni ne le stockons pour le déverrouillage du coffre.

Wallet : prouve la maîtrise d'une adresse via une signature sur un message fixe. Cette signature est combinée avec le mot de passe maître dans l'entrée de la KDF pour les coffres payload v3 typiques (Argon2id côté client, coûteuse en mémoire). Le wallet n'est pas un oracle de chiffrement générique : il ne chiffre pas des données arbitraires à la demande du serveur.

Rôles : le mot de passe apporte l'entropie mémorisée ; le wallet attache le coffre à une adresse que vous contrôlez et permet des opérations signées (ex. publication de mises à jour). Certains clients permettent un mode uniquement local avant liaison wallet ; la sync IPFS suppose un wallet lié et des publications signées.

Délégations : mise en cache optionnelle et limitée dans le temps d'une signature pour le déverrouillage ou l'autosave. Pendant qu'elles sont actives, considérez l'appareil comme digne de confiance : un accès à la session déverrouillée ou un malware peut abuser de ces mécanismes.

3. IPFS & identifiants de contenu (CID)

Le blob du coffre est chiffré sur le client avant envoi (ex. AEAD type XChaCha20-Poly1305 dans la bibliothèque core). IPFS stocke et adresse ce chiffré via un CID.

Qui voit quoi : passerelles et réseau peuvent constater l'existence d'un blob et le récupérer s'ils connaissent le CID. Sans vos clés, ils ne devraient pas pouvoir lire mots de passe ou notes. Le blob est « public » au sens « accessible si on a le CID » ; il ne l'est pas au sens « contenu en clair exposé ».

Une table de correspondance (ex. adresse wallet → dernier CID) peut exister pour la commodité ; elle ne révèle pas le contenu du coffre.

4. Serveur & API

Les API hébergées enrobent les flux clients sans remplacer l'E2EE : par exemple accepter un payload de coffre déjà chiffré pour l'épinglage ou le relais, vérifier une signature wallet, et enregistrer le CID courant pour une adresse (registres de type vault-cid). Les routes et déploiements peuvent évoluer ; cette section décrit l'intention, pas des secrets d'infrastructure.

D'autres points d'accès peuvent servir des métadonnées non secrètes (ex. manifestes de récupération fragmentée indexés par un hash d'un identifiant de récupération que vous gardez privé). Rien ici ne suppose que le serveur puisse déchiffrer votre coffre.

5. Journaux & données

Couche application : les chemins sensibles sont conçus pour ne pas journaliser le coffre en clair, le mot de passe maître, les clés privées ni les signatures brutes.

Limites honnêtes : reverse proxy, hébergeur, CDN et nœuds IPFS hors de notre code peuvent produire des journaux d'accès ou d'erreur (horodatage, IP, URL, statut HTTP, tailles). Nous ne pouvons pas garantir l'absence de logs chez ces tiers. Les contrôles optionnels de fuites de mots de passe (modèle k-anonymity) n'envoient qu'un préfixe de hash vers une API publique, pas le mot de passe entier.

6. Extension & navigateur

XSS & surface web : l'extension dialogue avec des pages non fiables. Un site malveillant ne lit pas directement votre stockage crypto isolé de VaultKeepR par les mécanismes habituels, mais hameçonnage, faux formulaires et spoofing d'interface restent des risques. En cas de doute, privilégiez la confirmation depuis l'interface de l'extension.

Délégations : comme ci-dessus, les signatures mises en cache réduisent les demandes wallet ; un profil navigateur ou une extension compromise pendant une session ouverte augmente la surface d'attaque.

Malware : un malware système ou navigateur peut capturer frappes, écran ou mémoire. Aucun gestionnaire de mots de passe ne neutralise totalement un appareil compromis ; mettez à jour OS et navigateur.

7. Import & export

L'analyse et la transformation s'exécutent en local dans le navigateur ou l'app. L'import ne nécessite pas de nous envoyer le coffre en clair.

Formats courants ou pris en charge selon le client :

• JSON Bitwarden non chiffré
• JSON Proton Pass
• CSV des gestionnaires majeurs (champs normalisés)
• .1pif 1Password lorsque implémenté
• Fichiers enveloppés PGP ou autres formats proposés dans l'app

En général non pris en charge dans l'app : exports Bitwarden chiffrés et archives 1Password .1pux—utilisez JSON Bitwarden non chiffré, CSV ou 1PIF selon le cas. Les exports téléchargés sont aussi sensibles que le coffre ; protégez-les comme une sauvegarde disque.

8. Récupération fragmentée (Premium)

Le découpage optionnel type Shamir permet de définir un seuil (ex. k parmi n) : vous choisissez combien de parts sont nécessaires pour reconstituer le secret utilisé dans le flux de récupération. Les parts peuvent être stockées sur IPFS et/ou d'autres canaux que vous configurez dans l'app.

Un recovery ID (distinct du wallet) est un identifiant secret que vous conservez ; les API publiques peuvent référencer des parts ou manifestes par un hash de cet ID afin qu'un appelant au hasard ne puisse pas énumérer vos données de récupération.

Pas de reset central : nous ne pouvons pas « réinitialiser votre mot de passe maître » ni déchiffrer votre coffre à votre place. La récupération repose sur les parts, le recovery ID et les paramètres que vous avez définis—pas sur une porte dérobée support.

Avant de compter sur la récupération fragmentée pour un coffre de production, faites un essai complet avec un coffre de test : répartissez les parts, vérifiez que le seuil restaure bien l'accès, et confirmez que vous retrouvez le recovery ID—sans effacer le coffre principal tant que le flux n'est pas validé.

Premium couvre aussi TOTP, alias e-mail, etc.—voir la description Premium dans l'app.