Cette page a été traduite par l'API Cloud Translation.

Schéma de signature APK v3

Android 9 prend en charge la rotation des clés APK , ce qui donne aux applications la possibilité de modifier leur clé de 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 prendre en charge la rotation des clés, nous avons mis à jour le schéma de signature APK de la v2 à la v3 pour permettre l'utilisation des nouvelles et anciennes clés. La V3 ajoute des informations sur les versions du SDK prises en charge et une structure de preuve de rotation au bloc de signature APK.

Bloc de signature APK

Pour maintenir la compatibilité ascendante 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 format du bloc de signature APK v3 est le même que celui de la v2 . La signature v3 de l'APK est stockée sous forme de paire ID-valeur avec l'ID 0xf05368c0.

Blocage du schéma de signature APK v3

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

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

Format

Le bloc APK Signature Scheme v3 est stocké dans le bloc de signature APK sous l’ID 0xf05368c0 .

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

séquence de signer avec préfixe de longueur :
- signed data avec préfixe de longueur :
  - séquence de digests avec préfixe de longueur :
    - signature algorithm ID (4 octets)
    - digest (avec préfixe de longueur)
  - séquence de certificates X.509 avec préfixe de longueur :
    - certificate X.509 avec préfixe de longueur (formulaire ASN.1 DER)
  - minSDK (uint32) - ce signataire doit être ignoré si la version de la plateforme est inférieure à ce numéro.
  - maxSDK (uint32) - ce signataire doit être ignoré si la version de la plateforme est supérieure à ce numéro.
  - séquence d' additional attributes préfixés par la longueur :
    - ID (uint32)
    - value (longueur variable : longueur de l'attribut supplémentaire - 4 octets)
    - ID - 0x3ba06f8c
    - value - Structure de preuve de rotation
- minSDK (uint32) - duplicata de la valeur minSDK dans la section des données signées - utilisé pour ignorer la vérification de cette signature si la plate-forme actuelle n'est pas à portée. Doit correspondre à la valeur des données signées.
- maxSDK (uint32) - duplicata de la valeur maxSDK dans la section des données signées - utilisé pour ignorer la vérification de cette signature si la plate-forme actuelle n'est pas à portée. Doit correspondre à la valeur des données signées.
- séquence de signatures avec préfixe de longueur :
  - signature algorithm ID (uint32)
  - signature avec préfixe de longueur sur signed data
- public key avec préfixe de longueur (SubjectPublicKeyInfo, formulaire ASN.1 DER)

Preuve de rotation et structures de certificats anciens fiables

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

affirmation pour les tiers selon laquelle le certificat de signature de l'application peut être fiable là où ses prédécesseurs sont dignes de confiance
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 à lien 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'anciens certificats de confiance. La liste est classé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 en sorte que le certificat de chaque nœud signe le suivant dans 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 des anciens certificats de confiance 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 sur un nœud donné est approuvé pour obtenir les autorisations de signature Android. Cet indicateur permet aux autres applications signées par l'ancien certificat de toujours bénéficier d'une autorisation de signature définie par une application signée avec le nouveau certificat de signature. Étant donné que l'ensemble de l'attribut de preuve de rotation réside dans la section de données signées du champ signer v3, 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 de différents certificats de signature d'ancêtres en un seul (plusieurs nœuds de départ vers un récepteur commun).

Format

La preuve de rotation est stockée dans le bloc APK Signature Scheme v3 sous l'ID 0x3ba06f8c . Son format est :

séquence de levels préfixés en longueur :
- signed data avec préfixe de longueur (par certificat précédent - si elles existent)
  - certificate X.509 avec préfixe de longueur (formulaire ASN.1 DER)
  - signature algorithm ID (uint32) - algorithme utilisé par le certificat au niveau précédent
- flags (uint32) - indicateurs indiquant si ce certificat doit ou non être dans la structure self-trusted-old-certs et pour quelles opérations.
- signature algorithm ID (uint32) - doit correspondre à celui de la section de données signées du niveau suivant.
- signature avec préfixe de longueur sur les signed data ci-dessus

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 de données signées forme un graphe acyclique orienté, qui pourrait mieux être considéré comme une liste à lien unique, 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 des APK indépendamment, car la structure de preuve de rotation doit faire en sorte que les anciens certificats de signature signent le 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 demander au signataire B d'inclure simplement une signature par A ou B, car il s'agit d'une identité de signature différente de celle de B et C. Cela entraînerait signifie que les signataires doivent se coordonner avant de construire une telle structure.

Attribut de preuve de rotation de plusieurs signataires

séquence d' sets préfixés par longueur :
- signed data (par ensemble précédent - si elles existent)
  - séquence de certificates avec préfixe de longueur
    - certificate X.509 avec préfixe de longueur (formulaire ASN.1 DER)
  - Séquence d' signature algorithm IDs (uint32) : un pour chaque certificat de l'ensemble précédent, dans le même ordre.
- flags (uint32) - indicateurs indiquant si cet ensemble de certificats doit ou non être dans la structure self-trusted-old-certs, et pour quelles opérations.
- séquence de signatures avec préfixe de longueur :
  - signature algorithm ID (uint32) - doit correspondre à celui de la section de données signées
  - signature avec préfixe de longueur sur les signed data ci-dessus

Plusieurs ancêtres 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 afin d’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, dans lequel la même application dispose de 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

Sous 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 anciennes plates-formes ignorent les signatures v3 et tentent de vérifier les signatures v2, puis v1.

Processus de vérification de la signature APK

Figure 1. Processus de vérification de la signature APK

Vérification du schéma de signature APK v3

Localisez le bloc de signature APK et vérifiez que :
1. Deux champs de taille du bloc de signature APK contiennent la même valeur.
2. Le répertoire central ZIP est immédiatement suivi de l'enregistrement ZIP de fin du répertoire central.
3. ZIP La fin du répertoire central n'est pas suivie par d'autres données.
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. Sinon, revenez à la vérification de l'APK à l'aide du schéma v2 .
Pour chaque signer du bloc APK Signature Scheme v3 avec une version min et max du SDK qui est à portée de la plate-forme actuelle :
1. Choisissez signature algorithm ID pris en charge le plus puissant parmi signatures . L’ordre des forces dépend de chaque version d’implémentation/plateforme.
2. Vérifiez la signature correspondante des signatures par rapport signed data à l'aide public key . (Il est désormais possible d'analyser signed data en toute sécurité.)
3. Vérifiez que les versions min et max du SDK 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 digests et signatures est identique. (Cela permet d'éviter la suppression/l'ajout de signature.)
5. Calculez le résumé du contenu APK en utilisant le même algorithme de résumé que l'algorithme de résumé utilisé par l'algorithme de signature.
6. Vérifiez que le résumé calculé est identique au digest correspondant de digests .
7. Vérifiez que SubjectPublicKeyInfo du premier certificate de certificates est identique à public key .
8. Si l'attribut de preuve de rotation existe pour le signer , vérifiez que la structure est valide et que ce signer est le dernier certificat de la liste.
La vérification réussit si exactement un signer a été trouvé à portée de la plate-forme actuelle et que l'étape 3 a réussi pour ce signer .

Validation

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