OSM - Sécurité

JavaScript est requis pour utiliser One Shot Message. Veuillez l'activer dans votre navigateur.

Chiffré avant d'être stocké

Le contenu transite en TLS 1.3, puis est chiffré en AES-256-GCM avant d'être écrit : il n'est jamais conservé en clair, ni écrit en clair sur nos disques. Pour un fichier, son nom et son type le sont aussi, avec la même clé, et un fichier altéré ou tronqué est détecté : il n'est pas remis en entier. Avec l'option de bout en bout, le chiffrement a lieu plus tôt encore, dans votre navigateur. Le détail des paramètres.

La clé du message vit dans le lien

Unique à chaque envoi et tirée au hasard, elle n'est enregistrée sur aucun de nos serveurs. Qui n'a pas le lien n'a pas la clé.

Verrous optionnels

L'expéditeur peut exiger un code à usage unique reçu par SMS, ou une signature manuscrite horodatée, avant tout accès.

Détruit à la lecture, ou à l'échéance

À la première ouverture, le contenu et l'élément qui permet de le déchiffrer sont supprimés ensemble. Un envoi de plusieurs fichiers s'ouvre sur leur liste : chacun est détruit de même dès son téléchargement, et ceux que le destinataire n'a pas pris le sont 30 minutes après l'ouverture ; d'ici là, seul le navigateur qui a ouvert l'envoi peut les télécharger. Un message jamais consulté ne reste pas pour autant : l'expéditeur fixe à l'envoi un délai, de 12 heures à un mois, au terme duquel il est détruit de la même façon, sans avoir été lu. Dans les deux cas l'effacement est définitif, pas un simple masquage, et aucune sauvegarde n'en garde copie : ni les contenus ni les vecteurs ne sont jamais sauvegardés.

Cinq machines, trois éléments nécessaires au déchiffrement, volontairement séparés

Lire un message demande trois éléments : le contenu chiffré, le vecteur d'initialisation qui permet de le déchiffrer, et la clé du message. Nous les avons délibérément dissociés. Le contenu et le vecteur vivent sur deux machines distinctes, toutes deux à l'écart de la base qui gère les comptes et les envois, et la clé, elle, n'est stockée sur aucune : elle n'existe que dans le lien que vous transmettez.

Trois familles de clés, à ne pas confondre :

La clé de votre message est unique, tirée à chaque envoi, et n'est stockée nulle part : elle voyage dans le lien.
Les clés du service, détenues par la machine 4, protègent tout autre chose : les numéros de mobile, l'identité et la signature manuscrite d'un signataire, les secrets d'authentification à deux facteurs, et elles apposent la signature qui donne aux dossiers de preuve leur intégrité et traçabilité.
La clé des liens, enfin, chiffre le lien lui-même, pour que ni l'identifiant du message ni sa clé n'apparaissent en clair dans les journaux d'un serveur, un en-tête de provenance ou l'historique d'un navigateur. Aucune des deux dernières ne permet d'ouvrir un message.

Ni le vecteur ni le contenu ne se récupèrent sans le lien. Le serveur applicatif n'atteint jamais la base des vecteurs directement : il passe obligatoirement par le service cryptographique, qui y dépose le vecteur à l'envoi. Cette base, comme celle des contenus, ne rend ensuite ce qu'elle garde que sur présentation d'une empreinte dérivée de la clé du lien, et le vecteur est détruit aussitôt repris. Sans le lien, l'un comme l'autre restent donc hors de portée, y compris depuis nos propres serveurs.

Ce qu'une intrusion donnerait

Le cloisonnement se juge à une question : que récupère quelqu'un qui prend le contrôle d'une machine ?

Machine compromise	Ce que l'intrus obtient
Serveur applicatif	Du code applicatif, et la clé qui protège les liens, qui n'ouvre aucun message. Ni contenu ni vecteur : sans le lien, il ne peut en obtenir aucun. Un contrôle indépendant de l'application compare régulièrement ses fichiers à une référence et alerte l'équipe de tout ajout ou modification.
Base de l'application	Les comptes (mots de passe hachés), l'historique des envois et des dossiers de preuve chiffrés par le service cryptographique, comme les références d'envoi, qui le sont avec une clé propre à chaque organisation. Aucun contenu de message, même chiffré.
Base des contenus	Du contenu chiffré, sans la clé ni le vecteur qui permettraient de le lire, ni rien qui le rattache à un compte ou à un expéditeur. Le nom d'un fichier y est chiffré au même titre que lui.
Service cryptographique	Des clés qui n'ouvrent aucun message, et un accès aux vecteurs qui reste conditionné à l'empreinte de la clé du lien.
Base des vecteurs	Des vecteurs d'initialisation, sans contenu ni clé associés.

