Modèle de sécurité

Cette page décrit ce que Rempar protège, comment, et ce qu'il ne protège pas. Le document de référence est le protocole v1, dont les chaînes sont figées.

Objectif

Une compromission complète du serveur, de ses sauvegardes et de son administrateur ne doit révéler aucun secret : ni mot de passe maître, ni contenu, ni même le nom d'un élément.

Dérivation des clés (appareil uniquement)

password     = NFKC(saisie)
master_key   = Argon2id(password, kdf_salt, m=65536 KiB, t=3, p=4, 32 octets)
auth_key     = HKDF-SHA256(master_key, info="rempart/auth/v1")
wrap_key     = HKDF-SHA256(master_key, info="rempart/wrap/v1")
  • kdf_salt : 16 octets aléatoires, créés avec le compte ou le coffre local.
  • auth_key est envoyée au serveur comme mot de passe de compte. Elle ne permet de dériver rien d'autre.
  • wrap_key ne quitte jamais l'appareil. Elle scelle la clé du coffre.
  • Les clients refusent des paramètres Argon2id plus faibles que m=19456, t=2, p=1, même si le serveur les propose.

Format de scellement

seal(key, plaintext, aad) = base64( 0x01 || nonce(24) || XChaCha20-Poly1305(key, nonce, plaintext, aad) )

Chaque usage a sa chaîne AAD figée : rempart/vaultkey/v1, rempart/itemkey/v1|<item_id>, rempart/item/v1|<item_id>, rempart/export/v1, etc. Un blob ne peut pas être rejoué dans un autre contexte ni attaché à un autre élément.

Coffre et éléments

  • vault_key : 32 octets aléatoires, créés une fois par coffre.
  • Chaque élément a sa propre item_key de 32 octets. Le blob stocké est { k: seal(vault_key, item_key), c: seal(item_key, contenu) }.
  • La liste s'affiche depuis un index scellé local. Ouvrir une fiche ne déchiffre que cette fiche.
  • Les identifiants d'éléments sont des UUID v4 liés dans les deux AAD.

Kit de secours

32 octets aléatoires, affichés une seule fois en Crockford base32. recovery_wrap = HKDF(recovery_key, "rempart/recovery-wrap/v1") scelle une copie de la clé du coffre ; recovery_auth = HKDF(recovery_key, "rempart/recovery-auth/v1") authentifie une restauration auprès du serveur.

Compte et jetons

  • Pré-connexion anti-énumération : un sel factice déterministe est renvoyé pour les e-mails inconnus.
  • Jeton d'accès par appareil (60 min) et jeton de rafraîchissement à rotation (30 jours). Un second usage d'un jeton rafraîchi révoque l'appareil (token_reused).
  • 2FA TOTP optionnelle, recommandée. Obligatoire pour les administrateurs.
  • Toutes les routes sensibles sont limitées en débit.

Côté appareil

  • Secrets masqués par 12 points fixes, remasqués après 30 s.
  • Presse-papiers vidé après 30 s (réglable de 10 s à 2 min). Les phrases de récupération ne se copient jamais en entier.
  • Verrouillage après 5 min, en veille et à la fermeture ; la clé du coffre est mise à zéro en mémoire.
  • Délais progressifs après échec : 30 s, 1 min, 5 min. Jamais d'effacement silencieux.
  • Android : FLAG_SECURE interdit les captures. iOS et macOS : voile de confidentialité dans le sélecteur d'applications.
  • Biométrie : la clé du coffre est confiée au trousseau système protégé par Touch ID, Face ID ou l'empreinte, jamais à un fichier.

Ce que le modèle ne couvre pas

  • Un appareil compromis pendant que le coffre est ouvert (logiciel espion, enregistreur de frappe).
  • Un mot de passe maître faible : Argon2id ralentit l'attaque, il ne la rend pas impossible.
  • La perte simultanée du mot de passe maître et du kit de secours.
  • Les métadonnées de compte : e-mail, nombre d'éléments, taille des blobs, dates et plateformes des appareils.

Signaler une vulnérabilité

Écrivez à security@rempar.org. Nous accusons réception sous 48 heures et publions un correctif avant toute divulgation.

Une question sans réponse ici ? support@rempar.org