Schéma de signature APK v3.2

Android 17 (niveau d'API 37) introduit APK Signature Scheme v3.2, un schéma de signature hybride conçu pour prendre en charge la transition de l'écosystème Android vers la cryptographie post-quantique (PQC).

À mesure que le secteur déploie des algorithmes PQC à grande échelle, le schéma v3.2 offre une défense en profondeur. Il vous oblige à signer les APK avec un algorithme classique, tel que RSA ou ECDSA, et un algorithme PQC. Cette approche hybride utilise la cryptographie classique pour protéger votre APK tout en vous défendant contre les menaces des ordinateurs quantiques.

Objectif et détails

Le schéma v3.2 fonctionne comme un mécanisme de transition standard et conforme aux normes du secteur. Avec cette approche hybride, vous bénéficiez des avantages de la PQC en matière de résistance quantique tout en continuant à vous appuyer sur la sécurité éprouvée des algorithmes de signature classiques. Une fois que les algorithmes PQC nouvellement normalisés auront atteint une maturité opérationnelle à grande échelle, vous pourrez passer de cette configuration hybride à une seule clé de signature PQC. La plate-forme prend en charge le schéma de signature v3.2 à partir d'Android 17. Les versions d'Android antérieures ignorent le bloc v3.2 et utilisent les schémas précédents pour la validation de la signature.

Pour maintenir la sécurité et éviter les attaques par rétrogradation pendant cette transition, le schéma v3.2 applique les comportements suivants :

  • Nouveau matériel de clé : la transition vers un bloc hybride nécessite la génération de nouvelles clés classiques et PQC. Ne réutilisez pas le matériel de clé entre les configurations hybrides et non hybrides.
  • Rotation implicite : la plate-forme traite le bloc hybride comme une rotation de clé implicite. La plate-forme ajoute la nouvelle clé classique à la lignée de signature existante de l'application en tant qu'avant-dernière clé, et traite la nouvelle clé PQC comme l'identité de signature actuelle de l'application.
  • Lignée partagée : pour exécuter correctement la rotation implicite, la nouvelle clé classique et la nouvelle clé PQC du bloc hybride doivent partager la même ascendance de signature. Vous devez dupliquer l'historique de signature existant de l'application (qu'il s'agisse d'une seule clé d'origine ou d'une lignée de clés ayant fait l'objet d'une rotation) pour les deux nouveaux signataires hybrides. La plate-forme utilise cette lignée partagée pour vérifier que l'entité qui fait passer l'application au schéma hybride est le propriétaire légitime de l'identité de signature actuelle de l'application.
  • Restriction de signataire unique PQC : lors du déploiement initial de la PQC, Android limite explicitement l'utilisation des algorithmes PQC au bloc hybride v3.2. La plate-forme ne valide pas une configuration PQC à signataire unique à l'aide de schémas de signature précédents, tels que v2, v3.0 ou v3.1.
  • Retour en arrière : lors du passage d'un bloc hybride v3.2 à un bloc à signataire unique (un signataire classique ou un signataire PQC lorsqu'il sera compatible dans une version ultérieure), la plate-forme vérifie que les clés classiques et PQC du bloc hybride sont présentes dans la nouvelle lignée de signature et attestent du nouveau signataire unique.

Bonnes pratiques pour la transition

Pour maintenir la compatibilité avec les versions d'Android antérieures et fournir un chemin de mise à niveau sécurisé lors de la transition vers la signature PQC, les APK doivent continuer à inclure un bloc de signature v3.0 ou v3.1 standard signé par une seule clé classique. Étant donné que seuls Android 17 (niveau d'API 37) et les versions ultérieures sont compatibles avec le schéma hybride v3.2, cette exigence permet aux appareils exécutant des versions antérieures de valider et d'installer l'application.

Configuration de remplacement classique

Pour fournir un filet de sécurité opérationnel lors de la transition PQC, implémentez une configuration de remplacement classique.

  • Applications existantes : la clé de signature établie actuelle de l'application, K0, sert de base naturelle à ce remplacement.
  • Nouvelles applications : générez une clé de signature classique de référence, K0, en même temps que les nouvelles clés hybrides, C_K1 et PQC_K1, pour établir l'identité initiale.

Dans les deux cas, l'APK doit inclure un bloc de signature v3.0 ou v3.1 standard signé par la clé classique, K0, ainsi que le bloc hybride v3.2 signé par les nouvelles clés hybrides, C_K1 et PQC_K1.

Lors du déploiement initial du schéma v3.2, la lignée de signature du bloc hybride doit accorder la fonctionnalité ROLLBACK à K0. En cas de problème de déploiement, cette fonctionnalité permet à l'application de revenir à une signature classique sans perturber les mises à jour des utilisateurs. Une fois que des données d'exécution suffisantes confirment la stabilité du déploiement hybride, nous vous recommandons de supprimer la fonctionnalité ROLLBACK lors des mises à jour ultérieures afin de sécuriser entièrement vos nouvelles clés.

