La confidentialité relève d’un choix d’architecture, pas d’un document de politique
Sanket repose sur le principe selon lequel le serveur ne peut pas être considéré comme fiable. Une architecture à connaissance nulle, le chiffrement Signal Protocol et des contrôles de confidentialité à plusieurs niveaux garantissent la confidentialité de vos communications par conception - et non par simple promesse.
Serveur à connaissance nulle
Le serveur stocke uniquement le texte chiffré
9 couches cryptographiques
De l’échange de clés au stockage
Secret de transmission parfait
Renouvellement de la clé à chaque message
Aucun modèle fondé sur la publicité
Aucun profilage des métadonnées
Architecture fondamentale
Architecture de serveur à connaissance nulle
Un serveur à connaissance nulle ne stocke et ne relaie que des données chiffrées - il détient des données chiffrées qu'il ne peut pas lire. Cela signifie que l'exploitant de la plateforme, l'administrateur du serveur et toute personne ayant accès au serveur ne peuvent pas lire vos messages, même sur décision de justice.
Modèle de serveur traditionnel
Alice saisit un message
Texte en clair sur l'appareil
Message envoyé par HTTPS
Chiffré uniquement pendant le transit
Le serveur déchiffre et stocke
Le serveur détient les données en clair
Le serveur chiffre à nouveau pour Bob
Le serveur signe à nouveau le message
Le serveur dispose d’un accès complet
L’opérateur peut lire tous les messages
L'opérateur du serveur peut lire tous les messages. Une violation de sécurité, une décision de justice ou une menace interne expose l'ensemble des communications.
Modèle de serveur sans accès aux données de Sanket
Alice saisit un message
Texte en clair sur l'appareil
Message chiffré sur l'appareil
À l’aide de la clé publique de Bob via Signal Protocol
Texte chiffré envoyé au serveur
Le serveur reçoit uniquement un bloc de données chiffrées
Le serveur stocke le texte chiffré
Déchiffrement impossible - aucune clé privée
L’appareil de Bob déchiffre les données localement
Texte en clair uniquement sur l'appareil du destinataire
L'opérateur du serveur n'a aucun accès au contenu des messages. Une violation de sécurité, une décision de justice ou une menace interne ne peut pas révéler les messages en clair.
Ce que garantit une architecture à connaissance nulle
L’opérateur ne peut pas lire les messages
Tosh Defence Private Limited ne peut pas lire le contenu des communications de votre organisation - ni aujourd’hui, ni dans le cadre d’une procédure judiciaire visant l’exploitant de la plateforme.
Une compromission du serveur ne peut pas exposer le contenu
Si un attaquant compromet le serveur Sanket, il n’obtient que des données chiffrées. Sans les clés privées (qui ne quittent jamais les appareils), le contenu ne peut pas être déchiffré.
Les clés privées ne quittent jamais les appareils
Les clés d’identité, de session et de message sont générées et stockées sur l’appareil de l’utilisateur. Le serveur ne détient jamais de clés privées et n’y a jamais accès.
Les sessions passées restent protégées de manière permanente
La confidentialité persistante signifie que les clés éphémères utilisées pour les sessions passées ne sont pas conservées. La compromission de la clé d'aujourd'hui ne permet pas de déchiffrer la conversation d'hier.
Aucun profilage possible à partir des métadonnées
Sans accès aux données en clair, le serveur ne peut effectuer aucune analyse de contenu, recherche de mots-clés, analyse des sentiments ou autre forme de renseignement sur les messages.
Aucun point unique de défaillance pour le déchiffrement
Il n'existe aucune clé maîtresse permettant de déchiffrer tous les messages. Chaque session est chiffrée indépendamment. Une compromission reste toujours limitée à des sessions individuelles.
Algorithme Double Ratchet
Secret de transmission parfait
L’algorithme Double Ratchet de Signal Protocol génère une nouvelle clé cryptographique pour chaque message. Les clés sont éphémères - utilisées une seule fois, puis supprimées. Cette propriété, appelée confidentialité persistante (PFS), signifie que la compromission d’une clé aujourd’hui ne permet pas de déchiffrer les messages envoyés par le passé.
Pour les organisations sensibles confrontées à des adversaires persistants - acteurs malveillants étatiques, espionnage industriel de longue durée ou collecte prolongée de renseignements - la confidentialité persistante n'est pas facultative. Elle fait la différence entre un incident limité et la divulgation de l'ensemble des communications passées.
Début de la session
X3DHL’accord de clés X3DH établit la session initiale à l’aide de clés d’identité, de préclés signées et de préclés à usage unique. Aucun secret prépartagé n’est nécessaire.
Chaque message
DH RatchetLe cliquet Diffie-Hellman progresse à chaque échange de messages et génère de nouvelles clés éphémères. Chaque message utilise une clé unique dérivée de l'état précédent du cliquet.
Dérivation de clé
HKDFHKDF-SHA256 dérive les clés de chiffrement symétrique et les clés MAC de chaque sortie du mécanisme de cliquet. Les clés de message ne sont jamais réutilisées - une fois utilisées, elles sont supprimées de la mémoire.
Messages précédents
PFSLes clés de session supprimées ne peuvent pas être régénérées. Même si un adversaire compromet ultérieurement la clé d’identité permanente d’un appareil, il ne peut pas l’utiliser pour déchiffrer les échanges des sessions passées.
Spécifications cryptographiques
Algorithmes de chiffrement utilisés dans Sanket
Chaque couche de communication de Sanket utilise des normes cryptographiques publiées et évaluées par des pairs - aucun algorithme propriétaire, aucune sécurité fondée sur l’obscurité.
| Couche | Algorithme | Standard | Longueur de clé | Ce que cela protège |
|---|---|---|---|---|
| Accord de clé | X3DH (triple Diffie-Hellman étendu) | Signal Protocol | 255 bits (Curve25519) | Échange initial de clés sans secrets prépartagés |
| Chiffrement des messages | AES-256-GCM | NIST FIPS 197 | 256 bits | Confidentialité et intégrité du contenu des messages |
| Clés de session | Algorithme Double Ratchet | Signal Protocol | 256 bits par étape de la chaîne de dérivation | Confidentialité persistante - les sessions passées restent protégées même si une clé est compromise |
| Couche de transport | TLS 1.3 | RFC 8446 | 256 bits (ECDHE) | Protection des métadonnées et prévention des attaques de l'homme du milieu |
| Épinglage des certificats | Validation de l'épinglage par SHA-256 | RFC 7469 | Sans objet | Prévention des interceptions au niveau du réseau |
| Dérivation de clé | HKDF-SHA256 | RFC 5869 | Sortie de 256 bits | Matériel de clé isolé cryptographiquement pour chaque session |
| Authentification | HMAC-SHA256 | RFC 2104 | 256 bits | Authenticité des messages et détection des altérations |
| Stockage de clé | Enclave sécurisée / StrongBox | Platform TEE | Lié au matériel | Résistance à l'extraction physique des clés |
| Courbe elliptique | Curve25519 / Ed25519 | RFC 8032 / RFC 8031 | 255 bits | Authenticité des clés et vérification de l'identité |
Tous les algorithmes sont des normes ouvertes dont les spécifications sont publiques. Sanket n'utilise aucune implémentation cryptographique propriétaire.
Contrôles à plusieurs niveaux
Contrôles de confidentialité à tous les niveaux
Contrôles administrateur
Création et suppression des comptes utilisateurs - seules les identités approuvées peuvent accéder à la plateforme
Révocation immédiate des accès - retirez immédiatement tout utilisateur de tous les groupes et canaux
Gouvernance des groupes et des canaux - créer, gérer et restreindre les structures de communication des équipes
Gestion de la confiance des appareils - approuver, auditer et effacer à distance les appareils enregistrés
Conservation des messages configurable - définissez des durées de conservation pour toute l’organisation ou propres à chaque canal
Accès aux journaux d’audit - visibilité sur les événements d’accès des utilisateurs et les modifications administratives
Contrôles des utilisateurs
Messages éphémères - définir un délai de suppression automatique pour chaque conversation
Prévention des captures d’écran - restriction de la capture d’écran dans l’application sur les plateformes compatibles
Gestion des accusés de lecture - activer ou désactiver les confirmations de distribution et de lecture
Gestion des sessions actives - consultez et fermez les sessions sur tous les appareils connectés
Confidentialité du contenu des notifications - masquer les aperçus des messages dans les notifications sur l’écran de verrouillage
Verrouillage biométrique de l’application - empreinte digitale ou reconnaissance faciale requise pour y accéder
Contrôles des données de l’organisation
Choix de la localisation des données - sélectionnez la région géographique où les données de votre déploiement sont traitées
Accord de traitement des données conforme au GDPR - un accord formel est disponible pour tous les déploiements de Sanket.Work
Application de la politique de conservation - les administrateurs définissent et imposent les durées de conservation à l'échelle de l'organisation
Aucune publicité ni aucun profilage - aucune extraction commerciale de données à partir du contenu ou des métadonnées des communications
Exportation et portabilité - capacité d’exportation des données pour les demandes d’accès des personnes concernées et l’exercice du droit à la portabilité
Procédures d'effacement - capacité de suppression des données pour respecter le droit à l'effacement prévu par le GDPR
Alignement réglementaire
Communication conçue pour respecter le GDPR
La conformité des plateformes de communication au GDPR ne se résume pas à cocher des cases - elle exige une architecture adaptée. La conception de Sanket, dont les serveurs ne peuvent pas lire les données, ses options de localisation des données et la prise en charge d'un accord formel de traitement des données sont destinées aux organisations soumises aux obligations des responsables du traitement au titre du GDPR.
Demander la documentation GDPRMinimisation des données
Sanket ne collecte que les données nécessaires aux communications. Aucun profil publicitaire, aucun suivi comportemental, aucune conservation inutile des métadonnées.
Droit à l'effacement
Les administrateurs peuvent déclencher la suppression des données des utilisateurs. Les messages éphémères sont supprimés automatiquement. La suppression d’un compte efface de la plateforme le contenu de l’utilisateur.
Portabilité des données
L’exportation des données de l’organisation est disponible à des fins de conformité au GDPR. Les utilisateurs peuvent exporter leur historique de communications dans des formats structurés.
Protection de la vie privée dès la conception
L’architecture de serveur à connaissance nulle fait de la confidentialité l’état par défaut - et non un paramètre de configuration. Le serveur ne peut lire le contenu des messages en aucune circonstance.
Accord avec le sous-traitant des données
Un accord formel de traitement des données conforme au GDPR est disponible pour tous les déploiements de Sanket.Work. Tosh Defence agit en qualité de sous-traitant sous votre responsabilité de responsable du traitement.
Sécurité du traitement
Le chiffrement de bout en bout avec Signal Protocol, le transport par TLS 1.3, le stockage des clés sécurisé par matériel et l’épinglage des certificats satisfont ensemble aux mesures techniques de l’article 32.
Transferts internationaux
Les options de localisation des données permettent leur traitement au sein de l'UE ou de l'EEE. Les déploiements de Sanket.Enterprise sur les serveurs du client maintiennent l'intégralité des données sous la juridiction du client.
Modèle économique
Vos communications ne sont pas un produit
Les plateformes de messagerie grand public tirent leurs revenus de la publicité - ce qui nécessite de comprendre le comportement des utilisateurs. Sanket n’a pas de modèle publicitaire et n’a aucun intérêt à analyser ou à monétiser vos communications.
Plateforme de messagerie grand public
Les revenus publicitaires dépendent de la connaissance du comportement des utilisateurs
Les métadonnées des messages (qui, quand, à quelle fréquence) ont une valeur commerciale
L’analyse des réseaux de contacts sert au ciblage publicitaire
Les conditions d'utilisation autorisent un usage étendu des données à des fins d'« amélioration des services »
Quand un service est gratuit, l’attention et les données de l’utilisateur sont le produit
Sanket
Les revenus proviennent des déploiements et des abonnements - pas des données
Aucune incitation commerciale à analyser les métadonnées des communications
Aucune intégration publicitaire dans le code ou l’infrastructure de la plateforme
Aucun kit de développement logiciel d’analyse tiers dans l’application Sanket
Le client paie pour un service - ses données restent sa propriété
Évaluez l'architecture de confidentialité de Sanket pour votre organisation
Demandez une présentation technique approfondie à l’équipe Tosh Defence. Nous aborderons l’architecture à connaissance nulle, les spécifications du chiffrement, l’accord de traitement des données conforme au GDPR et les options de déploiement adaptées à vos exigences de conformité.