Signature d'applications Android : comment cela fonctionne et pourquoi c'est important

Chaque fois que vous installez une application sur votre téléphone Android, une vérification de sécurité silencieuse mais critique s'effectue en arrière-plan. Votre téléphone vérifie le signature numérique du package APK. Cette poignée de main cryptographique empêche les pirates malveillants d'« empoisonner » vos applications avec des logiciels malveillants tout en garantissant que les développeurs peuvent envoyer des mises à jour sans perdre leur identité.

Si vous écrivez des applications, la signature est quelque chose que vous devez simplement maîtriser ; si vous aimez simplement bricoler Android, c’est l’une des parties du système les plus satisfaisantes à comprendre. Quoi qu’il en soit, comment fonctionne la signature d'application vaut votre temps. Ci-dessous, nous passons en revue la technologie, comment les systèmes de signature ont évolué et comment vous pouvez vérifier manuellement les certificats en ligne.

Qu’est-ce que la signature d’application?

À la base, la signature d'application est un processus dans lequel un développeur utilise un Clé privée pour générer un bloc de signature pour les fichiers de son application. Le Clé publique correspondant est ensuite intégré dans l'APK dans le dossier META-INF. Lorsque votre téléphone tente d'installer l'application, il utilise la clé publique pour vérifier si la signature correspond au contenu du fichier.

Cela fournit deux propriétés principales :

1. Immutabilité: Si un seul octet du code de l'application est modifié (par exemple par un cheval de Troie), la signature ne correspondra plus au fichier et Android refusera de l'installer.
2. Preuve d'identité : Si une application tente de mettre à jour une application existante, leurs signatures doivent correspondre. C'est pourquoi vous ne pouvez pas installer une application Facebook falsifiée sur l'application officielle.

Évolution des schémas de signature

Google a continuellement mis à niveau le mécanisme de signature pour améliorer à la fois la vitesse et la sécurité :

• V1 (signature du pot) : Signe des fichiers individuels dans l'APK (ZIP). C'est lent car le système d'exploitation doit décompresser et vérifier chaque fichier. Il est également vulnérable à certaines manipulations ZIP.
• V2 (schéma de signature APK) : Signe l’intégralité du bloc binaire de l’APK. Il n'est pas nécessaire de le décompresser pour le vérifier, ce qui le rend incroyablement rapide. Il a été introduit dans Android 7.0 (Nougat).
• V3 (rotation des clés) : Étend la V2 en ajoutant une « lignée » de clés. Cela permet à un développeur de prouver qu'une nouvelle clé est le successeur autorisé d'une ancienne. Introduit dans Android 9.0 (Pie).
• V4 (signature en streaming) : Conçu spécifiquement pour les installations incrémentielles, permettant de vérifier les applications pendant qu'elles sont encore en cours de téléchargement via USB ou Wi-Fi.

Pourquoi les certificats sont importants pour le chargement latéral

Lorsque vous téléchargez un APK à partir d'une source non officielle, le Hachage de certificat est votre meilleur ami. Une empreinte digitale de certificat (telle qu'un hachage SHA-256) identifie de manière unique la clé de signature du développeur. Chaque application conserve la même clé de signature dans toutes ses mises à jour, vous pouvez donc comparer l'empreinte digitale d'un APK avec la valeur publiée par le développeur pour confirmer son authenticité.

Si vous pensez qu'un APK est faux, vous devez l'exécuter via notre Vérificateur APK en ligne. Notre outil vous montrera :

• Le Nom commun (CN) du signataire (par exemple, « Android »).
• Le Période de validité du certificat.
• Le Empreintes digitales SHA-1/SHA-256.

Comment Android vérifie une signature au moment de l'installation

L'étape « vérifier le certificat » est si souvent passée sous silence qu'il vaut la peine de découvrir ce que fait réellement le système d'exploitation lorsque vous appuyez sur un APK et qu'Android décide de l'installer :