Exigences de configuration à long terme

Vous devez conserver cette configuration de signature hybride tant que votre application cible une version de plate-forme qui n'est compatible qu'avec le schéma hybride. Même si une version de plate-forme est compatible avec les clés PQC à signataire unique, vous devez signer tout APK ciblant une version qui nécessite le bloc hybride v3.2 avec les deux clés.

Bloc APK Signature Scheme v3.2

Le bloc de signature APK stocke le bloc de signature v3.2 ainsi que tous les blocs de signature v2, v3.0 et v3.1.

La structure du bloc v3.2 est semblable à celle de la version 3.0, mais utilise un nouvel ID de bloc, 0x70e1c89f, pour indiquer qu'il s'agit d'un bloc hybride. Un bloc v3.2 valide doit contenir exactement deux signataires.

Algorithmes compatibles

Le schéma v3.2 est initialement compatible avec les algorithmes de signature PQC suivants :

  • ML-DSA-65
  • ML-DSA-87

Ils sont associés à des algorithmes de signature classiques standards, tels que ceux compatibles avec les versions 3.0 et 3.1, pour former le bloc hybride.

Format

Le bloc de signature APK stocke le bloc APK Signature Scheme v3.2 sous l'ID 0x70e1c89f.

Le format du bloc v3.2 est identique à celui de la version 3.0, mais la séquence de premier niveau des éléments de signataire doit contenir exactement deux entrées ciblant la même version du SDK :

  • séquence de signataires avec préfixe de longueur :
    • signataire avec préfixe de longueur (classique)
    • signataire avec préfixe de longueur (PQC)

