L’analyse côté client examine le contenu sur l’appareil de l’utilisateur, où il peut déjà être lisible avant l’envoi ou après la réception. Elle peut donc créer une voie de divulgation en dehors du canal de transmission chiffré. Comparer la somme de contrôle d’un APK ne prouve pas qu’une application ne contient aucun code d’analyse. Cela répond à une question plus restreinte : les octets sélectionnés correspondent-ils à une empreinte donnée ?
Distinguer ces affirmations rend le chiffrement comme la vérification des logiciels plus utiles.
Pourquoi l’analyse sur l’appareil modifie la frontière de confidentialité
Une application doit manipuler du texte en clair pour afficher un message ou préparer une photo à l’envoi. Une fonction d’analyse peut intervenir à ce moment-là, même si le message ensuite transmis sur le réseau est chiffré de bout en bout. Ce qui quitte l’appareil dépend de la conception de l’analyseur : il pourrait signaler une correspondance, téléverser du contenu sélectionné ou envoyer d’autres informations dérivées.
L’article de recherche Bugs in our Pockets examine notamment les risques d’abus, de faux positifs et d’augmentation de la surface d’attaque. Ce sont des raisons d’examiner les flux de données et la gouvernance d’un système d’analyse proposé. Elles ne démontrent pas que toute fonction exécutée sur l’appareil relève de la surveillance, ni qu’une loi particulière a imposé une obligation universelle d’analyse.
Une fonction locale contrôlée par l’utilisateur n’équivaut pas automatiquement à un signalement obligatoire. Demandez qui choisit l’analyse, ce qui la déclenche, qui peut mettre à jour ses règles et quelles données peuvent quitter l’appareil.
Quatre formes distinctes de preuves concernant un logiciel
| Vérification | Ce qu’elle peut établir | Ce qu’elle ne peut pas établir seule |
|---|---|---|
| Somme de contrôle SHA-256 | Le fichier correspond à une empreinte de référence fiable | Que le programme de référence est sûr ou correspond au code source |
| Vérification de signature APK | La signature du paquet est vérifiée et identifie un certificat de signature | Que le signataire est digne de confiance ou que le code n’a aucun comportement indésirable |
| Compilation reproductible | Le code source et les entrées de compilation spécifiés peuvent produire les artefacts attendus | Que le code source est exempt de vulnérabilités ou de logique nuisible |
| Examen et tests indépendants | Des constatations sur une version et un périmètre définis | Une garantie permanente couvrant toutes les mises à jour futures |
La documentation d’apksigner d’Android explique la vérification des paquets et l’affichage des informations de certificat. La définition de Reproducible Builds explique pourquoi le code source, l’environnement de compilation et les instructions comptent tous pour reproduire un artefact.
Une archive de code source et une somme de contrôle affichée à côté ne constituent pas, à elles seules, un résultat de compilation reproductible. De même, une signature valide sur une version malveillante reste une signature valide.
Vérifier un téléchargement sans surinterpréter le résultat
Identifiez d’abord la version souhaitée et obtenez son APK et l’empreinte attendue par une voie de distribution fiable. Calculez l’empreinte localement. Si elle diffère, n’installez pas le fichier tant que l’écart reste inexpliqué : une autre version, un téléchargement incomplet ou une altération peuvent tous produire une différence.
Si elle correspond, consignez la version et le résultat. Vous avez établi l’égalité des octets avec cette référence, et non l’absence d’analyse côté client. Si le même attaquant peut remplacer le téléchargement et la somme de contrôle affichée, la comparaison peut tout de même réussir. Des références indépendantes, la continuité de la clé de signature et la transparence des versions contribuent à traiter différentes parties de ce problème de confiance.
Pour une affirmation de correspondance entre source et binaire, recherchez des instructions de compilation documentées et des résultats reproduits indépendamment pour la version concernée. Ne déduisez pas cette propriété des mots « open source ».
Les mises à jour restent importantes
La distribution des logiciels peut être attaquée, mais éviter indéfiniment les mises à jour de sécurité n’est pas une bonne défense générale. Les mises à jour corrigent aussi des vulnérabilités exploitables. Utilisez un canal de mise à jour fiable, examinez les avis de sécurité pertinents et vérifiez les éléments de preuve des versions lorsque votre niveau de risque le justifie. Une ancienne version présentant une faille connue n’est pas plus sûre simplement parce que sa somme de contrôle a un jour correspondu.
Ce qu’établit le Proof Lab de Livara
Le Proof Lab de Livara propose une comparaison locale de l’empreinte d’un APK et des démonstrations cryptographiques dans le navigateur. La page indique qu’elle n’exécute pas les mécanismes de ratchet complets de LVR1/LGS1 et ne constitue pas un audit du protocole. Son modèle de menace explique aussi la limite lorsqu’un attaquant peut remplacer à la fois un fichier et son empreinte attendue.
Ces vérifications sont utiles dans leur périmètre. Elles ne prouvent pas qu’un téléphone sur lequel l’application est installée est exempt de logiciels malveillants, que Livara dispose de versions reproductibles indépendamment ou que son application ne peut pas contenir de comportements non divulgués. Consultez séparément la documentation de sécurité pour connaître les frontières de protection des messages revendiquées.
La bonne question n’est pas de savoir si un badge indique « vérifié ». C’est de savoir quelle affirmation a été testée, par rapport à quelle référence fiable et pour quelle version précise.
