🔐 bmlink
Zéro connaissance côté serveur

Transférer un secret ou un fichier avec un lien éphémère sécurisé.

bmlink chiffre les secrets et les fichiers directement dans le navigateur avant l'envoi. Le serveur ne stocke que des données chiffrées, applique l'expiration et garde l'historique d'activité.

Connexion salariés du siège Voir la documentation
🔐
Secrets

Envoyer un mot de passe ou un texte sensible

Le secret est chiffré directement dans le navigateur, puis rendu inutilisable après consultation réussie ou expiration.

  • Clé conservée uniquement dans le fragment de l'URL
  • Serveur incapable de lire le contenu en clair
  • Consommation uniquement après déchiffrement réussi
📦
Fichiers

Transférer des fichiers ou dossiers temporaires

Les fichiers sont découpés en morceaux, chiffrés localement, puis stockés sur le serveur uniquement sous forme illisible.

  • Fichiers chiffrés avant l'envoi
  • Manifest chiffré pour masquer noms et arborescence
  • Expiration et purge des données chiffrées
0 clé serveurla clé de déchiffrement n'est jamais stockée côté backend
Chiffrement localla donnée est protégée avant de quitter le navigateur
Liens éphémèresexpiration configurable et désactivation après usage réussi
Données opaquesle serveur conserve uniquement du contenu chiffré
Documentation

Fonctionnement technique

Le principe de sécurité est le même pour les secrets et les fichiers : le navigateur chiffre avant l'envoi, puis le serveur stocke uniquement des données illisibles et applique l'expiration.

1L'utilisateur prépare un secret, un fichier ou un dossier dans son navigateur.
2Le navigateur génère localement une clé aléatoire de chiffrement.
3Le contenu est chiffré côté client avec AES-GCM avant toute transmission au serveur.
4Le serveur reçoit seulement un identifiant, une date d'expiration et des données chiffrées.
5La clé reste dans le fragment de l'URL, partie qui n'est pas envoyée au backend lors de l'ouverture du lien.
6Le destinataire récupère les données chiffrées, déchiffre localement dans son navigateur, puis le lien devient inutilisable après usage réussi.

Secret

  1. Le texte est encodé dans le navigateur.
  2. Une clé AES-GCM et un vecteur d'initialisation sont générés localement.
  3. Seuls le texte chiffré, l'IV et les paramètres d'expiration sont envoyés au serveur.
  4. À l'ouverture, le navigateur utilise la clé du lien pour déchiffrer le contenu.
  5. Le lien est consommé uniquement si le déchiffrement réussit.

Fichier

  1. Le navigateur construit un manifest local décrivant les fichiers et dossiers.
  2. Le manifest est chiffré pour masquer les noms, chemins et informations sensibles.
  3. Les fichiers sont découpés en chunks afin de supporter des volumes plus importants.
  4. Chaque chunk est chiffré avant l'upload et stocké hors du dossier public.
  5. Au téléchargement, le navigateur déchiffre les chunks et reconstruit le fichier côté client.
Sécurité

Modèle zéro connaissance

Clés de déchiffrement

Elles restent côté navigateur et ne sont jamais stockées par l'application.

Contenu clair

Secrets et fichiers sont chiffrés avant l'upload ; le serveur ne manipule que du chiffré.

Métadonnées fichiers

Le manifest est chiffré afin de ne pas exposer les noms de fichiers ni l'arborescence.

Expiration

Le serveur contrôle la durée de vie du lien et purge les données chiffrées expirées.

Limite importante : comme pour toute application web chiffrée de bout en bout, si le serveur est compromis avant le chargement de la page, un attaquant pourrait tenter de modifier le JavaScript envoyé au navigateur. C'est une limite structurelle du modèle web E2EE, à connaître pour les usages très sensibles.