Quel est le niveau de sécurité de TEPHIA SECURE ?
Comment vos fichiers sont chiffrés, ce qui est stocké sur nos serveurs – et ce qu'obtiendrait un attaquant qui en prendrait entièrement le contrôle. Sans discours marketing, en toute transparence.
Chiffré dans le navigateur
Vos fichiers sont chiffrés avant de quitter votre ordinateur et ne sont déchiffrés que chez le destinataire.
La clé n'atteint jamais le serveur
Chaque envoi a son propre mot de passe aléatoire de 32 caractères. Notre serveur ne le voit jamais.
Des métadonnées pour la preuve
Nous ne pouvons lire que des informations comme le nom du fichier, les adresses, les dates et heures : celles qui sont nécessaires à l'établissement de la preuve de remise.
Comment fonctionne le chiffrement
- Mot de passeVotre navigateur crée un mot de passe aléatoire : 32 caractères, environ 190 bits.
- CléArgon2id en dérive la clé, ce qui rend chaque tentative de devinette coûteuse.
- ChiffrementAES-256-GCM chiffre le fichier et détecte toute modification ultérieure.
- EnvoiCe n'est qu'ensuite que le fichier part, via TLS 1.2 ou 1.3. Le mot de passe reste chez vous.
Le mot de passe ne fait pas partie du lien. Vous le transmettez par un second canal, par exemple dans un e-mail séparé ou par téléphone. Quiconque intercepte uniquement le lien ne peut pas ouvrir le fichier.
Boîte de dépôt
Quiconque vous dépose des documents les chiffre de la même manière dans son navigateur. Le serveur ne connaît qu'une valeur de contrôle du mot de passe, qui ne permet de rien déchiffrer.
Exception : pour que vous puissiez retrouver le mot de passe, nous vous l'envoyons par e-mail lors de la création de la boîte de dépôt. Il transite une fois par le serveur et n'est pas enregistré.
Complément Outlook
Le complément chiffre directement dans Outlook. Le mot de passe passe par votre propre système de messagerie, pas par notre serveur ; les fichiers eux-mêmes ne passent pas par votre système de messagerie.
Deux voies : TEPHIA SECURE envoie à chaque destinataire son propre lien et le mot de passe figure dans votre e-mail ; ou le lien figure dans votre e-mail et le mot de passe suit dans un second. Quiconque dispose du lien et du mot de passe peut récupérer le fichier – comme pour tout envoi par e-mail. Avec la seconde voie, la récupération peut être limitée aux adresses des destinataires ; un code reçu par e-mail est alors nécessaire en plus.
Détails techniques
- Dérivation de clé : Argon2id avec 64 Mo de mémoire, 4 passes et 2 threads, suivi de HKDF-SHA256
- Chiffrement : AES-256-GCM, avec un sel aléatoire propre (32 octets) et un IV (12 octets) par envoi
- Chiffrement par blocs : le fichier est chiffré et téléversé par blocs de 8 Mio, chacun avec son propre nonce (IV XOR numéro de bloc) ; le numéro de bloc et un marqueur de dernier bloc, en tant que données authentifiées additionnelles (AAD), empêchent d'intervertir, d'omettre ou de tronquer des blocs. Cela permet des fichiers jusqu'à 2 Go
- Sans WebAssembly (bloqué par une politique d'entreprise, par exemple) : PBKDF2-SHA512 avec un million d'itérations
- Plusieurs fichiers ou dossiers sont regroupés dans un ZIP dans le navigateur avant le chiffrement
- Transport : TLS 1.2 ou 1.3 avec confidentialité persistante (forward secrecy), HSTS pendant deux ans, Content Security Policy stricte
- Mots de passe de connexion : scrypt avec un sel individuel ; un second facteur est obligatoire
Ce qui se trouve sur notre serveur
Uniquement chiffré, ou pas du tout
- Contenu de vos fichiers : uniquement chiffré
- Mot de passe et clé d'un envoi : jamais
- Mot de passe d'une boîte de dépôt : uniquement une valeur de contrôle
- Mots de passe de connexion : uniquement sous forme d'empreinte
- Connexion avec Microsoft : rien, cela reste chez Microsoft
- Données de paiement : rien, elles sont détenues par Stripe
Lisible, pour la preuve
- Noms et tailles des fichiers, pour un ZIP également les noms qu'il contient
- Intitulé et message
- Expéditeur avec nom, adresse et organisation
- Adresses des destinataires, si nous envoyons le lien ou si la récupération est limitée
- Dates et heures, adresse IP et localisation approximative lors de la récupération
- Sommes de contrôle (SHA-256) des fichiers, calculées dans votre navigateur
Nous envoyons les e-mails contenant le lien à vos destinataires et les notifications telles que « Votre fichier a été récupéré » via Microsoft 365 et Hornetsecurity (transmission, contrôle antivirus et antispam). Ils ne contiennent aucun nom de fichier, seulement l'intitulé que vous choisissez vous-même ou le nombre de fichiers ; le mot de passe d'un envoi ne figure dans aucun de nos e-mails. Le PDF de la preuve de remise, qui contient les noms de fichiers, n'est joint que si vous activez cette option dans votre compte.
Et si quelqu'un prend le contrôle du serveur ?
Nous partons du pire scénario : un attaquant contrôle entièrement le serveur, la base de données et le stockage des fichiers.
Ce qu'il obtiendrait
- Les fichiers chiffrés présents à ce moment sur le serveur – illisibles sans le mot de passe
- Les métadonnées : qui a envoyé quoi à qui, quand, les noms de fichiers et les adresses. Un nom comme « Divorce_Martin.pdf » en dit déjà long.
Ce qu'il n'obtiendrait pas
- Le contenu des envois et des boîtes de dépôt passés : les mots de passe n'ont jamais été sur le serveur, et 190 bits ne peuvent pas être cassés par force brute
- Les fichiers supprimés : ils ne figurent pas non plus dans une sauvegarde
- Les mots de passe Microsoft et les données de paiement
Comment nous nous en protégeons
- Conservation courte : les fichiers sont supprimés après la récupération. Ce qui n'existe plus ne peut pas être volé.
- Code d'une seule source : l'application web ne charge son code que depuis notre propre serveur, et une Content Security Policy stricte empêche l'injection de code.
- Accès verrouillé : maintenance uniquement avec une clé et uniquement depuis des réseaux définis ; les organisations sont en outre séparées dans la base de données.
- Notification en cas d'incident : si nous détectons une intrusion, nous en informons les organisations concernées dans les meilleurs délais (art. 33 RGPD).
Combien de temps faudrait-il pour casser un fichier intercepté ?
Même avec un milliard de cartes graphiques, un attaquant aurait besoin en moyenne d’environ 4 × 1037 ans.
Supposons que quelqu'un intercepte un fichier chiffré – pendant le transfert ou sur le serveur. Sans le mot de passe, il ne lui reste qu'à essayer des mots de passe les uns après les autres. Voici le temps qu'il lui faudrait en moyenne :
À titre de comparaison : l'univers a environ 1,4 × 1010 ans. Même avec un milliard de cartes graphiques, il faudrait environ 1027 fois cette durée.
Pourquoi cela prend autant de temps
- De longs mots de passe aléatoires : chaque envoi reçoit son propre mot de passe de 32 caractères, créé dans votre navigateur. Cela représente environ 2,3 × 1057 possibilités (190 bits).
- Chaque tentative coûte cher : avant de pouvoir être vérifié, un mot de passe doit passer par Argon2id, avec 64 Mo de mémoire et quatre passes. Cela freine délibérément les cartes graphiques et le matériel spécialisé.
- La clé elle-même (AES-256), avec ses 2256 possibilités, serait encore plus difficile à deviner que le mot de passe.
Et les ordinateurs quantiques ?
En l'état actuel des connaissances, un ordinateur quantique réduit tout au plus de moitié le nombre de bits lorsqu'il essaie toutes les possibilités. Les 190 bits deviendraient en théorie 95, et chaque tentative devrait toujours passer par Argon2id. Cela reste, là aussi, très loin de toute puissance de calcul envisageable.
Les chiffres sont estimés largement en faveur de l'attaquant et arrondis à un chiffre significatif. Le calcul porte sur la moyenne, c'est-à-dire la moitié de toutes les possibilités.
Les attaques réalistes ne visent donc pas le chiffrement, mais le mot de passe : quiconque obtient à la fois le lien et le mot de passe n'a rien à casser. C'est pourquoi les deux empruntent toujours des chemins séparés – voir Ce que vous pouvez faire vous-même.
Où les données sont conservées et pendant combien de temps
Ce que vous pouvez faire vous-même
- Envoyez le mot de passe et le lien séparément, jamais dans le même message.
- Connectez-vous avec Microsoft et désactivez la connexion par mot de passe, ou utilisez une clé de sécurité ou une passkey.
- Choisissez des noms de fichiers neutres si le nom lui-même est confidentiel.
- Limitez la récupération aux adresses des destinataires : le lien et le mot de passe ne suffisent alors plus à eux seuls.
Nos limites, en toute transparence
- Les métadonnées telles que noms de fichiers, adresses, dates et heures nous sont lisibles ; elles sont nécessaires à l'établissement de la preuve.
- Le mot de passe d'une boîte de dépôt transite une fois par notre serveur, par Microsoft 365 et par Hornetsecurity lors de la création de la boîte de dépôt.
- Microsoft et Hornetsecurity voient ce que contiennent nos e-mails : expéditeur, intitulé, votre message, le lien, dates et heures – aucun nom de fichier et jamais le mot de passe d'un envoi.
- La vérification à l'envoi du complément Outlook est fournie par Cloudflare, afin que l'envoi des e-mails ne dépende pas de la disponibilité de notre serveur. Cloudflare voit l'adresse IP et l'identifiant du navigateur, pas les contenus.
- La somme de contrôle de chaque fichier est lisible pour nous. Elle ne révèle aucun contenu, mais indique si un fichier déjà connu a été transmis.
- Comme pour tout chiffrement dans le navigateur, la protection des nouveaux envois dépend de la livraison du code de l'application web sans modification – c'est pourquoi nous protégeons le serveur lui-même avec un soin particulier.
Vous avez trouvé une vulnérabilité ? Merci de la signaler de manière confidentielle à l'adresse indiquée dans notre security.txt.