Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Schema di firma APK v3

Android 9 supporta la rotazione della chiave APK , che offre alle app la possibilità di modificare la chiave di firma come parte di un aggiornamento APK. Per rendere pratica la rotazione, gli APK devono indicare i livelli di fiducia tra la chiave di firma nuova e vecchia. Per supportare la rotazione delle chiavi, abbiamo aggiornato lo schema delle firme APK da v2 a v3 per consentire l'utilizzo delle chiavi nuove e vecchie. V3 aggiunge informazioni sulle versioni SDK supportate e una struttura di prova di rotazione al blocco di firma APK.

Blocco firma APK

Per mantenere la retrocompatibilità con il formato APK v1, le firme APK v2 e v3 sono archiviate all'interno di un blocco di firma APK, situato immediatamente prima della directory centrale ZIP.

Il formato Blocco firma APK v3 è lo stesso di v2 . La firma v3 dell'APK viene archiviata come coppia ID-valore con ID 0xf05368c0.

Blocco dello schema di firma APK v3

Lo schema v3 è progettato per essere molto simile allo schema v2 . Ha lo stesso formato generale e supporta gli stessi ID algoritmo di firma , dimensioni chiave e curve EC.

Tuttavia, lo schema v3 aggiunge informazioni sulle versioni SDK supportate e sulla struttura di prova di rotazione.

Formato

Il blocco v3 dello schema di firma APK è memorizzato all'interno del blocco di firma APK con ID 0xf05368c0 .