Chaque signataire utilise le format v3 standard :

  • données signées avec préfixe de longueur :
    • séquence de condensés avec préfixe de longueur :
    • ID d'algorithme de signature (4 octets)
    • condensé (avec préfixe de longueur)
    • séquence de certificats avec préfixe de longueur :
    • certificat X.509 avec préfixe de longueur (format ASN.1 DER)
    • minSDK (uint32)
    • maxSDK (uint32)
    • séquence d'attributs supplémentaires avec préfixe de longueur :
    • ID (uint32)
    • valeur (longueur variable : longueur de l'attribut supplémentaire - 4 octets)
  • minSDK (uint32)
  • maxSDK (uint32)
  • séquence de signatures avec préfixe de longueur :
    • ID d'algorithme de signature (4 octets)
    • signature avec préfixe de longueur sur les données signées
  • clé publique avec préfixe de longueur (SubjectPublicKeyInfo, format ASN.1 DER)

Validation

Sur Android 17 (niveau d'API 37) et versions ultérieures, pour valider la signature v3.2, la plate-forme valide les signataires classiques et PQC, confirme leur compatibilité et vérifie la lignée de rotation implicite. Sur Android 16 (niveau d'API 36) et les versions de plate-forme antérieures, la plate-forme ne traite pas ce bloc de signature hybride et utilise plutôt les schémas précédents.

Le processus global est le suivant :

  1. Recherchez le bloc APK Signature Scheme v3.2 (ID 0x70e1c89f).
  2. Vérifiez que le bloc contient exactement deux signataires. Si le nombre de signataires est inférieur ou supérieur à deux, la validation échoue.
  3. Vérifiez qu'un signataire utilise un algorithme de signature classique et que l'autre utilise un algorithme de signature PQC. Si les deux sont classiques ou PQC, la validation échoue.
  4. Vérifiez que les deux signataires ciblent exactement la même plage de SDK (minSdkVersion et maxSdkVersion).
  5. Pour chacun des deux signataires, effectuez la validation v3 standard :
    1. Choisissez l'ID d'algorithme de signature compatible le plus puissant parmi les signatures.
    2. Validez la signature correspondante à partir des signatures par rapport aux données signées à l'aide de la clé publique.
    3. Vérifiez que les valeurs minSdkVersion et maxSdkVersion dans les données signées correspondent aux valeurs minSdkVersion et maxSdkVersion non signées.
    4. Analysez les certificats et vérifiez que le premier certificat correspond à la clé publique.
    5. Analysez les attributs supplémentaires pour extraire les structures de preuve de rotation.
  6. Vérifiez l'historique de signature (preuve de rotation) :
    1. Vérifiez que les deux signataires ont des historiques de signature précédents identiques.
    2. Les longueurs de lignée doivent correspondre, et tous les certificats et indicateurs de fonctionnalité menant aux signataires actuels doivent être identiques.
    3. Si les historiques correspondent, fusionnez les lignées : traitez le certificat du signataire classique comme le prédécesseur du certificat du signataire PQC, en attribuant le signataire PQC comme nœud terminal actuel.
  7. Validez les condensés de contenu :
    1. Parcourez la carte des condensés pour les deux signataires.
    2. Vérifiez que pour tous les algorithmes de condensé correspondants, les valeurs de condensé calculées sont identiques entre les signataires classiques et PQC.
  8. Utilisez les condensés correspondants des signataires validés pour vérifier l'intégrité du contenu de l'APK (comme pour les versions 2 et 3).
    1. Si l'application est déjà installée, vérifiez la traçabilité de la mise à jour du package :
    2. Mise à jour à partir d'un seul signataire : si l'application installée a été signée avec une seule clé classique, cette clé doit être présente dans la lignée de signature du nouveau bloc hybride en tant que prédécesseur des signataires hybrides.
    3. Mise à jour d'un signataire hybride pour continuer à utiliser un signataire hybride : si l'application installée a été signée avec un bloc hybride v3.2, les clés classiques et PQC précédentes doivent rester les signataires actifs actuels dans le bloc v3.2 de l'APK de mise à jour, ou les deux doivent être présentes dans la nouvelle lignée de signature attestant des clés hybrides nouvellement pivotées.
    4. Transition d'un signataire hybride : si l'application installée a été signée avec un bloc hybride v3.2 et que l'APK de mise à jour revient à un seul signataire (PQC ou classique), les deux signataires hybrides précédents doivent être présents dans la traçabilité de signature de l'APK de mise à jour et attester de la nouvelle clé de signature unique.
    5. Chemins de mise à jour non valides : si un développeur tente de mettre à jour une application signée de manière hybride en n'utilisant qu'une seule des clés hybrides comme signataire unique sans rotation appropriée, la mise à jour échoue. Les deux clés doivent être explicitement impliquées dans toute transition pour éviter les attaques par rétrogradation.
  9. Si une étape échoue, la validation échoue.

Protection contre la suppression

Pour éviter les attaques par rétrogradation vers des schémas de signature inférieurs, le schéma v3.2 inclut des attributs de protection contre la suppression semblables aux itérations de schéma précédentes.

L'outil de signature écrit deux attributs de protection contre la suppression hybride spécifiques dans les attributs supplémentaires des blocs de signature v3.0 et v3.1. Ces attributs définissent les limites exactes de la version du SDK dans lesquelles le bloc hybride v3.2 doit être présent et validé :

  • Attribut de version minimale du SDK (ID 0xbf940529) : la valeur de cet attribut détermine la version minimale du SDK compatible avec le bloc de signature hybride.
  • Attribut de version maximale du SDK (ID 0x9f06b79c) : la valeur de cet attribut détermine la version maximale du SDK compatible avec le bloc de signature hybride. Cet attribut vous permet de passer à une configuration à signataire unique lorsque les versions de plate-forme supérieures ne nécessitent pas la signature hybride.

Si la plate-forme ignore la validation v3.2, car le bloc est manquant ou que sa plage de SDK ne s'applique pas à l'appareil, elle valide l'APK par rapport au bloc suivant. Si ce bloc antérieur contient ces attributs de protection contre la suppression, la plate-forme applique les vérifications suivantes :

  • Vérification de la présence et de la plage : si un bloc de signature v3.0 ou v3.1 contient l'attribut de SDK minimal (ID 0xbf940529, valeur X) ou l'attribut de SDK maximal (ID 0x9f06b79c, valeur Y), la plate-forme exige que le bloc hybride v3.2 existe dans l'APK. La plate-forme lit le bloc hybride pour vérifier que sa plage de SDK cible correspond aux limites spécifiées par ces attributs. Si le bloc v3.2 est manquant ou si ses valeurs cibles internes minimales et maximales du SDK ne sont pas égales à X et Y, la plate-forme rejette l'installation.
  • Application dans la plage : si la version du SDK de l'appareil se situe dans la plage valide spécifiée par ces attributs (supérieure ou égale à X et inférieure ou égale à Y lorsque vous fournissez l' attribut maximal), la plate-forme exige strictement le bloc hybride v3.2 pour la validation de la signature. Si la plate-forme valide un bloc v3.0 ou v3.1 sur un appareil dans cette plage de SDK cible, elle rejette l'installation, car le bloc v3.2 a été contourné ou supprimé de manière malveillante.

En appliquant ces limites, la plate-forme détermine quand un APK doit contenir un bloc v3.2. Si le bloc a été supprimé, la plate-forme rejette l'installation pour éviter une attaque par rétrogradation.

Valider votre implémentation

Pour tester votre implémentation du schéma de signature v3.2, exécutez les tests CTS HybridSignatureVerificationTest.java situés dans cts/hostsidetests/appsecurity/src/android/appsecurity/cts/.

Ces tests couvrent un ensemble complet de scénarios, y compris les installations réussies, les mises à jour à partir de versions classiques uniquement, les transitions de rollback à l'aide de la fonctionnalité ROLLBACK et les validations des mesures d'atténuation des attaques par suppression.