Résumé : Une récente controverse a éclaté concernant la sécurité de l'application de messagerie Session, un fork de Signal. Un ingénieur en sécurité a soulevé plusieurs préoccupations majeures, notamment l'absence de "forward secrecy", des vulnérabilités dans la gestion des clés cryptographiques, et l'utilisation d'algorithmes potentiellement obsolètes comme SHA1PRNG. Ces critiques suggèrent que l'application pourrait être vulnérable à diverses attaques, permettant potentiellement le déchiffrement de messages passés et l'usurpation d'identité. En réponse, les développeurs de Session ont fermement contesté ces allégations, les attribuant à des malentendus techniques. Ils affirment que leur système utilise une entropie de 128 bits pour la génération des clés, maintient un processus robuste de validation des signatures, et que l'absence de Perfect Forward Secrecy est un choix délibéré lié à leur architecture décentralisée. Cette confrontation met en lumière les défis complexes et les débats techniques inhérents au développement d'applications de messagerie sécurisée.
L'application Session est un fork de l'application de messagerie Signal, souvent vantée pour sa confidentialité et sa sécurité. Cependant, après une analyse approfondie par un ingénieur en sécurité, cette application présenterait des failles qui compromettraient la sécurité de ses utilisateurs. Dans cet article, nous allons décortiquer les problèmes techniques qui auraient été identifiés de manière simple et accessible.
1. Qu'est-ce que "Forward Secrecy" et pourquoi est-ce important ?
Le concept de "forward secrecy" (ou "sécurité persistante") est un principe clé dans les systèmes de communication sécurisée. En termes simples, il garantit que même si un attaquant parvient à obtenir une clé secrète utilisée pour chiffrer des messages dans le futur, il ne pourra pas déchiffrer les messages déjà envoyés. Chaque conversation a donc sa propre clé unique qui change à chaque session.
Problème avec Session : L’application Session a supprimé le forward secrecy, ce qui signifie que si un attaquant parvient à voler une clé secrète, il pourrait potentiellement déchiffrer non seulement les futurs messages, mais aussi ceux envoyés dans le passé. C'est un gros risque pour la confidentialité, surtout dans un contexte où des informations sensibles sont échangées.
2. Les attaques par "Key Compromise Impersonation" (KCI)
Une des attaques les plus dangereuses possibles sur un système de messagerie sans forward secrecy est l'attaque par Key Compromise Impersonation (KCI). Cette attaque permet à un attaquant de se faire passer pour un utilisateur légitime en utilisant une clé secrète volée.
Problème avec Session : Comme il n'y a pas de forward secrecy, un attaquant qui parvient à voler la clé d’un utilisateur pourrait ensuite lire tous les messages futurs, voire les envoyer en son nom. C'est une menace sérieuse, car l'attaquant peut ainsi manipuler les conversations sans que les utilisateurs ne s'en aperçoivent.
3. La gestion des clés cryptographiques : Erreurs de conception
Dans une application de messagerie sécurisée, il est crucial que les clés cryptographiques soient gérées de manière fiable et sécurisée. Une des erreurs majeures dans Session est la manière dont les clés sont générées et utilisées.
Problème avec Session : L’application utilise une méthode de génération de clés qui présente des failles. Les clés cryptographiques, qui sont censées protéger les messages, peuvent être exposées à des attaques plus facilement que dans d'autres systèmes bien conçus comme Signal. Cela affaiblit la sécurité globale de l’application.
4. Les signatures et leur validation
Lorsqu’un message est envoyé dans une application sécurisée, une signature cryptographique est souvent utilisée pour garantir que le message provient bien de l'expéditeur et qu'il n'a pas été modifié pendant son transfert. Cela fonctionne de manière similaire à un cachet de cire sur une lettre : il assure l'intégrité et l'authenticité du message.
Problème avec Session : Dans le cas de Session, la validation des signatures n'est pas effectuée correctement. Cela signifie qu'un attaquant pourrait modifier un message en toute discrétion, en remplaçant des clés publiques sans que cela ne soit détecté. En d'autres termes, la signature n'est pas une preuve fiable que le message provient bien de l'expéditeur prévu. C’est un gros problème, car cela compromet l'authenticité des messages.
5. Utilisation d'algorithmes obsolètes et vulnérables
Les applications sécurisées utilisent des algorithmes cryptographiques modernes et éprouvés pour protéger les données des utilisateurs. Session, cependant, utilise certains algorithmes qui ne sont pas adaptés à des niveaux de sécurité élevés, ce qui peut les rendre vulnérables à des attaques.
Problème avec Session : Par exemple, l’application utilise SHA1PRNG (un générateur de nombres aléatoires basé sur un vieux standard appelé SHA-1), qui est connu pour ne pas être sécurisé. Cela peut compromettre la génération de clés et rendre plus facile pour un attaquant de prédire ou de manipuler les clés utilisées pour chiffrer les messages.
6. L’importance de l'aléatoire sécurisé
Pour générer des clés cryptographiques sécurisées, il est nécessaire d'utiliser un générateur de nombres aléatoires qui ne peut pas être prédit. Si un générateur de nombres aléatoires est faible, il devient possible pour un attaquant de deviner les clés et de déchiffrer les messages.
Problème avec Session : Sur Android, Session utilise une méthode de génération de nombres aléatoires qui n’est pas sécurisée. Cela rend l'application vulnérable aux attaques où un attaquant pourrait obtenir les clés secrètes générées et accéder aux messages de manière illégale.
7. Conclusion selon cet ingénieur : Ne faites pas confiance à Session
En résumé, Session présente plusieurs failles de sécurité critiques qui compromettent la confidentialité et l’intégrité des messages. L'absence de forward secrecy, la gestion défaillante des clés, la mauvaise validation des signatures et l’utilisation d’algorithmes obsolètes font de cette application un choix risqué pour quiconque souhaite protéger sa vie privée.
Si vous êtes préoccupé par la sécurité de vos conversations, il est fortement recommandé de vous tourner vers des alternatives comme Signal, qui ont démontré une approche plus rigoureuse en matière de sécurité.
Il est essentiel de se rappeler que la sécurité numérique est un domaine complexe, mais il est tout aussi essentiel de faire des choix éclairés pour protéger notre vie privée et nos données sensibles.
8. La réponse de Session face à ces problèmes :
Les développeurs de Session ont répondu en expliquant que ces accusations étaient basées sur des erreurs de compréhension ou des malentendus techniques.
1. Clé Ed25519 et entropie : Session utilise 128 bits d'entropie pour générer des clés, garantissant ainsi une sécurité de 128 bits, contrairement à la prétendue réduction à 64 bits mentionnée par le chercheur. Cette approche a été validée par un audit externe.
2. Validation des signatures : Le processus de validation des signatures dans Session est robuste et permet de vérifier l'identité de l'expéditeur sans compromettre la sécurité des messages, contrairement à ce que suggérait le chercheur. Les développeurs expliquent que le chercheur a mal interprété le code.
3. Réutilisation des clés publiques pour les requêtes onion : La réutilisation des clés publiques n'existe pas dans Session. La clé publique et la clé privée sont utilisées séparément pour chaque requête, assurant une sécurité optimale. Session démontre que c'est une erreur d'interprétation du code source, et que le système utilise correctement des clés éphémères.
D'autres préoccupations soulevées, comme le décodage mnémotechnique non sécurisé ou l'utilisation de SecureRandom sur de vieilles versions d’Android, ne présentent pas de risques pratiques. Enfin, la décision de ne pas inclure la Perfect Forward Secrecy (PFS) dans Session est expliquée par une volonté d'optimiser l'architecture décentralisée de l'application.
Session réaffirme son engagement envers la sécurité et la confidentialité des utilisateurs, avec un code open source et une approche transparente.
article généré depuis :
https://soatok.blog/2025/01/14/dont-use-session-signal-fork/
https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture