Skip to main content

SCORECARD

Quels outils et applications protègent réellement vos messages ?

Face à la cybersurveillance généralisée, nous avons besoin d'un moyen sûr et pratique pour parler les uns aux autres de nos téléphones et ordinateurs. Beaucoup de compagnies offrent des produits de « messagerie sécurisée » — mais ces systèmes sont-ils réellement sûrs ? Nous avons décidé de le découvrir, dans la première phase d'une nouvelle campagne de l'EFF pour une cryptographie sécurisée et facile d’utilisation.

Cette fiche d’évaluation représente seulement la première phase de cette campagne. Dans les phases ultérieures, nous prévoyons d’offrir des examens plus étroits concernant la convivialité et la sécurité des outils dont le score est le plus élevé. Par conséquent, les résultats de la fiche d’évaluation ci-dessous ne devraient pas être interprétés comme une approbation des outils individuels ou une garantie de leur sécurité ; il s’agit simplement d’éléments indiquant que les projets sont sur la bonne voie. Pour des conseils pratiques et des tutoriels sur la façon de protéger vos communications en ligne face à la surveillance, consultez le guide d’autoprotection digitale contre la surveillance de l'EFF.

À propos

Pendant des années, des experts de la confidentialité et de la sécurité dans le monde entier ont appelé le public à adopter une cryptographie forte et open source afin de protéger nos communications. Les révélations de Snowden ont confirmé nos pires craintes : les gouvernements épient nos vies numériques, saisissant des communications transmises en clair.

Étant donné la surveillance gouvernementale généralisée, pourquoi les gens n’utilisent pas couramment des outils pour chiffrer leurs communications ? Ne communiquerions-nous pas tous un peu plus librement sans l'ombre de la surveillance ?

Cela se résume à deux choses : sécurité et convivialité. La plupart des outils qui sont faciles à utiliser par le grand public n’appliquent pas des pratiques exemplaires de sécurité (y compris le cryptage de bout à bout et le code source ouvert). Les outils de messagerie qui sont vraiment sécurisés ne sont souvent pas faciles à utiliser ; les utilisateurs quotidiens peuvent avoir des difficultés pour installer la technologie nécessaire, pour vérifier son authenticité, pour créer un compte, ou peuvent les utiliser accidentellement de manière qui expose leurs communications.

L’EFF, en collaboration avec Julia Angwin de ProPublica et Joseph Bonneau du Princeton Center for Information Technology Policy, unissent leurs forces pour lancer une campagne pour une cryptographie sécurisée et conviviale. Nous défendons des technologies qui sont très sécurisés mais aussi simples à utiliser.

La Fiche d’évaluation de messagerie sécurisée (Secure Messaging Scorecard) examine des dizaines de technologies de messagerie et évalue chacune d’entre elles sur une série des meilleures pratiques de sécurité. Notre campagne est axée sur les technologies de communication (y compris les clients de messagerie instantanée, des applications de messagerie texte, des applications de messagerie électronique et les technologies d’appels vidéo). Ce sont les outils dont les utilisateurs quotidiens ont besoin pour communiquer avec leurs amis, leur famille et leurs collègues, et nous avons devons pouvoir leur proposer des solutions sécurisées.

Nous avons choisi des technologies qui ont une base importante d'utilisateurs (et donc beaucoup de communications sensibles) en outre de plus petites entreprises qui innovent en matière de pratiques de sécurité. Nous espérons que la fiche d'évaluation servira à une course vers l’excellence, stimulant l'innovation autour d’une cryptographie forte des communications numériques.

Méthodologie

Voici les critères que nous avons examinés dans l'évaluation de la sécurité des différents outils de communication.

1. Votre communication est-elle chiffrée en transit ?
Ce critère exige que les communications de l’utilisateur soient chiffrées sur toutes les liaisons dans la voie de communication. Veuillez noter que nous n'exigeons pas le chiffrement des données qui sont transmises sur un réseau d'entreprise, même si ce serait l'idéal. Nous ne demandons pas que les métadonnées (telles que les adresses ou noms d'utilisateurs) soient chiffrées.

