APK Signature Scheme v3

Android 9 supporte APK rotation de la clé , ce qui donne des applications la possibilité de modifier la clé de leur signature dans le cadre d'une mise à jour de l' APK. Pour rendre la rotation pratique, les APK doivent indiquer les niveaux de confiance entre la nouvelle et l'ancienne clé de signature. Pour soutenir la rotation des clés, nous avons mis à jour le schéma de signature APK de v2 à v3 pour permettre aux nouvelles à utiliser les clés et les anciens. V3 ajoute des informations sur les versions SDK prises en charge et une structure de preuve de rotation au bloc de signature APK.

Note: APK rotation de la clé n'est pas recommandée avant la sortie d'Android 11. Les développeurs ont la possibilité d'utiliser la mise à niveau clé de Google Play pour les nouvelles installations. Les développeurs inscrits à Play App Signing peuvent demander une mise à niveau via la console Play.

Bloc de signature APK

Pour maintenir la compatibilité descendante avec le format APK v1, les signatures APK v2 et v3 sont stockées dans un bloc de signature APK, situé juste avant le répertoire central ZIP.

Le APK v3 signature le format bloc est le même que v2 . La signature v3 de l'APK est stockée sous la forme d'une paire ID-valeur avec l'ID 0xf05368c0.

APK Signature Scheme v3 Block

Le système v3 est conçu pour être très similaire au système v2 . Il a le même format général et prend en charge les mêmes ID d'algorithmes de signature , tailles clés et courbes CE.

Cependant, le schéma v3 ajoute des informations sur les versions SDK prises en charge et la structure de preuve de rotation.

Format

APK Signature Scheme v3 bloc est stocké dans la APK signature sous ID bloc 0xf05368c0 .

Le format du bloc APK Signature Scheme v3 suit celui de la v2 :

