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.
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)
- X.509-préfixé longueur
-
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
-
- séquence préfixée longueur de préfixe de longueur
-
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 dessigned data
-
- préfixé longueur de
public key
(SubjectPublicKeyInfo, forme ASN.1 DER)
- préfixé-longueur des
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
- X.509-préfixé longueur
-
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 designed data
- préfixé-longueur des
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)
- X.509-préfixé longueur
- Séquence d'
signature algorithm IDs
(de uint32) - un pour chaque certificat de l'ensemble précédent, dans le même ordre.
- séquence préfixée longueur de
-
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 designed 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
- Localisez le bloc de signature APK et vérifiez que :
- Deux champs de taille d'APK Signing Block contiennent la même valeur.
- ZIP Central Directory est immédiatement suivi de l'enregistrement ZIP End of Central Directory.
- ZIP La fin du répertoire central n'est pas suivie de plus de 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. Dans le cas contraire, revenir à la vérification de l'APK en utilisant système v2 .
- 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:- Choisissez la prise en charge la plus forte
signature algorithm ID
l'signatures
signature algorithm ID
designatures
. L'ordre de force dépend de chaque version d'implémentation/plate-forme. - Vérifiez la correspondante
signature
designatures
contre lessigned data
en utilisant lapublic key
. (Il est maintenant sûr d'analyser dessigned data
.) - Vérifier les min et les versions SDK max dans les données signées correspondent à celles spécifiées pour le
signer
. - Vérifiez que la liste ordonnée des ID d'algorithme de signature dans les
digests
etsignatures
est identique. (Ceci est pour empêcher la suppression/l'ajout de signature.) - 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.
- Vérifiez que le digest calculé est identique au correspondant de
digest
dedigests
. - Vérifiez que SubjectPublicKeyInfo du premier
certificate
decertificates
est identique àpublic key
. - Si la preuve de rotation attribut existe pour le
signer
vérifier que le struct est valide et cesigner
est le dernier certificat dans la liste.
- Choisissez la prise en charge la plus forte
- 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 cesigner
.
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/
.