ByteSync est conçu comme un système de synchronisation sécurisé à connaissance zéro.
Cette page fournit une vue d’ensemble technique claire de la manière dont l’application protège les données, les identités et la communication entre les clients.
Elle résume les principes fondamentaux du modèle de sécurité de ByteSync et explique pourquoi le serveur ne peut accéder à aucune information significative concernant vos fichiers, dossiers ou activité de session.
Pour une spécification technique approfondie, consultez le
document Client Security Architecture sur GitHub :
https://github.com/POW-Software/ByteSync/blob/master/docs/client-security-architecture.md
1. Aperçu du modèle de sécurité
ByteSync utilise des normes cryptographiques modernes et bien établies pour garantir que seuls les clients autorisés peuvent participer à une session de synchronisation et accéder à son contenu.
Les principes clés comprennent :
- Chiffrement de bout en bout pour toutes les métadonnées, les informations de session et le contenu des fichiers
- Serveur à connaissance zéro : le relais cloud ne peut pas déchiffrer ou interpréter les données
- Système de Clients de Confiance pour vérifier les identités et empêcher l’usurpation d’identité
- Clés de chiffrement par session, jamais partagées avec le serveur
- Isolation cryptographique entre les clients dans toutes les sessions
ByteSync est conçu de manière à ce que la sécurité ne dépende pas de l’infrastructure cloud.
Même si le serveur est compromis, les données chiffrées restent illisibles.
2. Aperçu du chiffrement
ByteSync combine la cryptographie asymétrique et symétrique :
2.A. Cryptographie asymétrique (RSA-2048)
Utilisé pour :
- Identité du client
- Échange de clés publiques
- Signatures numériques
- Livraison sécurisée des secrets de session
Chaque client génère une paire de clés RSA-2048 lors du premier lancement.
Le serveur ne connaît que deux choses sur un client :
- Son adresse IP
- Sa clé publique RSA
Aucune autre information sur le client n’est stockée ou déduite.
2.B. Cryptographie symétrique (AES-256)
Utilisé pour :
- Chiffrement de session
- Chiffrement des métadonnées
- Chiffrement du transfert de fichiers
- Protection du stockage local
Chaque session de synchronisation reçoit une clé AES-256 unique, partagée en toute sécurité entre les participants.
Le serveur ne reçoit jamais cette clé.
2.C. Hachage
ByteSync utilise :
- SHA-256 pour les identificateurs de client, l’intégrité des métadonnées et le hachage au niveau de la session
- SHA-512 pour la liaison cryptographique à l’intérieur des signatures
- MD5 uniquement pour la vérification hors bande lisible par l’homme (pas pour la sécurité)
3. Clients de Confiance
ByteSync utilise un modèle de confiance décentralisé appelé Clients de Confiance.
Au lieu d’une autorité de certification centrale, chaque utilisateur confirme l’identité des autres clients par le biais d’une étape de vérification hors bande.
Comment ça marche
- Deux clients échangent leurs clés publiques RSA (via le serveur).
- Les deux calculent une clé de sécurité partagée, dérivée de :
– Leurs clés publiques RSA (SHA-256)
– Un sel de session aléatoire - Les utilisateurs comparent la clé de sécurité hors bande (appel téléphonique, chat, etc.).
- Si les valeurs correspondent, la clé publique est stockée localement comme fiable.
Une fois approuvé, un client peut rejoindre les sessions futures sans répéter l’étape de vérification.
Avantages
- Empêche les attaques de l’homme du milieu
- Empêche le serveur d’injecter des clés malveillantes
- Assure la stabilité à long terme de l’identité du client
- Maintient la confiance entièrement sous le contrôle de l’utilisateur
4. Serveur à connaissance zéro
Le backend cloud de ByteSync agit uniquement comme un relais et un orchestrateur.
Il ne peut pas lire, interpréter ou reconstruire les données échangées entre les clients.
Le serveur ne connaît PAS :
- Les noms de fichiers
- Les structures de répertoires
- Le contenu des fichiers
- Les noms de machines
- Les sources ou chemins de données
- Les métadonnées de session
- Les actions effectuées par les membres
Il ne voit que :
- Les blobs de session chiffrés
- Les tranches de fichiers chiffrées
- Les hachages SHA-256 lorsque cela est nécessaire pour acheminer le contenu chiffré
- Les adresses IP
- Les clés publiques RSA
Toutes les informations significatives sont chiffrées côté client avant la transmission.
Pourquoi le serveur ne peut rien déchiffrer :
- Il ne reçoit jamais les clés de session AES
- Il ne peut pas dériver les mots de passe de session
- Il ne peut pas usurper l’identité d’un client (grâce aux Clients de Confiance)
- Il stocke les blobs chiffrés sans pouvoir les interpréter
Cette architecture assure la confidentialité même en cas de compromission du serveur.
5. Transferts de fichiers chiffrés
Tous les transferts de fichiers sont chiffrés de bout en bout à l’aide de AES-256-CBC.
Caractéristiques :
- Les fichiers sont chiffrés à la volée avant le téléchargement
- Le déchiffrement n’a lieu que sur la machine du destinataire
- Chaque fichier a un vecteur d’initialisation (IV) unique
- Les transferts utilisent des tranches chiffrées, n’exposant jamais le texte brut
- Le serveur ne traite que des données chiffrées opaques
Étant donné que les noms, les chemins et les métadonnées sont également chiffrés, le serveur ne sait même pas quel fichier est transféré, ni combien.
Résumé
ByteSync fournit un environnement de synchronisation sécurisé à connaissance zéro basé sur :
- Les identités RSA-2048
- Les sessions et les transferts de fichiers chiffrés AES-256
- Les Clients de Confiance pour empêcher l’usurpation d’identité
- La vérification hors bande pour la confiance initiale
- Le hachage fort (SHA-256 / SHA-512)
- Les métadonnées et les noms de fichiers chiffrés
- Un serveur relais sans capacité de déchiffrer ou d’interpréter les données
Pour une analyse cryptographique plus approfondie, des détails sur le cycle de vie des clés et des diagrammes de protocole, consultez le document technique officiel :
https://github.com/POW-Software/ByteSync/blob/master/docs/client-security-architecture.md