Aller plus loin : le chiffrement de bout en bout

Messages texte comme fichiers, une option de chiffrement de bout en bout déplace encore la frontière. Le contenu est alors chiffré dans votre navigateur avant le moindre envoi, et la clé reste dans la partie du lien située après le « # », une portion d'URL que les navigateurs, par conception, n'envoient jamais au serveur. La clé ne nous est jamais transmise : elle reste dans le fragment de l'URL et le chiffrement est effectué dans votre navigateur. Notre infrastructure serveur ne dispose donc pas de la clé permettant de déchiffrer le contenu. Votre navigateur ne nous transmet qu'une empreinte de cette clé, qui ne permet pas de la reconstituer : elle ouvre l'accès au vecteur et au contenu chiffré, jamais leur déchiffrement.

Pour un fichier, la différence se joue sur qui peut rouvrir le nom. Il est chiffré dans les deux cas, mais en mode ordinaire nos serveurs le déchiffrent le temps de remettre le fichier au destinataire ; en bout en bout, ils ne le peuvent jamais. Ils n'en gardent qu'un bloc d'octets opaque, restitué tel quel, sans savoir de quoi il s'agit.

Le chiffrement en détail

Pour qui veut vérifier, voici les paramètres exacts, en mode ordinaire comme de bout en bout.

Ce qui est chiffré	Vecteur d'initialisation et intégrité
Un message texte	Vecteur de 96 bits, tiré au hasard à l'envoi. Tag de 128 bits.
Le contenu d'un fichier	Vecteur de 96 bits, tiré au hasard à l'envoi. En mode ordinaire, le fichier est chiffré par blocs : chacun a son propre nonce, calculé à partir de ce vecteur et de son rang, et son propre tag de 128 bits. Le rang et la marque du dernier bloc sont authentifiés comme données associées : un bloc altéré, déplacé, retiré ou ajouté, ou un fichier tronqué, est détecté, et le fichier n'est pas remis en entier. De bout en bout, le fichier est chiffré d'un seul tenant, sous un tag de 128 bits : votre navigateur le vérifie en entier avant d'en enregistrer quoi que ce soit.
Le nom et le type d'un fichier	Vecteur de 96 bits, tiré au hasard à l'envoi, distinct de ceux du contenu. Tag de 128 bits.
Plusieurs fichiers dans un même envoi	Chacun est chiffré comme un fichier seul, avec ses propres vecteurs pour son contenu et pour son nom. Leur liste (noms, types et tailles), qui s'affiche à l'ouverture, est chiffrée à part : vecteur de 96 bits tiré au hasard à l'envoi, tag de 128 bits.

Algorithme et clé. Le contenu d'un message, et pour un fichier son nom et son type, sont chiffrés en AES-256-GCM sous la clé du message : 256 bits tirés au hasard à chaque envoi, propres à ce seul message.

Génération. Les vecteurs viennent d'un générateur aléatoire cryptographique : celui de notre serveur en mode ordinaire, celui de votre navigateur de bout en bout. Aucun ne dépend d'un compteur ni de l'horloge ; seuls les nonces des blocs d'un fichier sont calculés, à partir de son vecteur et du rang du bloc.

Unicité. Sous une même clé, aucun vecteur ne sert deux fois : chaque chiffrement a le sien, le contenu (en mode ordinaire, chacun de ses blocs) comme le nom, et dans un envoi de plusieurs fichiers, chacun d'eux comme leur liste. Tirés au hasard sur 96 bits, ou calculés à partir de rangs distincts pour les blocs, deux d'entre eux ne coïncideraient qu'avec une probabilité négligeable, et l'envoi le vérifie malgré tout : en mode ordinaire, notre serveur tire alors d'autres vecteurs ; de bout en bout, il refuse l'envoi. Chaque opération AES-GCM utilise un vecteur d'initialisation unique ; aucune paire clé/IV n'est réutilisée.

Séparation. Le nom et le type, chiffrés ensemble, ont leur propre vecteur. Comme celui du contenu, il est conservé à part, dans la base des vecteurs, et détruit à la lecture : une copie du chiffré et le lien ne suffisent pas à lire le nom d'un fichier. Dans un envoi de plusieurs fichiers, la liste a aussi son vecteur, conservé de même et détruit à l'ouverture, et chaque fichier garde les siens jusqu'à son téléchargement.

