PrivacyTools.io

Chapitre sur le chiffrement avancé

Chapitre sur le chiffrement avancé

Je sais, j’ai déjà abordé différents domaines du chiffrement avec des niveaux de détail variables. Mais je pense qu’un aspect qui mérite d’être souligné encore davantage est un point que j’ai soulevé un peu plus haut. “Quand vous vous battez littéralement pour votre vie en ligne, ne placez JAMAIS toute votre confiance dans une seule entreprise ou un seul service”. Cela s’applique aussi au chiffrement à tous les niveaux. Disons que vous avez un dossier contenant 6 ou 7 fichiers top secret et que vous devez vous assurer que ce dossier est à l’abri de toutes les formes de compromission. Vous voudriez vous assurer que ce dossier soit stocké sur un système entièrement chiffré et à l’abri des regards indiscrets. Personnellement, je chiffrerais intégralement (FDE) une clé USB avec VeraCrypt et un mot de passe de 45 à 50 caractères. Je m’assurerais que l’algorithme de chiffrement soit en cascade, comme AES(Serpent). Je monterais ensuite la clé USB chiffrée et placerais, disons, 400 fichiers aléatoires (images, fichiers .txt quelconques, etc.) dans le répertoire racine. Puis VeraCrypt (ou macOS avec un .dmg chiffré) servirait à créer un conteneur chiffré sur cette même clé USB en utilisant un mot de passe différent de 50 caractères et 3 fichiers de clé sélectionnés parmi les 300 images.

Le dossier contenant les informations sensibles serait alors stocké dans le conteneur VeraCrypt sur la clé USB chiffrée. Pour attaquer cette configuration, il faudrait d’abord pénétrer dans la clé USB en attaquant VeraCrypt, soit par force brute sur le mot de passe (pas facile avec une telle longueur de mot de passe), soit en attaquant le chiffrement lui-même (ce qui n’arrivera pas non plus en raison du mode cascade utilisé). Pour dire les choses franchement : le chiffrement intégral de la clé USB ne sera pas cassé à moins qu’ils ne puissent voler votre mot de passe. De plus, cet adversaire devrait ensuite réussir à pénétrer dans le conteneur VeraCrypt stocké sur ladite clé USB. Un autre exploit pratiquement impossible en raison du mot de passe de 50 caractères et de la sécurité supplémentaire apportée par l’utilisation de 3 fichiers de clé parmi un lot de 400. ‘apt-get install overkill —fix-missing’

Quand nous prenons ce même type de raisonnement et l’appliquons à la communication sécurisée avec quelqu’un, nous devrions nous retrouver à chercher une méthode qui nous permettrait d’appliquer notre propre chiffrement par-dessus le chiffrement fourni par le service que nous utilisons pour communiquer. Idéalement, quelque chose comme XMPP (en utilisant OTR et votre propre serveur bien sûr) avec Tor Messenger pour rester anonyme serait une méthode bonne et sécurisée pour communiquer. En plus de cela, nous pourrions écrire nos messages localement dans un document .txt puis chiffrer le texte avec la clé PGP de l’autre personne avant de le lui envoyer. Un adversaire devrait d’abord casser OTR (Off-The-Record) ou attaquer le client que nous utilisons ET casser les messages chiffrés avec PGP. Le protocole OTR devrait faire usage de la perfect forward secrecy pour garantir que, même si vous perdez votre clé privée, aucun message précédent ne puisse être compromis. Quelle que soit la forme de communication que vous utilisez, je m’assurerais qu’elle emploie une PFS solide et qu’elle dispose d’un moyen simple d’ajouter une forme de chiffrement par-dessus (comme PGP). Je suis d’accord avec Snowden quand il dit que Signal est une façon très sécurisée de communiquer avec quelqu’un. MAIS, il faudrait idéalement un vrai téléphone jetable qui ne soit pas lié à son identité, sinon il faut donner son numéro de téléphone personnel à l’autre partie. ET il faut pouvoir vérifier le code source sur l’appareil où on l’installe, une fonctionnalité qui n’est pas encore disponible pour iOS.

Un autre gros problème que nous rencontrons quand nous envisageons de communiquer de façon sécurisée avec quelqu’un est la manière dont nous choisissons et déployons cette “méthode” de communication. Si le FBI, la CIA, le GCHQ ou une autre organisation de renom sait que nous utilisons name@myserver.com via XMPP pour initier nos communications secrètes avec quelqu’un, ils savent quoi attaquer. En revanche, si nous rencontrons quelqu’un sur un serveur TeamSpeak quelconque, lui envoyons en message privé les détails d’un serveur IRC chiffré employant un bon SSL et ne journalisant pas les connexions, puis initions une conversation OTR avec la personne sur ce serveur IRC pour échanger des noms d’utilisateur XMPP, des empreintes OTR et des informations de clé PGP, nous réduirions sérieusement les chances que ces organisations gouvernementales puissent nous attaquer. Comme elles sont incapables de déterminer activement comment nous communiquons (si nous faisons transiter toutes les connexions par Tor et des VPN), nous avons utilisé un peu d’obscurité à notre avantage.