Android 17 (livello API 37) introduce lo schema di firma dell'APK v3.2, uno schema di firma ibrido progettato per supportare la transizione dell'ecosistema Android alla crittografia post-quantistica (PQC).
Man mano che il settore implementa gli algoritmi PQC su larga scala, lo schema v3.2 fornisce una difesa approfondita. Richiede di firmare gli APK con un algoritmo classico, come RSA o ECDSA, e un algoritmo PQC. Questo approccio ibrido utilizza la crittografia classica per proteggere l'APK e al contempo difendersi dalle minacce dei computer quantistici.
Scopo e dettagli
Lo schema v3.2 funziona come un meccanismo di transizione standard e allineato al settore. Con questo approccio ibrido, ottieni i vantaggi di resistenza quantistica della PQC continuando a fare affidamento sulla sicurezza comprovata degli algoritmi di firma classici. Una volta che gli algoritmi PQC appena standardizzati raggiungono la maturità operativa su larga scala, puoi passare da questa configurazione ibrida a una singola chiave di firma PQC. Il supporto della piattaforma per lo schema di firma v3.2 inizia con Android 17. Le versioni precedenti di Android ignorano il blocco v3.2 e utilizzano gli schemi precedenti per la verifica della firma.
Per mantenere la sicurezza e prevenire gli attacchi di downgrade durante questa transizione, lo schema v3.2 applica i seguenti comportamenti:
- Nuovo materiale della chiave: la transizione a un blocco ibrido richiede la generazione di nuove chiavi classiche e PQC. Non riutilizzare il materiale della chiave tra configurazioni ibride e non ibride.
- Rotazione implicita: la piattaforma tratta il blocco ibrido come una rotazione implicita della chiave. La piattaforma aggiunge la nuova chiave classica alla genealogia di firma esistente dell'app come penultima chiave e tratta la nuova chiave PQC come l'identità di firma corrente dell'app.
- Genealogia condivisa: per eseguire correttamente la rotazione implicita, sia la nuova chiave classica sia la nuova chiave PQC all'interno del blocco ibrido devono condividere la stessa genealogia di firma. Devi duplicare la cronologia di firma esistente dell'app, sia una singola chiave originale sia una genealogia di chiavi ruotate in precedenza, per entrambi i nuovi firmatari ibridi. La piattaforma utilizza questa tracciabilità condivisa per verificare che l'entità che esegue la transizione dell'app allo schema ibrido sia il proprietario legittimo dell'identità di firma corrente dell'app.
- Restrizione del firmatario singolo PQC: durante il lancio iniziale della PQC, Android limita esplicitamente l'utilizzo degli algoritmi PQC al blocco ibrido v3.2. La piattaforma non verifica una configurazione PQC con un singolo firmatario utilizzando schemi di firma precedenti, come v2, v3.0 o v3.1.
- Transizione inversa: quando si esegue la transizione da un blocco ibrido v3.2 a un blocco con un singolo firmatario, un firmatario classico o un firmatario PQC quando supportato in una release futura, la piattaforma verifica che sia le chiavi classiche sia le chiavi PQC del blocco ibrido siano presenti nella nuova genealogia di firma e attestino il nuovo firmatario singolo.
Best practice per la transizione
Per mantenere la compatibilità con le versioni precedenti di Android e fornire un percorso di upgrade sicuro durante la transizione alla firma PQC, gli APK devono continuare a includere un blocco di firma v3.0 o v3.1 standard firmato da una singola chiave classica. Poiché solo Android 17 (livello API 37) e versioni successive supportano lo schema ibrido v3.2, questo requisito consente ai dispositivi con versioni precedenti di verificare e installare l'app.
Configurazione di fallback classica
Per fornire una rete di sicurezza operativa durante la transizione PQC, implementa una configurazione di fallback classica.
- App esistenti: la chiave di firma corrente dell'app, K0, funge da base naturale per questo fallback.
- Nuove app: genera una chiave di firma classica di base, K0, insieme alle nuove chiavi ibride, C_K1 e PQC_K1, per stabilire l'identità iniziale.
In entrambi gli scenari, l'APK deve includere un blocco di firma v3.0 o v3.1 standard firmato dalla chiave classica, K0, insieme al blocco ibrido v3.2 firmato dalle nuove chiavi ibride, C_K1 e PQC_K1.
Durante l'implementazione iniziale dello schema v3.2, la genealogia di firma per il blocco ibrido deve concedere la funzionalità ROLLBACK a K0. Se si verificano problemi di implementazione, questa funzionalità consente all'app di eseguire il fallback a una firma classica senza interrompere gli aggiornamenti degli utenti. Una volta che i dati di runtime sufficienti confermano che l'implementazione ibrida è stabile, ti consigliamo di rimuovere la funzionalità ROLLBACK negli aggiornamenti successivi per proteggere completamente le nuove chiavi.
Requisiti di configurazione a lungo termine
Devi mantenere questa configurazione di firma ibrida finché la tua app ha come target una release della piattaforma che supporta esclusivamente lo schema ibrido. Anche se una versione della piattaforma supporta le chiavi PQC con un singolo firmatario, devi firmare qualsiasi APK che abbia come target una release che richiede il blocco ibrido v3.2 con entrambe le chiavi.
Blocco dello schema di firma dell'APK v3.2
Il blocco di firma dell'APK memorizza il blocco di firma v3.2 insieme a tutti i blocchi di firma v2, v3.0 e v3.1.
La struttura del blocco v3.2 è simile a v3.0, ma utilizza un nuovo ID blocco, 0x70e1c89f, per indicare che si tratta di un blocco ibrido. Un blocco v3.2 valido deve contenere esattamente due firmatari.
Algoritmi supportati
Lo schema v3.2 supporta inizialmente i seguenti algoritmi di firma PQC:
- ML-DSA-65
- ML-DSA-87
Questi vengono abbinati agli algoritmi di firma classici standard, come quelli supportati in v3.0 e v3.1, per formare il blocco ibrido.
Formato
Il blocco di firma dell'APK memorizza il blocco dello schema di firma dell'APK v3.2 con l'ID 0x70e1c89f.
Il formato del blocco v3.2 è identico a v3.0, ma la sequenza di primo livello degli elementi del firmatario deve contenere esattamente due voci che hanno come target la stessa versione dell'SDK:
- Sequenza con prefisso di lunghezza del firmatario con prefisso di lunghezza:
- Firmatario con prefisso di lunghezza (classico)
- Firmatario con prefisso di lunghezza (PQC)
Ogni firmatario utilizza il formato v3 standard:
- Dati firmati con prefisso di lunghezza:
- Sequenza con prefisso di lunghezza dei digest con prefisso di lunghezza:
- ID algoritmo di firma (4 byte)
- Digest (con prefisso di lunghezza)
- Sequenza con prefisso di lunghezza dei certificati:
- Certificato X.509 con prefisso di lunghezza (modulo ASN.1 DER)
- minSDK (uint32)
- maxSDK (uint32)
- Sequenza con prefisso di lunghezza degli attributi aggiuntivi con prefisso di lunghezza:
- ID (uint32)
- Valore (lunghezza variabile: lunghezza dell'attributo aggiuntivo - 4 byte)
- minSDK (uint32)
- maxSDK (uint32)
- Sequenza con prefisso di lunghezza delle firme con prefisso di lunghezza:
- ID algoritmo di firma (4 byte)
- Firma con prefisso di lunghezza sui dati firmati
- Chiave pubblica con prefisso di lunghezza (
SubjectPublicKeyInfo, modulo ASN.1 DER)
Verifica
Su Android 17 (livello API 37) e versioni successive, per verificare la firma v3.2, la piattaforma verifica sia i firmatari classici sia i firmatari PQC, ne conferma la compatibilità e controlla la genealogia di rotazione implicita. Nelle release della piattaforma Android 16 (livello API 36) e precedenti, la piattaforma non elabora questo blocco di firma ibrido e utilizza invece gli schemi precedenti.
La procedura generale è la seguente:
- Trova il blocco dello schema di firma dell'APK v3.2 (ID 0x70e1c89f).
- Verifica che il blocco contenga esattamente due firmatari. Se sono presenti meno o più di due firmatari, la verifica non va a buon fine.
- Verifica che un firmatario utilizzi un algoritmo di firma classico e l'altro un algoritmo di firma PQC. Se entrambi sono classici o entrambi sono PQC, la verifica non va a buon fine.
- Verifica che entrambi i firmatari abbiano come target esattamente lo stesso intervallo SDK (
minSdkVersionemaxSdkVersion). - Per ciascuno dei due firmatari, esegui la verifica v3 standard:
- Scegli l'ID dell'algoritmo di firma supportato più efficace dalle firme.
- Verifica la firma corrispondente dai dati firmati utilizzando la chiave pubblica.
- Verifica che
minSdkVersionemaxSdkVersionnei dati firmati corrispondano aminSdkVersionemaxSdkVersionnon firmati. - Analizza i certificati e verifica che il primo certificato corrisponda alla chiave pubblica.
- Analizza gli attributi aggiuntivi per estrarre le strutture di prova della rotazione.
- Verifica la cronologia di firma (prova di rotazione):
- Verifica che entrambi i firmatari abbiano cronologie di firma precedenti identiche.
- Le lunghezze della genealogia devono corrispondere e tutti i certificati e i flag di funzionalità che portano ai firmatari attuali devono essere identici.
- Se le cronologie corrispondono, unisci le genealogie: tratta il certificato del firmatario classico come il predecessore del certificato del firmatario PQC, assegnando il firmatario PQC come nodo terminale corrente.
- Verifica i digest dei contenuti:
- Itera la mappa dei digest per entrambi i firmatari.
- Verifica che, per tutti gli algoritmi di digest corrispondenti, i valori di digest calcolati siano identici tra i firmatari classici e PQC.
- Utilizza i digest corrispondenti dei firmatari verificati per verificare l'integrità dei contenuti dell'APK (in modo simile a v2 e v3).
- Se l'app è già installata, verifica la tracciabilità dell'aggiornamento del pacchetto:
- Aggiornamento da un singolo firmatario: se l'app installata è stata firmata con una singola chiave classica, questa chiave deve essere presente nella tracciabilità di firma del nuovo blocco ibrido come predecessore dei firmatari ibridi.
- Aggiornamento da un firmatario ibrido per continuare con l'ibrido: se l'app installata è stata firmata con un blocco ibrido v3.2, sia le chiavi classiche sia le chiavi PQC precedenti devono rimanere i firmatari attivi correnti nel blocco v3.2 dell'APK di aggiornamento oppure devono essere presenti nella nuova genealogia di firma che attesta le chiavi ibride appena ruotate.
- Transizione da un firmatario ibrido: se l'app installata è stata firmata con un blocco ibrido v3.2 e l'APK di aggiornamento torna a un singolo firmatario (PQC o classico), entrambi i firmatari ibridi precedenti devono essere presenti nella genealogia di firma dell'APK di aggiornamento e attestare la nuova chiave di firma singola.
- Percorsi di aggiornamento non validi: se uno sviluppatore tenta di aggiornare un'app firmata in modo ibrido utilizzando solo una delle chiavi ibride come singolo firmatario senza una rotazione corretta, l'aggiornamento non va a buon fine. Entrambe le chiavi devono essere esplicitamente coinvolte in qualsiasi transizione per prevenire gli attacchi di downgrade.
- Se un passaggio non va a buon fine, la verifica non va a buon fine.
Protezione da rimozione
Per prevenire gli attacchi di downgrade agli schemi di firma precedenti, lo schema v3.2 include attributi di protezione da rimozione simili alle iterazioni dello schema precedente.
Lo strumento di firma scrive due attributi di protezione da rimozione ibrida specifici negli attributi aggiuntivi dei blocchi di firma v3.0 e v3.1. Questi attributi definiscono i limiti esatti della versione dell'SDK all'interno dei quali il blocco ibrido v3.2 deve essere presente e verificato:
- Attributo della versione minima dell'SDK (ID
0xbf940529): il valore di questo attributo determina la versione minima dell'SDK supportata dal blocco di firma ibrido. - Attributo della versione massima dell'SDK
(ID
0x9f06b79c): il valore di questo attributo determina la versione massima dell'SDK supportata dal blocco di firma ibrido. Questo attributo ti consente di passare a una configurazione con un singolo firmatario quando le release della piattaforma più recenti non richiedono la firma ibrida.
Se la piattaforma ignora la verifica v3.2 perché il blocco non è presente o il relativo intervallo SDK non si applica al dispositivo, la piattaforma verifica l'APK rispetto al blocco successivo presente. Se il blocco precedente contiene questi attributi di protezione da rimozione, la piattaforma applica i seguenti controlli:
- Verifica della presenza e dell'intervallo: se un blocco di firma v3.0 o v3.1 contiene l'attributo SDK minimo (ID
0xbf940529, valore X) o l'attributo SDK massimo (ID0x9f06b79c, valore Y), la piattaforma richiede che il blocco ibrido v3.2 esista all'interno dell'APK. La piattaforma legge il blocco ibrido per verificare che l'intervallo SDK di destinazione corrisponda ai limiti specificati da questi attributi. Se il blocco v3.2 non è presente o se i valori di destinazione SDK minimi e massimi interni non sono uguali a X e Y, la piattaforma rifiuta l'installazione. - Applicazione all'interno dell'intervallo: se la versione dell'SDK del dispositivo rientra nell'intervallo valido specificato da questi attributi, ovvero è maggiore o uguale a X e minore o uguale a Y quando fornisci l' attributo massimo, la piattaforma richiede rigorosamente il blocco ibrido v3.2 per la verifica della firma. Se la piattaforma verifica un blocco v3.0 o v3.1 su un dispositivo all'interno di questo intervallo SDK di destinazione, la piattaforma rifiuta l'installazione perché il blocco v3.2 è stato bypassato o rimosso in modo dannoso.
Applicando questi limiti, la piattaforma determina quando un APK deve contenere un blocco v3.2. Se il blocco è stato rimosso, la piattaforma rifiuta l'installazione per prevenire un attacco di downgrade.
Convalida l'implementazione
Per testare l'implementazione dello schema di firma v3.2, esegui i test CTS HybridSignatureVerificationTest.java che si trovano in cts/hostsidetests/appsecurity/src/android/appsecurity/cts/.
Questi test coprono una suite completa di scenari, tra cui installazioni riuscite, aggiornamenti da versioni solo classiche, transizioni di rollback utilizzando la funzionalità ROLLBACK e verifiche delle mitigazioni degli attacchi di rimozione.