2. Votre communication est-elle chiffrée avec une clé à laquelle le fournisseur n'a pas accès ?
Ce critère exige que toutes les communications de l'utilisateur soient chiffrées de bout en bout. Cela signifie que les clés nécessaires pour décrypter les messages doivent être générées et stockées dans les points de terminaison (c.-à-d. par les utilisateurs, et non par les serveurs). Les clés devraient jamais laisser de points de terminaison sauf par une action explicite de l'utilisateur, comme celle de créer une clé de sauvegarde ou de synchroniser des clés entre deux périphériques. C’est acceptable que les clés publiques des utilisateurs soient échangées à l'aide d'un serveur centralisé.

3. Pouvez-vous vérifier de façon indépendante l’identité de votre correspondant ?
Ce critère exige qu'il existe une méthode intégrée pour que les utilisateurs puissent vérifier l'identité de leurs correspondants ainsi que l'intégrité du canal de communication, même si le fournisseur de services ou d'autres tierces parties sont compromis. Deux solutions acceptables sont :

  • Une interface pour que les utilisateurs puissent afficher l'empreinte (hash) de clés publiques de leurs correspondants ainsi que la leur, permettant de les vérifier ensuite manuellement ou en local.

  • Un protocole d'échange de clés avec une comparaison de type Short Authentification String (SAS), tel que le protocole du millionnaire socialiste.

D’autres solutions sont possibles, mais toute solution doit vérifier la liaison entre les utilisateurs et le canal de chiffrement qui a été mis en place. Pour la fiche d’évaluation, nous demandons simplement qu'un mécanisme soit présent et nous n’évaluons pas sa facilité d'utilisation ni sa sécurité.

4. Les communications passées sont-elles sécurisées si vos clés sont volées ?

Ce critère exige que l'application offre une confidentialité persistante (forward secrecy), autrement dit, que toutes les communications soient chiffrées avec des clés éphémères qui sont systématiquement supprimés (de même que les valeurs aléatoires utilisées pour leur création). Il est impératif que ces clés ne puissent pas être reconstruites après le fait par quiconque même s’il a obtenu l’accès aux clés privées à long terme des deux parties, garantissant ainsi que si les utilisateurs choisissent de supprimer leurs copies locales de correspondance, que celles-ci sont définitivement supprimées. Notez que ce critère exige le critère numéro 2, un chiffrement de bout en bout.

Remarque : Pour cette phase de la campagne, nous acceptons une approche hybride utilisant la confidentialité persistante sur la couche de transport (par exemple par le biais de TLS avec une suite de chiffrement Diffie-Hellman) et un chiffrement de bout en bout sans confidentialité persistante, plus une garantie explicite que les textes chiffrés ne sont pas enregistrées par le fournisseur. Il s'agit d'un compromis car il faut faire confiance au fournisseur de ne pas enregistrer les textes chiffrés, mais nous préférons cette configuration plutôt que de n’avoir aucune forme de confidentialité persistante.

5. Le code est-il ouvert à un examen indépendant ?

Ce critère exige qu’une portion suffisante de code source ait été publiée afin qu'une implémentation compatible puisse être compilée de manière indépendante. Bien que cela soit préférable, nous ne demandons pas que le code soit distribué sous une licence libre ou open source spécifique. Nous demandons seulement que l’ensemble du code qui pourrait affecter la communication et le chiffrement effectué par le client soit disponible pour examen afin de pouvoir détecter des bogues, des portes dérobées et des problèmes structurels.

Remarque : lorsque les outils sont fournis par un vendeur de système d'exploitation, nous avons seulement besoin du code de l'outil et non pas de l'OS en entier. Il s'agit d'un compromis, mais la tâche de sécuriser les systèmes d'exploitation et les mises à jour de systèmes d'exploitation dépasse le cadre de ce projet.

6. La conception cryptographique est-elle bien documentée ?

Ce critère exige qu’il existe des explications claires et détaillées de la cryptographie utilisée par l'application. De préférence, cela devrait prendre la forme d'un livre blanc écrit pour une vérification par un public de cryptographes professionnels. Cela doit apporter des réponses aux questions suivantes :

  • Quels algorithmes et paramètres (tels que les tailles de clés ou les groupes de courbes elliptiques) sont-ils utilisés à chaque étape du processus de cryptage et d'authentification ?

  • Comment les clés sont-elles générées, stockées et échangées entre les utilisateurs ?

  • Quel est le cycle de vie des clés et le processus pour que les utilisateurs puissent modifier ou révoquer leur clé ?

  • Une déclaration claire des propriétés et des protections que le logiciel a pour but de fournir (implicitement, cela tend à fournir également un modèle de menace, mais il est bon de prévoir en outre un modèle de menace explicite). Cela devrait inclure en outre un énoncé clair des scénarios dans lesquels le protocole n'est pas sûr. 