• séquence préfixée longueur de préfixe de longueur signer :
  • préfixé-longueur des signed data :
    • séquence préfixée longueur de préfixe de longueur digests :
      • signature algorithm ID (4 octets)
      • digest (-préfixée longueur)
    • séquence préfixée longueur de X.509 certificates :
      • X.509-préfixé longueur certificate (ASN.1 sous forme DER)
    • minSDK (uint32) - ce signataire doit être ignorée si la version de la plate - forme est inférieure à ce nombre.
    • maxSDK (uint32) - ce signataire doit être ignorée si la version de la plate - forme est au- dessus de ce nombre.
    • séquence préfixée longueur de préfixe de longueur additional attributes :
      • ID (uint32)
      • La value (de longueur variable: longueur de l'attribut supplémentaire - 4 octets)
      • ID - 0x3ba06f8c
      • La value - Preuve de rotation struct
  • minSDK (uint32) - en double de la valeur minSDK dans la section de données signé - utilisé pour ignorer la vérification de cette signature si la plate - forme actuelle est hors de portée. Doit correspondre à la valeur des données signées.
  • maxSDK (uint32) - en double de la valeur maxSDK dans la section de données signées - utilisées pour ignorer la vérification de cette signature si la plate - forme actuelle est hors de portée. Doit correspondre à la valeur des données signées.
  • séquence préfixée longueur de préfixe de longueur signatures :
    • signature algorithm ID (uint32)
    • longueur préfixée signature sur des signed data
  • préfixé longueur de public key (SubjectPublicKeyInfo, forme ASN.1 DER)

Structures de preuve de rotation et d'anciens certificats de confiance

La structure de preuve de rotation permet aux applications de faire pivoter leur certificat de signature sans être bloquées sur d'autres applications avec lesquelles elles communiquent. Pour ce faire, les signatures d'application contiennent deux nouvelles données :

• affirmation pour des tiers que le certificat de signature de l'application peut être approuvé partout où ses prédécesseurs sont approuvés
• les anciens certificats de signature de l'application auxquels l'application elle-même fait toujours confiance

L'attribut de preuve de rotation dans la section des données signées consiste en une liste à liaison unique, chaque nœud contenant un certificat de signature utilisé pour signer les versions précédentes de l'application. Cet attribut est censé contenir les structures de données conceptuelles de preuve de rotation et d'ancien certificat de confiance. La liste est triée par version avec le certificat de signature le plus ancien correspondant au nœud racine. La structure de données de preuve de rotation est construite en faisant signer le cert de chaque nœud au suivant de la liste, et en imprégnant ainsi chaque nouvelle clé de la preuve qu'elle doit être aussi fiable que la ou les anciennes clés.

La structure de données self-trusted-old-certs est construite en ajoutant des indicateurs à chaque nœud indiquant son appartenance et ses propriétés dans l'ensemble. Par exemple, un indicateur peut être présent indiquant que le certificat de signature à un nœud donné est approuvé pour l'obtention des autorisations de signature Android. Cet indicateur permet à d'autres applications signées par l'ancien certificat de se voir accorder une autorisation de signature définie par une application signée avec le nouveau certificat de signature. Parce que l'ensemble preuve de rotation réside d'attributs dans la section de données signée du v3 signer champ, il est protégé par la clé utilisée pour signer l'APK contenant.

Ce format exclut plusieurs clés de signature et la convergence des différents certificats de signature des ancêtres à un (plusieurs nœuds de départ à un puits commun).

Format

La preuve de rotation est stockée à l' intérieur du APK Signature Scheme v3 sous ID bloc 0x3ba06f8c . Son format est :

• séquence préfixée longueur de préfixe de longueur levels :
  • préfixé-longueur des signed data (par cert précédent - si elle existe)
    • X.509-préfixé longueur certificate (ASN.1 sous forme DER)
    • signature algorithm ID (uint32) - algorithme utilisé par cert dans le niveau précédent
  • flags (uint32) - drapeaux indiquant si oui ou non ce cert devrait être dans l'auto-vieux-confiance certs struct, et pour lesquels les opérations.
  • signature algorithm ID (uint32) - doit correspondre à celui de la section de données signé au niveau suivant.
  • préfixée longueur signature sur les dessus de signed data

Plusieurs certificats

Android traite actuellement un APK signé avec plusieurs certificats comme ayant une identité de signature unique distincte des certificats qui le composent. Ainsi, l'attribut de preuve de rotation dans la section des données signées forme un graphe acyclique dirigé, qui pourrait mieux être considéré comme une liste à liaison simple, chaque ensemble de signataires pour une version donnée représentant un nœud. Cela ajoute une complexité supplémentaire à la structure de preuve de rotation (version multi-signataire ci-dessous). En particulier, la commande devient une préoccupation. De plus, il n'est plus possible de signer les APK de manière indépendante, car la structure de preuve de rotation doit faire signer les anciens certificats de signature au nouvel ensemble de certificats, plutôt que de les signer un par un. Par exemple, un APK signé par la clé A qui souhaite être signé par deux nouvelles clés B et C ne pourrait pas faire en sorte que le signataire B inclue simplement une signature par A ou B, car il s'agit d'une identité de signature différente de celle de B et C. Ce serait signifie que les signataires doivent se coordonner avant de construire une telle structure.

Attribut de preuve de rotation à plusieurs signataires

• séquence préfixée longueur de préfixe de longueur des sets :
  • signed data (par précédents - si elle existe)
    • séquence préfixée longueur de certificates
      • X.509-préfixé longueur certificate (ASN.1 sous forme DER)
    • Séquence d' signature algorithm IDs (de uint32) - un pour chaque certificat de l'ensemble précédent, dans le même ordre.
  • flags (uint32) - drapeaux indiquant si oui ou non cet ensemble de certs devrait être dans l'auto-vieux-confiance certs struct, et pour lesquels les opérations.
  • séquence préfixée longueur de préfixe de longueur signatures :
    • signature algorithm ID (uint32) - doit correspondre à celui de la section de données signée
    • préfixée longueur signature sur les dessus de signed data

Ancêtres multiples dans la structure de preuve de rotation

Le schéma v3 ne gère pas non plus deux clés différentes tournant vers la même clé de signature pour la même application. Cela diffère du cas d'une acquisition, où la société acquéreuse souhaite déplacer l'application acquise pour utiliser sa clé de signature pour partager les autorisations. L'acquisition est considérée comme un cas d'utilisation pris en charge, car la nouvelle application se distinguerait par son nom de package et pourrait contenir sa propre structure de preuve de rotation. Le cas non pris en charge, de la même application ayant deux chemins différents pour accéder au même certificat, brise de nombreuses hypothèses formulées dans la conception de la rotation des clés.

Vérification

Dans Android 9 et versions ultérieures, les APK peuvent être vérifiés selon le schéma de signature APK v3, v2 ou v1. Les plates-formes plus anciennes ignorent les signatures v3 et essaient de vérifier les signatures v2, puis v1.

Figure 1. APK processus de vérification de signature

Vérification du schéma de signature APK v3

1. Localisez le bloc de signature APK et vérifiez que :
   1. Deux champs de taille d'APK Signing Block contiennent la même valeur.
   2. ZIP Central Directory est immédiatement suivi de l'enregistrement ZIP End of Central Directory.
   3. ZIP La fin du répertoire central n'est pas suivie de plus de données.
2. Localisez le premier bloc APK Signature Scheme v3 à l'intérieur du bloc de signature APK. Si le bloc v3 est présent, passez à l' étape 3. Dans le cas contraire, revenir à la vérification de l'APK en utilisant système v2 .
3. Pour chaque signer dans le APK Signature Scheme v3 bloc avec une min et la version max SDK qui est à portée de la plate - forme actuelle:
   1. Choisissez la prise en charge la plus forte signature algorithm ID l' signatures signature algorithm ID de signatures . L'ordre de force dépend de chaque version d'implémentation/plate-forme.
   2. Vérifiez la correspondante signature de signatures contre les signed data en utilisant la public key . (Il est maintenant sûr d'analyser des signed data .)
   3. Vérifier les min et les versions SDK max dans les données signées correspondent à celles spécifiées pour le signer .
   4. Vérifiez que la liste ordonnée des ID d'algorithme de signature dans les digests et signatures est identique. (Ceci est pour empêcher la suppression/l'ajout de signature.)
   5. Calculer le résumé du contenu APK en utilisant le même algorithme de hachage que l'algorithme de synthèse utilisé par l'algorithme de signature.
   6. Vérifiez que le digest calculé est identique au correspondant de digest de digests .
   7. Vérifiez que SubjectPublicKeyInfo du premier certificate de certificates est identique à public key .
   8. Si la preuve de rotation attribut existe pour le signer vérifier que le struct est valide et ce signer est le dernier certificat dans la liste.
4. La vérification réussit si exactement un signer a été trouvé dans la gamme de la plate - forme actuelle et l' étape 3 réussi pour ce signer .

Attention: APK ne doit pas être vérifiée à l' aide du système v1 ou v2 si une défaillance se produit à l' étape 3 ou 4.

Validation

Pour vérifier que votre appareil prend en charge v3 correctement, exécutez les PkgInstallSignatureVerificationTest.java de tests CTS en cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .