Il provisioning delle chiavi remote di Google sarà obbligatorio in Android 13: cosa significa per te

L'attestazione chiave di Android è la spina dorsale di molti servizi affidabili sui nostri smartphone, tra cui SafetyNet, Digital Car Key e l'API delle credenziali di identità. È richiesto come parte di Android a partire da Android 8 Oreo e dipendeva da una chiave root installata su un dispositivo in fabbrica. La fornitura di queste chiavi richiedeva la massima segretezza da parte del produttore e, se una chiave fosse trapelata, ciò avrebbe significato che la chiave avrebbe dovuto essere revocata. Ciò comporterebbe che il consumatore non sarebbe in grado di utilizzare nessuno di questi servizi affidabili, il che sarebbe un peccato se mai ci fosse una vulnerabilità che possa esporlo. Provisioning di chiavi remote, che sarà obbligatorio in Androide 13, mira a risolvere questo problema.

I componenti che compongono l'attuale catena di fiducia su Android

Prima di spiegare come funziona il nuovo sistema, è importante fornire un contesto su come funziona 

vecchio (e ancora in uso per molti dispositivi) il sistema funziona. Molti telefoni oggigiorno utilizzano l'attestazione della chiave supportata da hardware, che potresti conoscere come il chiodo nella bara per qualsiasi tipo di bypass SafetyNet. Esistono diversi concetti importanti da comprendere per lo stato attuale dell'attestazione chiave.

È una combinazione di questi concetti che garantisce che uno sviluppatore possa avere la certezza che un dispositivo non sia stato manomesso e possa gestire informazioni sensibili nel TEE.

Ambiente di esecuzione affidabile

Un Trusted Execution Environment (TEE) è una regione sicura sul SoC utilizzata per la gestione dei dati critici. Il TEE è obbligatorio sui dispositivi lanciati con Android 8 Oreo e versioni successive, il che significa che qualsiasi smartphone recente ne è dotato. Tutto ciò che non è all'interno del TEE è considerato "non attendibile" e può vedere solo contenuto crittografato. Ad esempio, il contenuto protetto da DRM è crittografato con chiavi a cui può accedere solo il software in esecuzione sul TEE. Il processore principale può vedere solo un flusso di contenuto crittografato, mentre il contenuto può essere decrittografato dal TEE e quindi visualizzato all'utente.

Zona fiduciaria ARM

Trusty è un sistema operativo sicuro che fornisce un TEE su Android e sui sistemi ARM utilizza Trustzone di ARM. Trusty viene eseguito sullo stesso processore del sistema operativo principale e ha accesso a tutta la potenza del dispositivo ma è completamente isolato dal resto del telefono. Trusty è costituito da quanto segue:

• Un piccolo kernel del sistema operativo derivato da Piccolo Kernel
• Un driver del kernel Linux per trasferire i dati tra l'ambiente sicuro e Android
• Una libreria in spazio utente Android per comunicare con applicazioni attendibili (ovvero attività/servizi protetti) tramite il driver del kernel

Il vantaggio che ha rispetto ai sistemi TEE proprietari è che tali sistemi TEE possono essere costosi e creare anche instabilità nell'ecosistema Android. Trusty viene fornito gratuitamente agli OEM partner da Google ed è open source. Android supporta altri sistemi TEE, ma Trusty è quello su cui Google spinge di più.

Cassaforte

I dispositivi StrongBox sono CPU sicure completamente separate, appositamente realizzate e certificate. Questi possono includere Secure Elements (eSE) incorporati o un'unità di elaborazione sicura su SoC (SPU). Google afferma che StrongBox è attualmente "fortemente consigliato" in dotazione con i dispositivi di lancio Androide 12 (secondo il documento di definizione della compatibilità) poiché è probabile che diventi un requisito in una futura versione di Android. Si tratta essenzialmente di un'implementazione più rigorosa di un archivio chiavi supportato da hardware e può essere implementato insieme a TrustZone. Un esempio di implementazione di StrongBox è il chip Titan M negli smartphone Pixel. Non molti telefoni utilizzano StrongBox e la maggior parte utilizza Trustzone di ARM.

Maestro delle chiavi TA

Keymaster Trusted Application (TA) è il keymaster sicuro che gestisce ed esegue tutte le operazioni di archiviazione delle chiavi. Può funzionare, ad esempio, su TrustZone di ARM.

Come cambia l'attestazione chiave con Android 12 e Android 13

