Android 13 est compatible avec APK Signature Scheme v3.1, une amélioration de l'APK Signature Scheme v3 existant. Le schéma v3.1 résout certains problèmes connus du schéma de signature APK v3 concernant la rotation. En particulier, le schéma de signature v3.1 est compatible avec le ciblage de la version du SDK, ce qui permet à la rotation de cibler une version ultérieure de la plate-forme.
Le schéma de signature v3.1 utilise un ID de bloc qui n'est pas reconnu sur Android 12 ou version antérieure. Par conséquent, la plate-forme applique le comportement suivant au signataire :
- Les appareils équipés d'Android 13 ou version ultérieure utilisent le signataire ayant fait l'objet d'une rotation dans le bloc v3.1.
- Les appareils exécutant d'anciennes versions d'Android ignorent le signataire ayant fait l'objet d'une rotation et utilisent à la place le signataire d'origine dans le bloc v3.
Les applications qui n'ont pas encore modifié leur clé de signature ne nécessitent aucune action supplémentaire. Chaque fois que ces applications choisissent de faire une rotation, le système applique le schéma de signature v3.1 par défaut.
Bloc de signature v3.1
Le bloc de signature v3.1 a le même contenu que le bloc de signature v3, mais avec le nouvel ID de bloc, ces signatures ne sont reconnues que sur les appareils exécutant Android 13 ou version ultérieure. Cela permet aux applications d'effectuer une rotation de leurs clés de signature en toute sécurité, sans avoir à se soucier des APK multicibles, car le signataire d'origine peut être utilisé pour signer l'APK dans le bloc de signature v3 et le signataire ayant effectué la rotation dans le bloc de signature v3.1. Cela permet également à la plate-forme de réutiliser tous les codes de validation existants pour le bloc de signature v3 lors de la validation d'une signature v3.1.
Par défaut, la bibliothèque apksig utilise le bloc de signature v3.1 chaque fois qu'une clé et une traçabilité ayant subi une rotation sont fournies dans la configuration de signature. Si le minSdkVersion d'une application est inférieur à Android 12 et qu'une clé ayant fait l'objet d'une rotation est utilisée, la clé de signature d'origine doit également être spécifiée afin de pouvoir être utilisée pour signer l'APK dans le bloc de signature v3. Cela ressemble au comportement actuel, où le signataire d'origine est requis si l'APK cible une version antérieure à Android 9.
Pour prendre en charge la rotation des clés cibles à partir d'une version spécifique du SDK, la bibliothèque apksig expose de nouvelles API qui permettent de définir une version minimale du SDK pour la rotation. Si une version du SDK antérieure à Android 12 est spécifiée comme version minimale pour la prise en charge de la rotation, le bloc v3 d'origine est utilisé. Le bloc de signature v3.1 n'est utilisé qu'en cas de rotation, lorsque la version minimale du SDK pour la rotation est définie sur Android 12 ou version ultérieure. Le bloc de signature v3 comporte un attribut pour la protection contre la suppression de la version minimale du SDK de rotation.
| L'APK inclut la lignée | Valeur de rotation-min-sdk-version | Bloc de signature v3 | Bloc de signature v3.1 |
|---|---|---|---|
| Non | Valeur par défaut ou toute autre valeur (représentée par x ci-dessous) | Signée par le signataire d'origine, ciblant Android 9 et versions ultérieures | Non présent |
| Oui | Par défaut | Signé avec le signataire d'origine, ciblant Android 9 à 12L | Signé avec un signataire ayant fait l'objet d'une rotation, ciblant Android 12 et versions ultérieures |
| Oui | x < 33 (Android 13) | Signé avec un signataire ayant fait l'objet d'une rotation, ciblant Android 9 et versions ultérieures | Non présent |
| Oui | x >= 33 (Android 13) | Signé avec le signataire d'origine, ciblant Android 9 – (x-1) | Signé avec un signataire ayant fait l'objet d'une rotation, ciblant x+ |
Problèmes liés à la rotation
Les problèmes de rotation suivants ont été résolus dans la plate-forme :
Correctifs Android 12
- La plate-forme n'accorderait une autorisation de signature à une application à l'origine de la demande que si le signataire actuel de l'une ou l'autre des applications figure dans la lignée de signature ou est le signataire actuel de l'autre application. Cela empêche l'octroi d'une autorisation de signature à une application à l'origine de la demande si les deux applications suivent les bonnes pratiques concernant les clés de signature et passent à différentes clés de signature.
- La fonctionnalité de rollback d'APK de la plate-forme ne pouvait pas effectuer de rollback d'un APK dont la clé de signature venait d'être modifiée, sauf si la clé précédente de la lignée de signature avait la capacité de rollback. Toutefois, cette capacité va à l'encontre de l'objectif de la rotation, car elle permet de signer une nouvelle mise à jour du package avec la clé de signature précédente et d'effectuer un rollback de la clé modifiée.
- Un APK signé uniquement avec la clé ayant fait l'objet d'une rotation, puis mis à jour avec un APK signé avec la clé d'origine et la clé ayant fait l'objet d'une rotation dans la lignée, n'affiche que la clé ayant fait l'objet d'une rotation dans la lignée sur les appareils exécutant Android 11 ou une version antérieure.
Correctifs Android 11
PackageManager#checkSignaturesn'a pas été correctement mis à jour pour vérifier les clés de signature d'origine de deux packages. Cela a interrompu l'instrumentation pour les applications utilisant une clé de signature modifiée avec l'APK d'instrumentation utilisant la clé de signature d'origine.- Les packages d'un
sharedUserIdpartagent leur lignée de signature. Chaque fois qu'une application dont la chaîne de signature a été mise à jour est installée ou mise à jour dans unsharedUiserId, la chaîne de cette application remplace la chaîne partagée pour lesharedUserId(c'est-à-dire que si la chaîne de signature d'une application était A > B et qu'une application est mise à jour dans lesharedUserIdavec la chaîne B > C, la chaîne dusharedUserIdest remplacée par B > C). De même, les capacités d'un signataire précédent dans la lignée ne pouvaient pas être mises à jour, sauf si la lignée de signature était modifiée.
Intégration de la version 4
Le schéma de signature v4 utilise la configuration de signature fournie à apksigner. Dans le cas de plusieurs configurations de signature fournies pour la rotation, la dernière configuration de signature utilisée est celle qui a été modifiée. Avant l'introduction de la version 3.1, la version 3 n'incluait que la dernière configuration de signature modifiée. La version 4 pouvait donc utiliser cette configuration telle quelle. Grâce à cela, le schéma de signature v4 pouvait prendre en charge la rotation, car il utilisait la clé de signature modifiée dans son SigningInfo. Bien que SigningInfo v4 n'inclue pas l'intégralité de la lignée de signature, il est en mesure de l'extraire du bloc de signature v3 pour permettre à la plate-forme d'accéder à la lignée pour toutes les requêtes de signature. Lorsque la version 3.1 est utilisée pour cibler la rotation pour la rotation-min-sdk-version fournie, la configuration générique v3 inclut à la fois la configuration de signature d'origine et la dernière configuration de signature permutée. Une extension du schéma de signature v4 a été créée. Elle inclut des blocs d'informations de signature supplémentaires pour chacune des configurations de signature du bloc v3.1.
Validation
Pour tester votre implémentation de la version 3.1, exécutez les tests CTS PkgInstallSignatureVerificationTest.java dans cts/hostsidetests/appsecurity/src/android/appsecurity/cts/.
Pour en savoir plus sur les tests, consultez la section Validation de la version 3.