APK Signature Scheme v3.1

Aperçu

Android 13 prend en charge le schéma de signature APK v3.1, une amélioration par rapport au schéma de signature APK v3 existant. Le schéma v3.1 résout certains des problèmes connus du schéma de signature APK v3 concernant la rotation. En particulier, le schéma de signature v3.1 prend en charge le ciblage des versions du SDK, ce qui permet une rotation pour cibler une version ultérieure de la plateforme.

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 plateforme applique le comportement de signataire suivant :

• Les appareils qui exécutent Android 13 ou version ultérieure utilisent le signataire pivoté dans le bloc v3.1.
• Les appareils qui exécutent des versions antérieures d'Android ignorent le signataire pivoté et utilisent à la place le signataire d'origine dans le bloc v3.

Les applications qui n’ont pas encore changé leur clé de signature ne nécessitent aucune action supplémentaire. Chaque fois que ces applications choisissent d'effectuer une rotation, le système applique par défaut le schéma de signature v3.1.

bloc de signature v3.1

Le bloc de signature v3.1 aura le même contenu que le bloc de signature v3, mais avec le nouvel ID de bloc, ces signatures ne seront reconnues que sur les appareils exécutant Android 13 et versions ultérieures. Cela permet aux applications de faire pivoter leurs clés de signature en toute sécurité sans avoir à se soucier des APK multi-cibles, car le signataire d'origine peut être utilisé pour signer l'APK dans le bloc de signature v3 et le signataire pivoté dans le bloc de signature v3.1. Cela permet également à la plateforme de réutiliser tous les codes de vérification existants pour le bloc de signature v3 lors de la vérification d'une signature v3.1.

Par défaut, la bibliothèque apksig utilisera le bloc de signature v3.1 chaque fois qu'une clé et un lignage pivotés sont fournis dans la configuration de signature. Si minSdkVersion d'une application est inférieure à Android 13 et qu'une clé pivotée est utilisée, la clé de signature d'origine doit également être spécifiée afin qu'elle puisse être utilisée pour signer l'APK dans le bloc de signature v3. Ceci est similaire au comportement actuel où le signataire d'origine est requis si l'APK cible une version antérieure à Android 9.

Pour prendre en charge le ciblage de la rotation des clés à partir d'une version particulière du SDK, la bibliothèque apksig exposera de nouvelles API qui permettront de définir une version minimale du SDK pour la rotation. Si une version du SDK inférieure à Android 13 est spécifiée comme version minimale pour la prise en charge de la rotation, alors la v3 d'origine Le bloc sera utilisé. Le bloc de signature v3.1 n'est utilisé qu'en présence de rotation où la version minimale du SDK pour la rotation est définie sur Android 13 et versions ultérieures. Le bloc de signature v3 aura un nouvel attribut pour la protection contre la suppression de la version minimale du SDK en rotation.

L'APK inclut la lignée	Valeur de rotation-min-sdk-version	bloc de signature v3	bloc de signature v3.1
Non	Par défaut ou n’importe quelle valeur (représentée par x ci-dessous)	Signé avec le signataire original, ciblant Android 9 et versions ultérieures	Pas présent
Oui	Défaut	Signé avec le signataire original, ciblant Android 9 à 12L	Signé avec un signataire pivoté, ciblant Android 13 et versions ultérieures
Oui	x < 33 (Android 13)	Signé avec un signataire pivoté, ciblant Android 9 et versions ultérieures	Pas présent
Oui	x >= 33 (Android 13)	Signé avec le signataire d'origine, ciblant Android 9 - ( x -1)	Signé avec le signataire pivoté, ciblant x+

Problèmes liés à la rotation

Les problèmes suivants liés à la rotation ont été résolus dans la plateforme :

Correctifs d'Android 12

• La plate-forme n'accorderait une autorisation de signature à une application requérante que si le signataire actuel de l'une ou l'autre des applications fait partie de la lignée de signature ou est le signataire actuel de l'autre application ; cela empêche d'accorder une autorisation de signature à une application demandeuse si les deux applications suivent les meilleures pratiques en matière de clé de signature et utilisent des clés de signature différentes.
• La fonctionnalité de restauration d'APK de la plate-forme ne pouvait pas restaurer un APK dont la clé de signature venait d'être pivotée, à moins que la clé précédente de la lignée de signature n'ait la capacité de restauration, mais cette fonctionnalité va à l'encontre de l'objectif de la rotation car elle permet à une nouvelle mise à jour de package d'être signée par le clé de signature précédente et restauration de la clé pivotée.
• Un APK signé avec uniquement la clé pivotée et mis à jour ultérieurement avec un APK signé avec la clé d'origine et la clé pivotée dans la lignée n'affichera que la clé pivotée dans la lignée sur les appareils exécutant Android 11 et versions antérieures.

Correctifs d'Android 11

• PackageManager#checkSignatures n'a pas été correctement mis à jour pour vérifier les clés de signature d'origine de deux packages. Cela a cassé l'instrumentation pour les applications utilisant une clé de signature pivotée avec l'APK d'instrumentation utilisant la clé de signature d'origine.
• Les packages sous un sharedUserId partagent leur lignée de signature. Chaque fois qu'une application avec une lignée de signature mise à jour est installée ou mise à jour dans un sharedUiserId , la lignée de cette application remplace la lignée partagée pour le sharedUserId (c'est-à-dire si la lignée de signature d'une application était A -> B et qu'une application est mise à jour dans le sharedUserId avec la lignée B -> C, alors la lignée sharedUserId serait 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 à moins que la lignée de signature ne soit modifiée.

Recommandé : il est recommandé, dans le cadre des bonnes pratiques, d'effectuer une rotation de la clé de signature de votre application au moins tous les deux ans.

intégration v4

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 pivotée est utilisée. Avant l'introduction de la version 3.1, la version 3 incluait uniquement cette dernière configuration de signature en rotation, la version 4 pouvait donc utiliser cette configuration telle quelle ; avec cela, le schéma de signature v4 était capable de prendre en charge la rotation puisqu'il utilisait la clé de signature pivotée dans son SigningInfo. Bien que SigningInfo v4 n'inclue pas la lignée de signature complète, il est capable de l'extraire du bloc de signature v3 pour permettre à la plate-forme d'accéder à la lignée pour toute requête de signature. Lorsque la version 3.1 est utilisée pour cibler la rotation pour la version rotation-min-sdk fournie, la configuration générique v3 inclura à la fois la configuration de signature d'origine ainsi que la dernière configuration de signature pivotée. Une extension du schéma de signature v4 a été créée et 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 plus d'informations sur les tests, consultez la section de vérification dans la v3.