Se una chiave viene esposta su uno smartphone Android, Google è tenuta a revocarla. Ciò rappresenta un problema per qualsiasi dispositivo a cui è stata inserita una chiave in fabbrica: qualsiasi tipo di fuga di dati che esponga la chiave significherebbe che gli utenti non sarebbero in grado di accedere a determinati contenuti protetti. Ciò potrebbe includere anche la revoca dell’accesso a servizi come Google Pay, qualcosa su cui molte persone fanno affidamento. Questo è un peccato per i consumatori perché senza la riparazione del telefono da parte di un produttore, non sarebbe possibile ripararlo da soli.

Accedi al provisioning della chiave remota. A partire da Android 12, Google sta sostituendo il provisioning della chiave privata in fabbrica con una combinazione di estrazione della chiave pubblica in fabbrica e fornitura di certificati via etere di breve durata certificati. Questo schema sarà richiesto in Android 13 e presenta un paio di vantaggi. Innanzitutto, impedisce agli OEM e agli ODM di dover gestire la segretezza delle chiavi in ​​una fabbrica. In secondo luogo, consente il ripristino dei dispositivi qualora le loro chiavi venissero compromesse, il che significa che i consumatori non perderanno per sempre l'accesso ai servizi protetti. Ora, invece di utilizzare un certificato calcolato utilizzando una chiave che si trova sul dispositivo e che potrebbe essere trapelata attraverso un file vulnerabilità, viene richiesto un certificato temporaneo a Google ogni volta che un servizio che richiede l'attestazione è usato.

Per quanto riguarda il funzionamento, è abbastanza semplice. Da ciascun dispositivo viene generata una coppia di chiavi statica univoca e la parte pubblica di questa coppia di chiavi viene estratta dall'OEM nella propria fabbrica e inviata ai server di Google. Lì serviranno come base di fiducia per il successivo provisioning. La chiave privata non lascia mai l'ambiente sicuro in cui viene generata.

Quando un dispositivo viene utilizzato per la prima volta per connettersi a Internet, genererà una richiesta di firma del certificato per chiavi che ha generato, firmandolo con la chiave privata che corrisponde alla chiave pubblica raccolta nel file fabbrica. I server backend di Google verificheranno l'autenticità della richiesta e quindi firmeranno le chiavi pubbliche, restituendo le catene di certificati. L'archivio chiavi sul dispositivo memorizzerà quindi queste catene di certificati, assegnandole alle app ogni volta che viene richiesta un'attestazione. Può trattarsi di qualsiasi cosa, da Google Pay a Pokemon Go.

Questa esatta catena di richieste di certificati avverrà regolarmente alla scadenza dei certificati o all'esaurimento dell'attuale fornitura di chiavi. Ogni applicazione riceve una chiave di attestazione diversa e le chiavi stesse vengono ruotate regolarmente, garantendo entrambe la privacy. Inoltre, i server backend di Google sono segmentati in modo tale che il server che verifica la chiave pubblica del dispositivo non veda le chiavi di attestazione allegate. Ciò significa che non è possibile per Google correlare le chiavi di attestazione al particolare dispositivo che le ha richieste.

Gli utenti finali non noteranno alcun cambiamento, anche se gli sviluppatori devono prestare attenzione a quanto segue, secondo Google.

• Struttura della catena di certificati
  • A causa della natura della nostra nuova infrastruttura di provisioning online, la lunghezza della catena è più lunga rispetto a prima ed è soggetta a modifiche.
• Radice di fiducia
  • La radice dell'attendibilità verrà eventualmente aggiornata dall'attuale chiave RSA a una chiave ECDSA.
• Deprecazione dell'attestazione RSA
  • Tutte le chiavi generate e attestate da KeyMint saranno firmate con una chiave ECDSA e la corrispondente catena di certificati. In precedenza, le chiavi asimmetriche venivano firmate dal loro algoritmo corrispondente.
• Certificati di breve durata e chiavi di attestazione
  • I certificati forniti ai dispositivi saranno generalmente validi fino a due mesi prima della scadenza e della rotazione.

Abbiamo contattato Google e chiesto se questo ha qualche rilevanza per Widevine DRM e in che modo alcuni utenti Pixel hanno segnalato che il loro livello DRM è stato declassato con un bootloader bloccato. Abbiamo anche chiesto se questo può essere distribuito ora come aggiornamento OTA agli utenti tramite Google Play Services. Aggiorneremo sicuramente questo articolo se riceveremo risposta. Non è chiaro quali componenti dell’attuale catena di fiducia saranno interessati o in che modo.

---

Fonte: Google