Dimenticare il PIN dello smartphone Android può avere conseguenze “fatali”: se impronta digitale, riconoscimento facciale o altri sistemi biometrici non bastano e non si ricorda più la credenziale principale, Google fa presente che non c’è soluzione. Serve cancellare il contenuto del telefono, configurarlo nuovamente e recuperare dal cloud ciò che era stato precedentemente sincronizzato o sottoposto a backup.
Google starebbe però preparando una sorta di “salvagente” per gli utenti Android più distratti. Nel codice di Android 17 QPR2 Beta 5 sono comparsi riferimenti a una funzione chiamata Sblocca con Account Google, pensata per consentire lo sblocco dello smartphone utilizzando l’account Google associato al dispositivo.
La nuova funzione non è ancora attiva e non c’è alcuna conferma che Google la distribuirà nella forma attualmente “avvistata”. Se Google dovesse fare sul serio, però, si palesa all’orizzonte un’evidente modifica nel modello di sicurezza del dispositivo Android.

Il PIN Android non è soltanto una barriera grafica
Si potrebbe immaginare il PIN della schermata di blocco come una semplice password che Android confronta con un valore memorizzato da qualche parte nel sistema. Sui dispositivi del robottino verde, invece, il funzionamento è decisamente più sofisticato.
Android utilizza la File-Based Encryption (FBE), obbligatoria sui dispositivi commercializzati con Android 10 o versioni successive. In pratica, il contenuto della memoria non è protetto con un’unica chiave: Android usa chiavi diverse per differenti categorie di dati. Alcune informazioni indispensabili al funzionamento del sistema possono essere lette già dopo l’accensione, prima ancora che l’utente inserisca il PIN; i dati personali più sensibili, invece, restano cifrati e inaccessibili fino al primo sblocco. Questi ultimi appartengono all’area definita Credential Encrypted (CE), perché l’accesso dipende dalla credenziale impostata sulla schermata di blocco.
Il PIN, la password o la sequenza di sblocco appartengono alla categoria che Android chiama LSKF, Lock Screen Knowledge Factor.
Android non utilizza direttamente il PIN come chiave AES con cui cifrare foto, messaggi e database delle applicazioni. Il sistema gestisce invece un segreto crittografico ad alta entropia chiamato synthetic password, dal quale dipende a sua volta la protezione delle chiavi necessarie per accedere ai dati dell’utente. Il PIN serve a sbloccare una catena di chiavi crittografiche.
Weaver e Gatekeeper impediscono di indovinare il PIN
Un PIN di 4 o 6 cifre contiene relativamente poca entropia: se un aggressore potesse provare combinazioni a velocità elevata, una protezione basata esclusivamente sul PIN sarebbe debole.
Android utilizza quindi componenti isolati dal sistema operativo principale, come Weaver e Gatekeeper, che possono operare nel Trusted Execution Environment (TEE) o in un hardware sicuro dedicato.
Weaver associa alla credenziale dell’utente un segreto casuale ad alta entropia: solo fornendo il valore corretto e rispettando le limitazioni sul numero e sulla frequenza dei tentativi, Android può ottenere il materiale crittografico necessario a proseguire con lo sblocco.
Android 17 rafforza inoltre ulteriormente le politiche di rate limiting, cioè i ritardi e i blocchi applicati dopo tentativi errati consecutivi. La documentazione AOSP specifica che i dati protetti dell’utente sono sbloccati soltanto quando il corretto LSKF viene fornito al sistema di verifica hardware.
Emerge quindi una domanda fondamentale: come può l’account Google sostituire un PIN che partecipa alla protezione delle chiavi locali?
Google deve creare una seconda strada verso la chiave
La documentazione AOSP sulla File-Based Encryption contiene un passaggio particolarmente significativo. Le chiavi che proteggono l’area Credential Encrypted possono essere recuperate attraverso la credenziale della schermata di blocco oppure, in determinate configurazioni, mediante specifici recovery o escrow token.
Che significa? Che dal punto di vista crittografico è possibile progettare più di una modalità per raggiungere lo stesso segreto principale.
L’attuale implementazione Android limita però i normali token di reset del passcode soprattutto a scenari gestiti, come profili di lavoro e dispositivi amministrati dall’organizzazione. La nuova funzione destinata agli utenti consumer richiederebbe quindi un meccanismo differente oppure un’estensione sostanziale di quelli già presenti.
Una possibile soluzione sarebbe permettere ad Android di proteggere la stessa chiave necessaria per accedere ai dati in due modi diversi. Il primo continuerebbe a dipendere dal PIN o dalla password impostati sul telefono; il secondo entrerebbe in gioco soltanto durante la scelta della strada Sblocca con Account Google, previa rigorosa verifica da parte di Google.
In questo modo Google non avrebbe bisogno di conoscere o conservare il PIN dello smartphone. Il dispositivo disporrebbe semplicemente di un secondo percorso, predisposto in anticipo, per recuperare l’accesso alle chiavi che proteggono i dati.
Allo stato attuale, tuttavia, si tratta soltanto di una nostra ipotesi: non c’è nulla che Google abbia documentato in proposito.
Account Google non significa necessariamente chiave conservata sui server Google
In queste ore, da quando si è saputo della novità Sblocca con Account Google, per aggirare il PIN dimenticato su Android, tanti commenti si sono focalizzati sul livello di sicurezza che una funzionalità simile può davvero garantire.
Se l’account Google può sbloccare lo smartphone, significa che Google possiede una sorta di chiave universale capace di decifrarlo? Al momento non esistono elementi per affermarlo.
Il codice individuato in Android rivela l’interfaccia della futura funzione, ma non descrive il protocollo crittografico sottostante né indica dove siano conservate eventuali chiavi di recupero.
Sono possibili architetture molto diverse. Il dispositivo potrebbe, ad esempio, preparare durante l’attivazione un segreto di recupero cifrato in modo che l’autenticazione Google serva soltanto ad autorizzarne l’utilizzo. Oppure parte del materiale crittografico potrebbe essere suddivisa tra smartphone e infrastruttura cloud, rendendo insufficienti entrambe le parti prese singolarmente.
Senza documentazione tecnica è del tutto prematuro parlare di “backdoor“. Un sistema ben congegnato, infatti, può permettere al legittimo proprietario di predisporre volontariamente una seconda credenziale senza necessariamente consegnare al fornitore del servizio una chiave universale per tutti i dispositivi.
L’autenticazione a due fattori diventa cruciale
Se Google procederà con il progetto Sblocca con Account Google, uno degli aspetti più delicati sarà il livello di autenticazione richiesto durante il recupero dello smartphone Android del quale non si ricorda il PIN.
Consentire lo sblocco semplicemente conoscendo indirizzo dell’account Google e password aumenterebbe infatti l’impatto della compromissione di un account Google. Un aggressore che ottenesse contemporaneamente il telefono e le credenziali dell’account potrebbe potenzialmente superare anche il blocco locale.
Per rendere realmente robusta una funzione del genere sarebbe ragionevole aspettarsi ulteriori verifiche: autenticazione a due fattori, passkey, conferma da un altro dispositivo affidabile, controlli contro accessi anomali e periodi di sicurezza dopo la modifica della password.
C’è anche un problema meno evidente: se il secondo fattore dell’account Google è proprio lo smartphone rimasto bloccato, la procedura deve prevedere modalità alternative per evitare un circolo vizioso. Circolo vizioso nel quale alcuni utenti ogni tanto, purtroppo, continuano ad incappare (lo abbiamo spiegato nell’articolo citato in precedenza).