Il formato del blocco AP3 Signature Scheme v3 segue quello di v2:

  • sequenza con prefisso di lunghezza del signer prefisso di lunghezza:
    • signed data prefisso di lunghezza:
      • sequenza con prefisso di lunghezza dei digests prefisso di lunghezza:
        • signature algorithm ID (4 byte)
        • digest (prefisso lunghezza)
      • sequenza con prefisso di lunghezza dei certificates X.509:
        • certificate X.509 con prefisso di lunghezza (modulo DER ASN.1)
      • minSDK (uint32) - questo firmatario dovrebbe essere ignorato se la versione della piattaforma è inferiore a questo numero.
      • maxSDK (uint32) - questo firmatario dovrebbe essere ignorato se la versione della piattaforma è sopra questo numero.
      • sequenza con prefisso di lunghezza degli additional attributes prefisso di lunghezza:
        • ID (uint32)
        • value (lunghezza variabile: lunghezza dell'attributo aggiuntivo - 4 byte)
        • ID - 0x3ba06f8c
        • value - Struct della prova di rotazione
    • minSDK (uint32) - duplicato del valore minSDK nella sezione dei dati firmati - utilizzato per saltare la verifica di questa firma se la piattaforma corrente non è nell'intervallo. Deve corrispondere al valore dei dati firmati.
    • maxSDK (uint32) - duplicato del valore maxSDK nella sezione dei dati firmati - utilizzato per saltare la verifica di questa firma se la piattaforma corrente non è nell'intervallo. Deve corrispondere al valore dei dati firmati.
    • sequenza con prefissi di lunghezza delle signatures prefisso di lunghezza:
      • signature algorithm ID (uint32)
      • signature prefisso di lunghezza sui signed data
    • public key prefisso di lunghezza (SubjectPublicKeyInfo, modulo DER ASN.1)

Strutture a prova di rotazione e di fiducia

La struttura della prova di rotazione consente alle app di ruotare il loro certificato di firma senza essere bloccate su altre app con cui comunicano. A tale scopo, le firme delle app contengono due nuovi dati:

  • affermazione da parte di terzi che la certificazione di firma dell'app può essere considerata attendibile ovunque siano attendibili i suoi predecessori
  • i vecchi certificati di firma dell'app di cui l'app stessa si fida ancora

L'attributo della prova di rotazione nella sezione dei dati firmati è costituito da un elenco collegato singolarmente, con ogni nodo contenente un certificato di firma utilizzato per firmare le versioni precedenti dell'app. Questo attributo è destinato a contenere le strutture di dati concettuali di prova di rotazione e auto-affidabili-old-certs. L'elenco è ordinato per versione con il certificato di firma più vecchio corrispondente al nodo radice. La struttura dei dati di prova di rotazione viene creata facendo in modo che il certificato in ciascun nodo firmi il successivo nell'elenco e quindi fornisca a ogni nuova chiave l'evidenza che dovrebbe essere affidabile come la chiave più vecchia.

La struttura di dati auto-affidabili-old-certs è costruita aggiungendo flag a ciascun nodo indicandone l'appartenenza e le proprietà nel set. Ad esempio, potrebbe essere presente un flag che indica che il certificato di firma in un determinato nodo è attendibile per ottenere le autorizzazioni di firma Android. Questo flag consente ad altre app firmate dal certificato precedente di ottenere ancora un'autorizzazione di firma definita da un'app firmata con il nuovo certificato di firma. Poiché l'intero attributo della prova di rotazione risiede nella sezione dei dati firmati del campo del signer v3, è protetto dalla chiave utilizzata per firmare l'apk contenente.

Questo formato preclude più chiavi di firma e la convergenza di certificati di firma di antenati diversi su uno (più nodi iniziali su un sink comune).

Formato

La prova di rotazione è memorizzata nel blocco Schema di firma APK v3 con ID 0x3ba06f8c . Il suo formato è:

  • sequenza con prefissi di lunghezza dei levels prefisso di lunghezza:
    • signed data prefisso di lunghezza (dal certificato precedente - se esiste)
      • certificate X.509 con prefisso di lunghezza (modulo DER ASN.1)
      • signature algorithm ID (uint32) - algoritmo utilizzato da cert nel livello precedente
    • flags (uint32) - flags che indicano se questo certificato deve essere presente nella struttura self-trusted-old-certs e per quali operazioni.
    • signature algorithm ID (uint32): deve corrispondere a quello della sezione dei dati firmati al livello successivo.
    • signature prefisso di lunghezza sui signed data sopra

Certificati multipli

Android attualmente tratta un APK firmato con più certificati come avente un'identità di firma univoca separata dai certificati comprendenti. Pertanto, l'attributo della prova di rotazione nella sezione dei dati firmati forma un grafico aciclico diretto, che potrebbe essere meglio visualizzato come un elenco collegato singolarmente, con ogni set di firmatari per una data versione che rappresenta un nodo. Ciò aggiunge ulteriore complessità alla struttura della prova di rotazione (versione multi-signer di seguito). In particolare, l'ordinazione diventa una preoccupazione. Inoltre, non è più possibile firmare gli APK in modo indipendente, poiché la struttura della prova di rotazione deve avere i vecchi certificati di firma che firmano il nuovo set di certificati, piuttosto che firmarli uno per uno. Ad esempio, un APK firmato dalla chiave A che desidera essere firmato da due nuove chiavi B e C non può avere il firmatario B che include solo una firma di A o B, poiché si tratta di un'identità di firma diversa da B e C. significa che i firmatari devono coordinarsi prima di costruire una simile struttura.

Attributo di prova di rotazione di più firmatari

  • sequenza con prefisso lunghezza di sets prefisso lunghezza:
    • signed data (dal set precedente - se esiste)
      • sequenza di certificates prefisso di lunghezza
        • certificate X.509 con prefisso di lunghezza (modulo DER ASN.1)
      • Sequenza di signature algorithm IDs di signature algorithm IDs (uint32) - una per ciascun certificato dell'insieme precedente, nello stesso ordine.
    • flags (uint32) - flags che indicano se questo insieme di certificati deve essere o meno nella struttura auto-affidabile-old-certs e per quali operazioni.
    • sequenza con prefissi di lunghezza delle signatures prefisso di lunghezza:
      • signature algorithm ID (uint32): deve corrispondere a quello della sezione dei dati firmati
      • signature prefisso di lunghezza sopra i signed data sopra

Antenati multipli nella struttura della prova di rotazione

Lo schema v3 inoltre non gestisce due chiavi diverse ruotando sulla stessa chiave di firma per la stessa app. Ciò differisce dal caso di un'acquisizione, in cui la società acquirente vorrebbe spostare l'app acquisita per utilizzare la sua chiave di firma per condividere le autorizzazioni. L'acquisizione viene considerata come un caso d'uso supportato perché la nuova app si distinguerebbe per il nome del pacchetto e potrebbe contenere la propria struttura di prova di rotazione. Il caso non supportato, della stessa app con due percorsi diversi per ottenere lo stesso certificato, interrompe molte delle ipotesi formulate nella progettazione della rotazione dei tasti.

Verifica

In Android 9 e versioni successive, gli APK possono essere verificati in base allo schema di firma APK v3, schema v2 o schema v1. Le piattaforme precedenti ignorano le firme v3 e provano a verificare le firme v2, quindi v1.

Processo di verifica della firma APK

Figura 1. Processo di verifica della firma APK

Verifica dell'APK Signature Scheme v3

  1. Individua il blocco firma APK e verifica che:
    1. Due campi di dimensioni di APK Signing Block contengono lo stesso valore.
    2. ZIP Central Directory è immediatamente seguito dal record ZIP End of Central Directory.
    3. ZIP End of Central Directory non è seguito da più dati.
  2. Individua il primo blocco v3 dello schema di firma APK all'interno del blocco di firma APK. Se è presente il blocco v3, procedere al passaggio 3. In caso contrario, tornare alla verifica dell'APK utilizzando lo schema v2 .
  3. Per ogni signer nel blocco dello schema di firma APK v3 con una versione minima e massima dell'SDK che si trova nel raggio della piattaforma corrente:
    1. Scegli l' signature algorithm ID supportato più forte tra le signatures . L'ordinamento della forza dipende da ogni versione di implementazione / piattaforma.
    2. Verificare la signature corrispondente dalle signatures rispetto ai signed data utilizzando public key . (Ora è sicuro analizzare i signed data .)
    3. Verificare che le versioni min e max dell'SDK nei dati firmati corrispondano a quelle specificate per il signer .
    4. Verificare che l'elenco ordinato di ID algoritmo di firma nei digests e nelle signatures sia identico. (Questo serve a prevenire lo stripping / aggiunta della firma.)
    5. Calcola il digest dei contenuti APK usando lo stesso algoritmo digest dell'algoritmo digest usato dall'algoritmo di firma.
    6. Verificare che il digest calcolato sia identico al digest corrispondente dai digests .
    7. Verificare che SubjectPublicKeyInfo del primo certificate di certificates sia identico alla public key .
    8. Se l'attributo della prova di rotazione esiste per il signer verificare che la struttura sia valida e che questo signer sia l'ultimo certificato nell'elenco.
  4. La verifica ha esito positivo se viene trovato esattamente un signer nel raggio della piattaforma corrente e il passaggio 3 ha avuto signer positivo per quel signer .

Validazione

Per verificare che il dispositivo supporti correttamente v3, eseguire i test CTS PkgInstallSignatureVerificationTest.java CTS in cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .