logo
One Shot Message BETA
Lecture unique · Destruction automatique
logo
Sécurité

Comment vos messages sont protégés

Le chiffrement, le cloisonnement de l'infrastructure et les défenses qui filtrent le trafic, expliqués en clair.

Infrastructure & gestion 100% française

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. Pour un fichier, son nom et son type le sont aussi, avec la même clé. Avec l'option de bout en bout, le chiffrement a lieu plus tôt encore, dans votre navigateur.

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 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.

Quatre machines, trois secrets 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, et la clé, elle, n'est stockée sur aucune : elle n'existe que dans le lien que vous transmettez.

Architecture cloisonnée de One Shot Message Le navigateur atteint le serveur applicatif à travers le pare-feu. Le serveur applicatif dialogue d'une part avec la base des contenus chiffrés, d'autre part avec le service cryptographique, seul à pouvoir atteindre la base des vecteurs d'initialisation, où il les dépose puis les retire. La clé du message ne figure sur aucune de ces machines ; les clés détenues par le service cryptographique protègent d'autres données et n'ouvrent aucun message. Navigateur du visiteur HTTPS · TLS 1.3 Pare-feu applicatif 1 Serveur applicatif Sert le site, le back-office et l'API. Ne détient aucune clé ouvrant un message. 2 Base des contenus Messages et fichiers chiffrés en AES-256-GCM. Ni la clé, ni le vecteur. 3 Service cryptographique Seul chemin vers les vecteurs. Signe les preuves et chiffre les données annexes (ex. : numéro de téléphone). Ses clés n'ouvrent aucun message. 4 Base des vecteurs Vecteurs d'initialisation, détruits à la lecture ou à l'échéance. Ni contenu, ni clé. La clé de votre message Unique, tirée au hasard à l'envoi, elle n'est écrite sur aucune de ces machines : elle voyage dans le lien, et nulle part ailleurs.
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 3, 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 valeur probante.
  • 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.
Le vecteur ne se récupère pas 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, ne le restitue que sur présentation d'une empreinte dérivée de la clé du lien, puis le détruit aussitôt. Sans le lien, le vecteur reste 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. Aucune n'ouvre un message.
Base des contenus Du contenu chiffré, sans la clé ni le vecteur qui permettraient de le lire. 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.
Aucune de ces quatre lignes ne suffit à lire un message. Et l'élément qui manque à chacune d'elles, la clé du message, n'existe sur aucune de ces machines.
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. Elle ne nous parvient donc pas, et SysMeek n'a alors aucun accès au contenu, même en théorie.

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.

La contrepartie est réelle : un lien de bout en bout tronqué, ou amputé de sa partie située après le « # », devient définitivement illisible. Personne ne peut le récupérer, nous pas davantage que vous.
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, 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 depuis votre adresse dans la dernière heure. L'accès se rouvre de lui-même.
La référence affichée en bas de l'écran de refus (huit caractères, par exemple 9F2A41C8) est le seul élément à nous communiquer : elle nous permet de retrouver l'événement exact. Elle ne contient aucune donnée personnelle et n'a de sens que dans notre journal.

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.

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