Architecture à serveur sans accès au contenu : le serveur relaie des données chiffrées
Sanket (Sanket.Chat) de Tosh Defence ne donne aucune visibilité au serveur sur les contenus : le serveur relaie des données chiffrées et ne détient jamais les clés des messages, fichiers, appels, réactions ou diffusions chiffrées. Le contenu est chiffré sur l'appareil de l'expéditeur et déchiffré uniquement sur les appareils des destinataires. Ni Tosh Defence, ni un fournisseur d'hébergement, ni les propres serveurs du client ne peuvent donc le lire.
Un serveur sans accès au contenu change les conséquences d'une compromission du serveur. Un attaquant qui contrôle le serveur ne peut pas lire les contenus antérieurs, car les clés ne lui ont jamais été transmises. Il ne peut pas non plus ajouter discrètement un appareil pour intercepter les échanges, car les expéditeurs vérifient la liste signée des appareils associés à chaque compte.
Ce que signifie « serveur aveugle »
Dans Sanket, le serveur relaie le contenu chiffré. Les messages, les réactions et les diffusions chiffrées sont des messages libsignal chiffrés sur l'appareil de l'expéditeur ; les pièces jointes sont chiffrées avec AES-256-GCM avant leur téléversement ; les trames d'appel sont chiffrées de bout en bout avant d'atteindre le serveur multimédia. Toutes les clés correspondantes sont générées et conservées sur les appareils des utilisateurs.
Même la mention indiquant le niveau de classification d'un message est incluse dans les données chiffrées : le serveur ne peut donc ni la lire ni la modifier.
Un serveur compromis ne révèle aucun contenu
Tosh Defence analyse les conséquences de la compromission de chaque composant côté serveur. Quel que soit le composant compromis, les corps des messages, les réactions, les diffusions chiffrées, les étiquettes de classification, le contenu des fichiers, les flux multimédias des appels et les clés privées restent protégés, car la confidentialité du contenu ne dépend jamais de l'absence de compromission d'un composant serveur.
La reprise suit une procédure unique : reconstruire à partir d’une version vérifiée et signée, renouveler les secrets côté serveur, imposer une nouvelle authentification et examiner le journal d’audit dont toute altération est détectable.
- Corps des messages et réactions
- Les diffusions chiffrées et leur niveau de priorité
- Étiquettes de classification
- Contenu des fichiers
- Flux multimédias des appels
- Clés privées
Aucun auditeur à l'insu des participants
La liste des appareils de chaque compte est signée par une clé détenue sur l’appareil principal de ce compte et consignée dans un journal à ajout seul sur l’installation. Avant de chiffrer un message, l’expéditeur vérifie cette liste et n’envoie rien aux appareils qui n’y figurent pas. Un serveur hostile ne peut donc pas ajouter un appareil pour recevoir des copies. Les numéros de sécurité et les notifications de changement d’identité permettent aux utilisateurs de vérifier directement leurs identités respectives.
Au sein de votre installation
Sanket n'est jamais un service public partagé. Chaque organisation exploite sa propre installation dédiée : les métadonnées de routage nécessaires à la livraison des messages restent donc dans l'installation du client, sous le contrôle de ses administrateurs et soumises à sa politique de conservation et à ses audits.
Les administrateurs régissent les identités, les appareils et les politiques ; ils ne détiennent aucune clé de chiffrement des contenus et ne peuvent pas lire les conversations.
Démonstration technique
Consultez les détails dans le livre blanc de Sanket
Chaque affirmation de cette page est détaillée dans le livre blanc public sur la sécurité technique et l'architecture de SANKET, consultable gratuitement et sans inscription.
Que signifie le fait que le serveur ne puisse pas lire les données ?
Un serveur sans accès au contenu relaie des données chiffrées et ne détient jamais les clés des messages, fichiers, appels, réactions ou diffusions chiffrées. Le contenu n'est lisible que sur les appareils des participants à la conversation.
Tosh Defence peut-il lire les messages de ses clients ?
Non. Tosh Defence n'exploite pas les installations des clients et ne dispose d'aucun accès à celles-ci. Le contenu des messages est chiffré de bout en bout à l'aide de clés présentes uniquement sur les appareils des utilisateurs.
Les administrateurs du client peuvent-ils lire les messages ?
Non. Les administrateurs gèrent les identités, les appareils et les règles. Le serveur ne détient aucune clé d'accès aux contenus ; les administrateurs ne peuvent donc pas lire les messages ou les fichiers, ni accéder aux appels.
Que se passe-t-il si un serveur Sanket est compromis ?
Le contenu des anciens messages et fichiers reste confidentiel, car il a été chiffré avec des clés que le serveur n’a jamais détenues. Les listes d’appareils signées empêchent l’attaquant d’ajouter un appareil pour recevoir des copies, et les numéros de sécurité permettent aux utilisateurs de vérifier les identités.
Le serveur peut-il modifier ou rediffuser un message diffusé ?
Non. La priorité, l'échéance de confirmation de réception et l'expiration d'une diffusion chiffrée sont protégées par le chiffrement de bout en bout ; le serveur ne peut donc ni abaisser sa priorité ni la rejouer.
Où vont les métadonnées de routage ?
Les métadonnées de routage nécessaires à l’acheminement des messages restent dans l’installation dédiée du client, soumises à sa propre politique de conservation et à son audit.
Découvrez comment une architecture où le serveur n’a pas accès aux données modifie votre modèle de menace
Tosh Defence présente aux architectes de sécurité l'analyse des conséquences d'une compromission du serveur de Sanket, la confiance accordée aux appareils et le traitement des métadonnées.