1. Ouvrez l'APK sous forme de ZIP et localisez le bloc de signature. Pour les signatures v2/v3 qui est un bloc structuré juste avant le répertoire central ; pour le schéma v1 existant, il s'agit du contenu de META-INF/*.RSA, *.DSA ou *.EC.
2. Calculez les résumés SHA-256 de chaque autre octet de l'APK. Le bloc de signature est exclu de son propre résumé ; tout le reste est haché en morceaux définis.
3. Vérifiez le résumé de chaque morceau par rapport aux résumés enregistrés dans le bloc de signature. Si ne serait-ce qu'un seul octet a été modifié depuis que le développeur a signé le fichier, les résumés ne correspondront pas et l'installation est rejetée avec une erreur générique « Application non installée ».
4. Vérifiez que le bloc de signature lui-même a été produit avec la clé privée du certificat. La clé publique du certificat permet de vérifier la signature cryptographique dans le bloc. Une vérification réussie signifie que celui qui a signé le fichier possédait la clé privée associée à ce certificat.
5. Comparez l’empreinte digitale du certificat avec toute installation existante du même nom de package. Si le paquet est déjà installé et que le nouvel APK est signé avec un certificat différent, l'installation est rejetée avec l'erreur INSTALL_FAILED_UPDATE_INCOMPATIBLE. Il s'agit de la principale défense anti-usurpation d'identité du système d'exploitation : un acteur malveillant ne peut pas remplacer votre application bancaire par sa propre copie à moins qu'il n'ait également volé la clé de signature de la banque.

Rien de tout cela ne prouve que le développeur est digne de confiance, seulement que le fichier que vous êtes sur le point d'installer est identique en octets à celui qu'il a signé et qu'aucune autre partie ne l'a falsifié. La confiance dans le développeur est une décision distincte, que vous prenez en décidant des sources à partir desquelles vous installez.

Ce que signifie réellement « incompatibilité de signature »

La surprise la plus courante que les gens rencontrent lors du chargement latéral est l’erreur « incompatibilité de signature » ​​lors de la mise à jour. Voici ce qui se passe réellement :

• Vous avez installé Application X version 1.0 à partir du Play Store.
• Vous téléchargez Application X version 1.1 à partir d'une source autre que Play.
• Le système d'exploitation voit le même nom de package (com.example.app mais l'APK est signé avec un certificat différent (la clé de signature de la source secondaire, pas celle de l'éditeur d'origine)). Il refuse de s'installer.

Cela se produit de deux manières dans la pratique :

1. L'APK tiers est véritablement d'un autre éditeur, par exemple une copie « modifiée » ou « corrigée ». Refuser l’installation est le comportement correct ; l'installer signifierait confier à un inconnu les mêmes données que l'application de votre banque a déjà touchées.
2. L'APK tiers est un ré-upload de l'APK officiel, mais le système Play App Signing de Google signe le téléchargement de chaque utilisateur avec le wrapper clé de téléchargement de l'utilisateur. Deux appareils peuvent parfois voir des données de signature légèrement différentes pour la même version conceptuelle de l'application. Dans ce cas, l'empreinte digitale du certificat à la racine correspond toujours ; vous pouvez vérifier avec notre Vérificateur APK.

Si l'empreinte digitale du certificat vraiment diffère de votre installation existante, la seule solution consiste à désinstaller d'abord la copie actuelle (en perdant ses données) avant de charger le remplacement, sans jamais désactiver la vérification de la signature.

Générer votre propre clé de signature (pour les développeurs)

Si vous créez des applications Android, vous devrez éventuellement signer vos propres versions. La commande standard sur une ligne utilisant keytool à partir d'un SDK Java est :

keytool -genkeypair -v \
        -keystore my-release.keystore \
        -alias my-app -keyalg RSA -keysize 2048 \
        -validity 10000

Deux choses à savoir :

• Le validité est important : 10 000 jours (environ 27 ans) est la valeur conventionnelle car le système d'exploitation considère les mises à jour signées avec une clé presque expirée ou expirée comme compromises. Générez une fois une clé longue durée et protégez-la.
• Une fois publié, vous ne pouvez pas facilement changer de clé. Le schéma de signature v3 ajoute la clé rotation comme fonctionnalité explicite : un ancien certificat « bénit » un nouveau via une preuve stockée, permettant au système d'exploitation d'accepter les mises à jour de la nouvelle clé tout en préservant la continuité de l'identité. Sans la version 3, perdre la clé d'origine signifie rendre orphelines toutes les installations existantes.

Pour les versions de test chargées, un magasin de clés de débogage non signé convient ; pour la production, utilisez un magasin de clés à longue validité protégé par mot de passe et stocké dans une sauvegarde hors ligne.

Pièges courants en matière de signature

1. Certificats auto-signés : La plupart des applications Android sont auto-signées. Contrairement au SSL pour les sites Web, il n’existe pas d’autorité centrale pour la signature des applications Android. Vous devez faire confiance directement au développeur.
2. Certificats de débogage : Les applications conçues pour les tests utilisent une clé générique de « débogage ». Ces applications ne doivent jamais être rendues publiques et sont bloquées par de nombreux filtres de sécurité.
3. Perte de clé : Si un développeur perd son magasin de clés privées, il peut jamais mettre à jour à nouveau son application. Ils devraient publier une "nouvelle" application avec un nom de package différent.

Choisir le bon schéma de signature pour votre SDK cible

La signature d'applications sous-tend discrètement une grande partie de la sécurité d'Android. Une fois la relation clé privée/clé publique établie, vous pouvez juger une application téléchargée sur ses mérites et confirmer que ce que vous installez n'a pas été modifié depuis que le développeur l'a signé. Pour en savoir plus sur les composants internes d'Android, consultez notre guide du format XAPK.