Empreintes, signatures, builds reproductibles et audits répondent à des questions différentes.
Le code ouvert permet d’examiner le code ; il ne prouve toutefois pas à lui seul que l’application installée correspond à ce code ni qu’elle est dépourvue de vulnérabilités. Pour évaluer une messagerie, mieux vaut distinguer plusieurs types de preuves : code source, processus de compilation, signature du fichier, tests du protocole et rapport d’audit.
Que montre exactement chaque preuve ?
| Preuve | Apport principal | Ce qu’elle ne prouve pas à elle seule |
|---|---|---|
| Code source lisible | Permet d’examiner la conception et l’implémentation | La correspondance avec le fichier d’installation ou l’absence de tous les bugs |
| Build reproductible | Permet de comparer le résultat obtenu à partir d’une source et d’un environnement définis | La sécurité du code lui-même |
| Signature d’APK | Vérifie la signature et le lien du fichier avec une clé de signature de confiance | Le caractère inoffensif du comportement de l’application |
| Empreinte SHA-256 | Détecte les différences d’octets par rapport à un condensat de confiance | L’authenticité si un attaquant a remplacé le fichier et le condensat ensemble |
| Vecteur de test | Vérifie un comportement donné pour des entrées et sorties déterminées | La couverture de tous les états et chemins d’exécution |
| Audit indépendant | Résultats de l’examen d’un périmètre et d’une version définis | Une garantie permanente pour toutes les versions futures |
Un build reproductible n’est pas un téléchargement dont l’empreinte correspond
Selon la définition de Reproducible Builds, la reproductibilité consiste à produire un résultat identique à partir d’un code source, d’un environnement et d’instructions définis. Si vous comparez seulement le fichier téléchargé à l’empreinte publiée par son développeur, vous avez effectué un contrôle d’intégrité ; vous n’avez pas encore compilé vous-même le fichier à partir du code.
Pour évaluer une affirmation de reproductibilité, demandez la version du code, les dépendances, les instructions de compilation et le rapport d’une autre personne ayant reproduit le résultat. La phrase « le code source est sur GitHub » ne remplace pas ces preuves.
Comment interpréter correctement la vérification d’un APK ?
- Obtenez le fichier depuis la source officielle et pour une version précise.
- Obtenez le condensat et les informations sur le signataire auprès d’une source dont vous jugez l’authenticité fiable.
- Calculez l’empreinte du fichier et comparez-la à celle de la même version.
- Lors d’une vérification technique, validez aussi la signature ; l’outil officiel apksigner le permet.
- En cas de différence, interrompez l’installation et clarifiez la cause ; ne signez pas de nouveau le fichier pour contourner l’erreur.
Exemple de commande de vérification pour une personne experte disposant des Android SDK Build Tools :
apksigner verify --verbose --print-certs app.apk
Le nom app.apk n’est qu’un exemple. La réussite de la commande ne dispense pas de connaître la clé de confiance de l’éditeur.
Quel rôle joue Proof Lab ?
Le Proof Lab de Livara fournit des outils pour des vérifications précises. Lisez le périmètre de chaque test : empreinte de fichier, exemple d’accord de clé et rejet de données altérées répondent à des questions différentes. Une démonstration cryptographique réussie n’est pas un audit de l’ensemble de l’application installée, du serveur, des mises à jour ou de la gestion des comptes.
Le modèle de menace de Livara précise aussi que, si un attaquant remplace à la fois le fichier APK et le condensat affiché, une empreinte correspondante ne prouve pas à elle seule l’authenticité. Il s’agit d’une limite générale de la vérification des empreintes, et non d’une caractéristique propre à une messagerie.
Que demander à la lecture d’un rapport d’audit ?
- Quels organismes ou quelles personnes ont réalisé l’examen, et où se trouve le rapport public ?
- Quelle version et quel commit ont été examinés ?
- Quelles parties étaient hors périmètre ?
- Comment les constats importants ont-ils été corrigés et testés de nouveau ?
- Votre version installée est-elle la même ou contient-elle ces corrections ?
Ne tirez pas de conclusion définitive de mots comme « approuvé » sans réponse à ces questions. L’emploi d’un algorithme standardisé n’équivaut pas non plus à la certification de l’ensemble du produit selon une norme.
Conséquences pour le choix d’une messagerie
Le code ouvert et la vérifiabilité ne sont pas concurrents ; ce sont des preuves complémentaires. Préférez un produit aux affirmations précises, traçables et clairement délimitées. Étendez ensuite le même examen à votre usage particulier, par exemple les groupes, la version web, les sauvegardes et les appareils associés, au lieu de déduire une sécurité absolue d’un seul test réussi.
