Une fois arrivé à ce niveau, vous devez presque réévaluer tout ce qui concerne votre modèle de menace et ce que vous faites pour vous protéger. Même les plus petites choses peuvent provoquer une tempête de problèmes si vous vous frottez aux mauvaises personnes. Dans la section précédente justement, nous expliquions à quel point le logiciel open source est une très, très bonne chose. Et maintenant, nous devons parler de certains de ses problèmes et de ce que vous pouvez faire pour les combattre et rester en sécurité.
Le FOSS est génial parce qu’il nous permet de regarder le code dans son intégralité et de vérifier que ce que nous voyons fait bien ce que l’on nous fait croire qu’il fait. Mais pour que cette affirmation soit vraie, nous devons tout comprendre du code publié. Moi, par exemple, je ne sais coder rien de plus qu’un simple site web en HTML, je dois donc me fier à la parole des autres. Cette parole ne vaut cependant que ce que valent les gens qui la vérifient. Disons donc que nous prévoyons d’utiliser ServiceX (juste à titre d’exemple) pour communiquer de façon sécurisée avec quelqu’un d’autre, mais que ServiceX publie des mises à jour assez régulièrement (tous les mois). À moins de savoir lire, comprendre et valider le code nous-mêmes, il nous faut une autre personne de confiance capable de le faire. De plus, cette personne doit le faire à chaque mise à jour publiée. Se pose alors la question de savoir si une seule personne compétente qui regarde le code suffit. Si cette personne rate quelque chose susceptible de nous compromettre, nous utiliserions ServiceX jusqu’au moment où quelqu’un d’autre repère ce défaut. Même si ce laps de temps n’est peut-être qu’une affaire de jours, ce sont des jours pendant lesquels tout ce que nous faisons en lien avec ce service est compromis, ce qui, par association, nous compromet, nous et tout notre modèle de sécurité, de confidentialité ET d’anonymat que nous avons eu tant de mal à bâtir.
Un autre problème du logiciel libre et open source, ce sont les plateformes mobiles. Sur la plupart des systèmes d’exploitation pour ordinateurs de bureau, nous pouvons prendre le code source sur GitHub (ou un autre site de publication de code) et le construire ou le compiler nous-mêmes s’il a été écrit pour fonctionner avec notre OS. Mais sur les systèmes d’exploitation mobiles, nous ne pouvons pas le faire facilement. Et même dans les cas où nous le pouvons, nous faisons face à un énorme défi qui n’a pas encore de solution magique. Pour télécharger une application sur mon iPhone, elle doit être publiée sur l’App Store par la société qui a développé ladite application. Je ne peux pas aller sur le site d’Open Whisper Systems et télécharger Signal directement sur mon téléphone. Donc même si nous vérifions le code source du service ou de l’application (ou si nous le faisons vérifier par quelqu’un d’autre), nous ne pouvons toujours pas valider que c’est bien la même application qui est envoyée à l’App Store pour que nous la téléchargions. Si la société était compromise par un service de police et forcée de coopérer, elle pourrait publier une mise à jour propre sur GitHub, avec de légers changements d’interface pour éviter les soupçons, puis envoyer une version de la même application avec une porte dérobée à l’App Store pour que des milliers d’utilisateurs la téléchargent. C’est vrai en un sens pour les appareils Android et le Google Play Store également. La seule façon de contourner cela avec le Google Play Store est de soumettre des compilations reproductibles que le public peut voir et utiliser. Open Whisper Systems vient de déployer cela pour Signal et il serait vraiment agréable de voir d’autres services faire de même (petit clin d’œil : ProtonMail, Tutanota, ChatSecure) https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds. Donc, puisque nous ne pouvons pas vérifier facilement que l’application que nous utilisons sur nos téléphones ne fait pas de choses malveillantes, il devrait être raisonnable de supposer qu’abandonner les appareils mobiles et utiliser strictement les versions bureau des programmes, celles que nous pouvons compiler depuis les sources et surveiller nous-mêmes, est la meilleure voie à suivre.
Audits de code pour les outils de confidentialité
Même après avoir lu tout ce qui précède sur le logiciel open source, il reste un énorme problème à franchir avant de pouvoir être certain que le logiciel que nous utilisons est sûr. Il n’est pas juste de supposer que 100 % des gens qui lisent cette section vont pouvoir vérifier eux-mêmes le code d’une application. Bon sang, il n’est même pas juste de supposer que 5 % des gens qui lisent ceci pourraient accomplir une tâche aussi intimidante. Prenez TrueCrypt par exemple. Les audits de code réalisés pour s’assurer qu’il était sûr ont pris des mois, menés par des gens qui ont des années-lumière d’avance sur moi dans le domaine du chiffrement ; certains d’entre eux titulaires d’un master dans le domaine, avec des années d’expérience au compteur (hum, hum @matthew_d_green). Alors supposer qu’un individu seul peut faire ce genre de choses pour assurer sa propre sécurité est absurde. Les audits de code sur les applications et services auxquels nous confions notre sécurité à ce niveau sont cruciaux. Et une fois cet audit de code terminé, il faut ensuite considérer que l’audit ne sera pas valable pour les versions ultérieures de l’application. À la seconde où ils envoient une mise à jour et où vous l’installez, vous êtes revenu à la case départ, à moins que quelqu’un ne regarde les changements et ne les vérifie à chaque mise à jour.
Voir : L’importance du logiciel libre et open source pour les outils de confidentialité