Auditer les outils des défenseurs des droits humains : notre méthode

Une question revient souvent quand on audite une technologie sous pression : qu’est-ce qui différencie l’audit d’un outil utilisé par un défenseur des droits humains de l’audit d’un outil utilisé dans une banque ? Sur le plan technique, étonnamment peu de chose. Les protocoles d’authentification, les analyseurs et les choix cryptographiques sont la même mécanique que celle utilisée partout ailleurs.

Ce qui change, c’est le modèle de menace, et les enjeux.

Commencer par le modèle de menace

Pour les outils que nous auditions via le Security Lab de l’Open Technology Fund, l’adversaire est typiquement un acteur étatique puissant et tenace. L’utilisateur est souvent quelqu’un qui ne peut pas se permettre d’être détecté, encore moins compromis. Cette réalité transforme l’audit de façon concrète :

• La saisie de l’appareil est la référence. Nous partons du principe que l’appareil peut être physiquement confisqué. Chaque secret qu’une application stocke, ou ne stocke pas, doit se justifier face à cette possibilité.
• L’interception du réseau est le cas par défaut. Certificats implantés, DNS empoisonnés et portails captifs sont l’environnement réseau de départ, pas l’exception.
• La vie privée sous contrainte. L’application ne doit rien exposer qui puisse impliquer quelqu’un pour le simple fait de posséder l’outil.

Le cœur méthodologique

La méthode se résume à quelques questions simples, posées à chaque couche de la pile :

1. Quelles données touchent l’appareil, et qu’est-ce qui leur est autorisé ?
2. Un attaquant peut-il influer sur les chemins d’exécution sans aucun identifiant ?
3. Que se passe-t-il en cas d’erreur, et l’échec est-il du bon côté ?
4. Les promesses de la conception sont-elles vérifiées indépendamment ? Le chiffrement chiffre-t-il vraiment ? Le dossier « sécurisé » est-il accessible via une interface de débogage ?

Nous combinons la revue manuelle du code avec l’analyse dynamique, et nous classons chaque résultat contre une grille claire pour que les équipes puissent agir vite. Les résultats confidentiels et la classe intermédiaire sont livrés avec des étapes de reproduction et des suggestions de correction. Des résultats exploitables, pas des avertissements abstraits.

Les résultats sont le produit, pas une note

La sortie utile d’un audit n’est pas une note. C’est un ensemble de résultats qui permettent aux mainteneurs de faire évoluer leur logiciel en confiance. Concrètement :

• La reproductibilité d’abord. Chaque problème inclut les conditions exactes qui le déclenchent et celles qui vérifient le correctif.
• Un tri priorisé. Nous classons par exploitabilité réelle, pas par des scores CVSS, car les attaques réelles exploitées enchaînent les faiblesses.
• Une écriture orientée vers la correction. Les résultats désignent la décision de conception qui a permis le problème et proposent, quand c’est raisonnable, une remédiation concrète.

Pourquoi nous en publions une partie

Plusieurs de nos rapports d’audit sont publics, notamment Tella et NetAidKit, car la transparence élève le niveau pour tout un écosystème, pas seulement pour un vendeur. Un résultat public peut être étudié, vérifié et recoupé par n’importe quel chercheur. Se faire auditer est déjà un effort. Publier le rapport rend cet effort utile au-delà de votre projet.

Si votre projet sert des personnes confrontées à de réels adversaires et que vous voulez un travail de sécurité rigoureux et vérifiable, nous prenons des mandats. Le point de départ est notre page services.