Liaison. Le nom reste attaché à son fichier sans données associées. Il est rangé sous l'identifiant du message, ou du fichier dans un envoi qui en porte plusieurs, et ne se reprend qu'avec l'empreinte de sa clé. Surtout, il est chiffré sous une clé qui n'existe que pour ce message : placé dans un autre, il ne s'y déchiffrerait pas. En mode ordinaire, les données associées servent là où elles apportent quelque chose : lier chaque bloc d'un fichier à son rang, et le dernier à la fin du fichier.

L'API et ses jetons

Une API REST permet d'automatiser l'envoi depuis vos propres applications. Elle ouvre une porte de plus, et se traite comme telle : chaque appel s'authentifie par un jeton, et ce jeton donne strictement moins de pouvoir qu'on ne l'imagine.

Des jetons qu'on ne peut pas retrouver

Chaque clé fait 256 bits tirés au hasard et n'est affichée qu'une seule fois, à sa création. Nous n'en conservons qu'une empreinte SHA3-256, irréversible. Une clé perdue se remplace ; elle ne se récupère pas, pas même par nous.

L'API ne relit aucun contenu

Les points de consultation ne renvoient que des métadonnées : date d'envoi, lecture ou non, échéance. Aucun ne restitue le message ni le fichier. Un jeton dérobé n'ouvre donc aucun envoi déjà parti.

Restreinte par adresse, révocable sur-le-champ

Chaque clé peut être limitée à une liste d'adresses ou de plages. Sa révocation prend effet dès l'appel suivant, et chaque usage laisse une trace horodatée avec l'adresse d'origine.

Des notifications signées, et vides de contenu

Chaque livraison de webhook porte une signature HMAC-SHA256 qui permet d'en vérifier l'origine. Elle ne transporte que l'identifiant de l'envoi et l'événement : lu, signé, ou expiré.

Le chiffrement de bout en bout n'est pas disponible par l'API : il suppose un navigateur, seul endroit où la clé peut être fabriquée sans jamais nous parvenir. Un envoi par l'API voyage bien sûr en TLS 1.3, comme toute autre requête ; mais c'est notre serveur qui le chiffre ensuite, et il voit donc le contenu le temps de cette opération, en mémoire seulement, avant de l'écrire en AES-256-GCM. Pour la confidentialité maximale, l'envoi depuis le navigateur reste la voie à privilégier.

Le pare-feu applicatif

Chaque requête est inspectée avant que la moindre ligne de code du service ne s'exécute, avant l'ouverture d'une session et avant tout accès aux données. Une requête hostile est écartée sans jamais atteindre l'application.

Moteur de motifs

Détecte les familles d'attaques connues : injection SQL, script intersites, traversée de chemin, sondage automatisé.

Contrôle positif

Chaque page déclare les paramètres qu'elle attend. Tout ce qui n'y figure pas est refusé, plutôt que de tenter d'énumérer le nuisible.

Limitation de débit

Le rythme des requêtes est plafonné par adresse, avec un seuil renforcé sur les pages d'authentification.

Réputation d'adresses

Aux blocages décidés sur place s'ajoutent les listes communautaires CrowdSec, qui signalent les adresses déjà hostiles ailleurs.

Le journal du pare-feu ne conserve ni le corps des requêtes, ni les cookies, ni les en-têtes d'authentification. Il retient ce qui a été refusé, jamais ce que la requête transportait.

Vous avez été bloqué ?

Toute défense automatique se trompe parfois. Si une page de refus s'est affichée, voici ce qu'elle signifie.

Écran	Ce qui s'est passé
403	Accès refusé. La requête correspond à un motif d'attaque, ou porte un paramètre que la page n'attend pas.
429	Trop de requêtes. Le rythme d'envoi depuis votre adresse a dépassé le plafond. Il suffit d'attendre.
405	Méthode non autorisée. Le type de requête employé n'est pas accepté par le service.
418	« Je suis une théière ! » Trop de tentatives non autorisées ou de requêtes suspectes depuis votre adresse : l'accès est suspendu quatre heures, puis se rouvre de lui-même.

Vous pensez avoir été bloqué à tort ? Écrivez-nous via le support en indiquant cette référence et l'heure approximative.

Vous avez trouvé une faille ?

Les signalements de sécurité sont les bienvenus et traités sérieusement. Nos coordonnées dédiées et notre clé publique figurent dans le fichier /.well-known/security.txt, au format RFC 9116. Merci de nous laisser un délai raisonnable de correction avant toute publication.

Une fois corrigées, les failles sont publiées avec leur impact, au même titre que les bugs notables, dans la liste des correctifs.

Le détail des données traitées et de leurs durées de conservation figure dans notre politique de confidentialité.

Comment vos messages sont protégés