Une somme de contrôle compare des octets à une référence. Une signature lie l’intégrité à une clé. Aucune ne prouve à elle seule que le logiciel est sûr.
Avant d’installer un APK Android, distinguez trois vérifications : Ce fichier correspond-il à la version publiée attendue ? A-t-il été signé avec la clé attendue ? Des tiers indépendants peuvent-ils le reproduire à partir du code source indiqué ? Une somme de contrôle SHA-256, une signature d’APK et une compilation reproductible répondent différemment à ces questions.
Aucune ne constitue à elle seule un verdict sur la présence de logiciels malveillants. Un programme correctement signé et reproductible peut tout de même contenir une faille de sécurité ou un comportement volontairement nuisible.
Ce que chaque méthode de vérification permet d’établir
| Vérification | Résultat utile | Limite importante |
|---|---|---|
| Empreinte SHA-256 du fichier | Vos octets correspondent à une empreinte de confiance donnée | Un attaquant qui remplace à la fois le fichier et l’empreinte peut contourner cette comparaison |
| Vérification de la signature de l’APK | La signature du paquet est vérifiée à l’aide de son certificat de signature | Vous devez déterminer quelle clé de signature est attendue ; la validité seule n’établit pas l’identité de l’éditeur |
| Comparaison de compilations reproductibles | L’artefact spécifié peut être recréé à partir d’entrées documentées | La correspondance entre le code source et le binaire ne prouve pas que le code source est sûr |
| Examen de sécurité | Des points précis de la conception ou de l’implémentation ont été évalués | Son périmètre, la version, les conclusions et les problèmes non résolus comptent |
Android exige la signature des APK pour l’installation et les mises à jour. Avec Play App Signing, Google peut gérer la clé de signature de l’application et générer les APK de distribution à partir d’un App Bundle. Il s’agit de modalités de confiance documentées, et non d’une preuve que n’importe quel intermédiaire peut modifier discrètement un paquet tout en préservant sa signature valide. Guide Android sur la signature des applications.
Étape 1 : identifier précisément l’artefact
Notez la version de l’application, le canal de distribution, le nom du fichier et la variante de plateforme visée. Utilisez la page officielle de distribution de l’éditeur, et non une somme de contrôle copiée dans le même message non sollicité que celui qui vous a fourni l’APK.
Un APK téléchargé directement auprès d’un éditeur peut différer d’un APK généré pour un appareil par une boutique d’applications. Des versions, architectures, modes d’empaquetage ou modalités de signature différents peuvent légitimement produire des empreintes de fichier différentes. Comparez des éléments équivalents avant de considérer une différence comme la preuve d’une altération.
La question pratique est la suivante : D’où vient la valeur attendue, et pourquoi ai-je confiance en cette source ? Calculer une empreinte hors ligne ne résout pas le problème de confiance posé par une empreinte de référence obtenue en ligne.
Étape 2 : calculer le SHA-256 localement
Remplacez messenger.apk par le nom de votre fichier téléchargé. Ces exemples lisent le fichier ; ils ne l’installent pas.
Linux :
sha256sum messenger.apk
macOS :
shasum -a 256 messenger.apk
Invite de commandes Windows :
certutil -hashfile messenger.apk SHA256
Comparez l’empreinte complète, en ignorant uniquement les espaces de présentation et les différences entre majuscules et minuscules. Ne comparez pas seulement les premiers ou les derniers caractères. Conservez l’empreinte attendue avec les informations relatives à la publication et à sa version pour pouvoir répéter la comparaison.
Si les valeurs diffèrent, arrêtez-vous avant l’installation. Vérifiez l’artefact et la version, téléchargez à nouveau le fichier depuis la source de confiance si cela convient, et interrogez l’éditeur si la différence reste inexpliquée. Ne « corrigez » pas la somme de contrôle attendue pour qu’elle corresponde au fichier que vous avez reçu.
Étape 3 : vérifier la signature de l’APK
Pour les utilisateurs des Android SDK Build Tools, la documentation d’apksigner de Google décrit la vérification des signatures et l’affichage des certificats :
apksigner verify --verbose --print-certs messenger.apk
La vérification doit réussir pour les plateformes prises en charge par l’APK. Comparez les informations de son certificat de signature à un relevé de publication de confiance ou à l’historique des clés de signature documenté par l’éditeur. Une signature créée avec une clé inconnue ne devient pas digne de confiance parce que le mot « vérifiée » s’affiche. Une rotation légitime de la clé de signature nécessite elle aussi des preuves, plutôt qu’une consigne demandant d’ignorer une différence.
L’empreinte SHA-256 du fichier APK et l’empreinte SHA-256 de son certificat de signature sont deux valeurs différentes. Ne comparez pas l’une à l’autre.
Étape 4 : rechercher des preuves de compilation reproductible
Pour affirmer qu’une compilation est reproductible, il faut définir une révision du code source, un environnement de compilation, des instructions et un artefact cible. Des tiers indépendants doivent pouvoir recréer cet artefact et comparer le résultat. La définition du projet Reproducible Builds intègre ces entrées à l’affirmation.
Pour une messagerie, les éléments utiles attestant d’une publication comprennent une étiquette de version du code source, des versions fixées des dépendances et de la chaîne d’outils, des instructions de compilation et des résultats de comparaisons indépendantes. Demandez ce qui a été comparé exactement : un artefact non signé, un APK signé ou certains contenus du paquet. Ne déduisez pas qu’une compilation est reproductible du seul fait que le code source et une empreinte du téléchargement sont publiés.
La reproductibilité renforce le lien entre le code source examiné et le code distribué. Elle ne transforme pas une implémentation non examinée en protocole sûr et ne prouve pas qu’un téléphone en cours de fonctionnement n’est pas compromis.
Quel est le rôle du Proof Lab de Livara ?
Le Proof Lab de Livara propose de calculer localement l’empreinte d’un APK et de la comparer à l’empreinte publiée. Ses démonstrations cryptographiques ont un périmètre plus restreint qu’un audit du protocole de messagerie complet. Utilisez la vérification d’empreinte pour son objectif déclaré, avec les informations sur la publication attendue et sa signature ; ne la considérez pas comme une preuve indépendante de compilations reproductibles ou d’absence de portes dérobées.
Le modèle de menace mentionne explicitement la limite qui existe lorsque l’APK et son empreinte affichée peuvent tous deux être remplacés. C’est pourquoi la provenance de votre valeur de référence compte autant que la bonne exécution du calcul.
Questions fréquentes
Une somme de contrôle identique prouve-t-elle qu’un APK est sûr ?
Non. Elle établit une correspondance avec l’empreinte de référence, à condition que cette référence soit digne de confiance et que les propriétés de sécurité de la fonction de hachage soient respectées. Elle n’évalue pas le comportement du programme.
La vérification de la signature est-elle redondante si la somme de contrôle correspond ?
Non. Ces vérifications apportent des éléments différents. Une signature lie l’intégrité du paquet à une clé ; une empreinte de fichier identifie une séquence précise d’octets.
Un téléchargement depuis une boutique doit-il correspondre à l’empreinte de l’APK du site web ?
Seulement s’ils sont censés être le même artefact. Vérifiez d’abord le canal de distribution, la version et l’empaquetage. Une différence inexpliquée mérite une investigation, pas une accusation automatique ni une approbation automatique.
Ces vérifications peuvent-elles détecter un logiciel espion déjà présent sur mon téléphone ?
Non. Elles évaluent un artefact d’installation, pas chaque composant de l’état d’exécution actuel de l’appareil.