7. Un audit de sécurité indépendant a-t-il été conduit ?

Ce critère exige qu'un audit de sécurité indépendant ait été effectué dans les 12 mois avant l'évaluation. Cette vérification doit couvrir le concept ainsi que la mise en œuvre de l’application et doit être effectué par un service d’audit reconnu, indépendant de l'équipe principale de développement de l'outil. Un audit réalisé par une équipe de sécurité indépendante au sein d'une organisation de grande taille est jugé adéquat. Reconnaissant que les audits non publiés peuvent être précieux, nous n’exigeons pas que les résultats de l’audit aient été rendus publiques, seulement qu'une partie nommée soit disposée de s’assurer que la vérification a eu lieu.

Nous avons discuté de ce critère en profondeur dans article des Deeplinks : Qu’est-ce qui constitue un bon audit de sécurité ?
 

Journal des modifications

Les entrées de la Fiche d’évaluation de messagerie sécurisée ont été confirmées auprès des entreprises et des projets énumérés lors du lancement de la Scorecard le 11-06-2014. Des mises à jour seront effectuées si les participants ou autres nous informent de changements ou d’inexactitudes. Vous trouverez ci-dessous le journal de toutes les modifications :

  • 06-12-2015 :
    • Nous avons retiré Secret car ce service a fermé en mai 2015.
  • 06-03-2015 :
    • Nous avons crédité QQ pour avoir conduit un audit interne de sécurité indépendant ().
  • 17-02-2015 :
    • Nous avons crédité Telegram (mode secret et mode normal) pour avoir été soumis à un audit de code en février 2015 ().
  • 29-01-2015 :
    • Nous avons crédité QQ pour le cryptage des messages en transit (). Bien que QQ n'utilise pas de TLS/SSL, ce qui est considéré comme la meilleure pratique, ils ont mis en œuvre un protocole personnalisé pour le cryptage des messages en transit.
    • Nous avons clarifié notre système de notation pour la confidentialité persistante (critère #4).
  • 05-01-2015 :
    • Nous avons réparti le score de Telegram en deux rangées : conversations Telegram normales et conversations Telegram secrètes. Les conversations normales Telegram ne sont pas chiffrées de bout en bout afin que le fournisseur ne puisse pas les lire. (). Les conversations secrètes de Telegram le sont, et en outre Telgram prend désormais en charge la confidentialité persistante parfaite afin que les messages puissent être supprimés en toute sécurité ()
    • .

    • Wickr offre maintenant la possibilité de vérifier l'identité d’un contact en exposant les principales empreintes digitales, qui peuvent être vérifiées en local ou par l'intermédiaire de la bande vidéo. ()
  • 14-11-2014 :
    • RIM nous a dit que BlackBerry Messenger Protected utilise une phrase de chiffrement d’échange hors-bande et EC-SPEKE pour effectuer la vérification d'identité. (✓) RIM nous a également dit que BBM Protected reçoit des révisions de sécurité par une équipe interne de sécurité. (✓)
    • Viber a reçu un récent audit de sécurité externe de la part d’EY Advanced Security Center. (✓)
    • Pidgin a recensé un certain nombre d’audits de procédures, y compris l'utilisation régulière des outils d'analyse statique et des audits par une équipe de Cisco Talos. Les développeurs de Pidgin ont été clairs qu'ils ne savent pas à quel point ces audits ont été complets et approfondis, mais ces audits satisfont néanmoins nos critères. (✓) Bien que l'audit de Pidgin améliore la sécurité du projet connexe Adium (les projets partagent de nombreux composants y compris libpurple, libotr et libxml2), les développeurs d'Adium nous disent qu'à part l'analyse statique occasionnelle effectuée par les développeurs eux-mêmes, ils ne sont pas au courant d’un effort d’audit indépendant traitant le code spécifique d’Adium. Donc, pour le moment, ce projet ne recevra pas de coche pour un audit vérification.
  • 10-11-2014 : La coche de la case pour le chiffrement de bout à bout a été retirée pour Skype. (✘)
  • 04-11-2014 : L’application Snapchat a reçu un audit par une équipe interne de sécurité. (✓)

Back to top

JavaScript license information