Android protegge i dati utente, inclusi lo spazio di archiviazione criptato con le credenziali e le chiavi Keystore associate all'autenticazione, con fattori di conoscenza della schermata di blocco (LSKF) configurati dall'utente, come PIN, sequenze e password. In genere, gli LSKF sono valori a bassa entropia, come PIN a 4 o 6 cifre, quindi è necessaria la protezione dagli attacchi di forza bruta.
Android utilizza limitatori di frequenza Trusted Execution Environment (TEE) o Secure Element (SE) per rallentare e, se vengono effettuati tentativi sufficienti, bloccare gli attacchi di forza bruta agli LSKF. Il CDD 9.11 specifica i requisiti e le raccomandazioni di sicurezza minimi per i limitatori di frequenza LSKF. Android 16 QPR2 e versioni successive implementano policy di limitazione di frequenza significativamente più efficaci rispetto alle versioni precedenti di Android. Per maggiori dettagli, vedi Policy di limitazione di frequenza predefinita più efficace in Android 16 QPR2 e versioni successive.
Android 17 e versioni successive utilizzano una limitazione di frequenza della schermata di blocco predefinita più efficace rispetto alle versioni precedenti. In rari casi, gli utenti possono riscontrare timeout della schermata di blocco lunghi, pertanto Android 17 e versioni successive forniscono i seguenti feedback utente migliorati sulla schermata di blocco.
- Formattazione dell'ora migliorata: la schermata di blocco mostra i timeout di un minuto o più utilizzando unità di tempo più grandi per una migliore leggibilità, ad esempio Riprova tra 30 minuti anziché Riprova tra 1800 secondi.
- Shortlink di recupero: la schermata di blocco mostra uno shortlink
(per impostazione predefinita g.co/android/unlock) per aiutare gli utenti a trovare
le opzioni di recupero su un altro dispositivo. Questo link è configurabile tramite la
config_lockscreenLockoutShortlinkrisorsa. - Feedback sui tentativi duplicati: sui dispositivi con un'implementazione di Weaver, il sistema visualizza un messaggio univoco quando viene inserita una risposta errata duplicata. Questo feedback specifico non è disponibile sui dispositivi solo Gatekeeper, in quanto non forniscono codici di risposta separati per le risposte errate e altri errori di verifica.
- Gestione coerente dell'inserimento delle credenziali: la schermata di blocco disattiva il tastierino per l'inserimento del PIN se il dispositivo utilizza una credenziale PIN, in modo simile all'inserimento delle credenziali di password e sequenza.
Il metodo LockPatternUtils#getLockoutAttemptDeadline(int) è stato rinominato in LockPatternUtils#getLockoutEndTime(int) e fornisce l'ora di fine del blocco da una cache gestita dal sistema. Questo aggiornamento risolve un problema per cui venivano memorizzati nella cache solo per istanza LockPatternUtils, mostrando erroneamente nessun timeout attivo se ne veniva attivato uno utilizzando un'altra istanza. Gli sviluppatori di prompt delle credenziali di sistema, come le attività della schermata di blocco e delle impostazioni, devono aggiornarli per verificare i timeout esistenti prima di consentire ulteriori tentativi.
Sbloccare i dati utente protetti con gli LSKF
LockSettingsService
gestisce l'archiviazione e la verifica degli LSKF. Un utente ha un solo LSKF attivo alla volta. L'assegnazione di un nuovo LSKF invalida quello precedente e avvia la policy di limitazione di frequenza dall'inizio.
Un limitatore di frequenza principale nel TEE o SE, uno di Gatekeeper
o Weaver, applica la limitazione di frequenza per
l'LSKF attivo. LockSettingsService preferisce Weaver quando è disponibile un'implementazione.
I dati utente protetti vengono sbloccati solo quando viene fornito l'LSKF corretto al limitatore di frequenza principale. Se l'LSKF non è corretto, il limitatore di frequenza incrementa un contatore di errori e applica un timeout dopo un determinato numero di errori. Durante un timeout, rifiuta tutte le risposte e fornisce il timeout rimanente.
Policy di limitazione di frequenza predefinita più efficace in Android 16 QPR2 e versioni successive
Il CDD 9.11 richiede la limitazione di frequenza LSKF in Android 6 e versioni successive. Storicamente, la policy di limitazione di frequenza richiesta è stata piuttosto permissiva. Ad esempio, un'implementazione che soddisfa i requisiti minimi di Android 16 consente fino a 10 risposte nel primo minuto, 20 in 6 minuti, 50 in 25 minuti, 110 in 24 ore e 1800 risposte in 5 anni.
Sebbene questa policy sia ragionevolmente sicura per gli LSKF scelti in modo uniforme e casuale, in pratica gli utenti non scelgono gli LSKF in modo uniforme e casuale. Alcuni LSKF si verificano molto più spesso di altri. Gli autori di attacchi possono ottenere una percentuale di successo significativa provando gli LSKF in ordine di frequenza decrescente.
Ad esempio, lo studio This PIN Can Be Easily Guessed ha rilevato una percentuale di successo del 16,2% per la risposta ai PIN reali dopo 100 risposte e del 35,5% per le sequenze. Gli autori di attacchi che conoscono informazioni specifiche dell'utente, come i compleanni, possono ottenere percentuali di successo ancora più elevate.
Pertanto, Android 16 QPR2 e versioni successive forniscono una policy di limitazione di frequenza LSKF predefinita più efficace. Questa policy consente fino a 6 risposte nel primo minuto, 7 in 6 minuti, 8 in 25 minuti, 12 in 24 ore e 19 in 5 anni. Dopo 20 risposte errate, non sono consentite ulteriori risposte. La pianificazione completa dei timeout è riportata nella tabella seguente. È soggetta a modifiche nelle versioni future di Android.
| Numero di risposte errate | Timeout dopo la risposta errata |
|---|---|
| 0 | Non applicabile |
| 1-4 | 0 secondi |
| 5 | 1 minuto |
| 6 | 5 minuti |
| 7 | 15 minuti |
| 8 | 30 minuti |
| 9 | 90 minuti |
| 10 | 4 ore |
| 11 | 12 ore |
| 12 | 36 ore |
| 13 | 4 giorni |
| 14 | 13 giorni |
| 15 | 41 giorni |
| 16 | 123 giorni |
| 17 | 1 anno |
| 18 | 3 anni |
| 19 | 9 anni |
| 20+ | Non sono consentite ulteriori risposte |
Limitatori di frequenza aggiornati
Android 16 QPR2 e versioni successive includono implementazioni aggiornate di Gatekeeper e Weaver che applicano la policy di limitazione di frequenza nella tabella.
Limitatore di frequenza software
Android 16 QPR2 e versioni successive includono un limitatore di frequenza secondario facoltativo, SoftwareRateLimiter.
Viene implementato nel server di sistema e consente ai dispositivi di offrire una policy di limitazione di frequenza più efficace quando
non è possibile aggiornare il TEE o il SE.
Configura SoftwareRateLimiter in modalità di applicazione tramite il config_softwareLskfRateLimiterEnforcing
valore di configurazione. In modalità di applicazione, SoftwareRateLimiter applica la policy di limitazione di frequenza contemporaneamente al limitatore di frequenza principale. Per un determinato numero di risposte errate, il timeout è il più lungo tra quello richiesto dal limitatore di frequenza principale e quello richiesto da SoftwareRateLimiter.
In modalità non di applicazione, SoftwareRateLimiter passa tutte le richieste di verifica al limitatore di frequenza principale senza applicare una policy di limitazione di frequenza secondaria.
Rilevamento delle risposte duplicate
Per migliorare l'usabilità e consentire l'utilizzo di una policy di limitazione di frequenza più efficace, Android 16 QPR2 e versioni successive supportano il rilevamento delle risposte duplicate. Quando è attivato, gli utenti non vengono penalizzati per aver inserito più volte lo stesso LSKF errato.
A volte, gli utenti legittimi inseriscono più volte lo stesso LSKF errato. Se vengono conteggiati come più risposte, si verificano timeout non necessari. Gli autori di attacchi competenti non tentano un determinato LSKF più di una volta. Una policy che non conteggia le risposte duplicate migliora l'usabilità dell'inserimento degli LSKF per gli utenti legittimi senza semplificare la risposta agli LSKF per gli autori di attacchi competenti, consentendo l'applicazione di policy di limitazione di frequenza più efficaci. È meno probabile che gli utenti legittimi riscontrino un timeout, poiché l'utente deve inserire 5 risposte errate univoche anziché 5 risposte errate, inclusi i duplicati.
Sui dispositivi con Android 16 QPR2 e versioni successive, un'implementazione di Weaver e SoftwareRateLimiter configurato in modalità di applicazione, le risposte duplicate vengono rilevate e rifiutate prima di essere passate a Weaver. Questi rifiuti non aumentano il numero di risposte errate. In memoria vengono monitorate fino a 5 risposte errate univoche. Se il tracker è pieno, viene eliminato quello meno recente per fare spazio. Tutte le risposte monitorate vengono eliminate 5 minuti dopo l'ultima risposta errata non monitorata.
Gatekeeper non separa le risposte errate da altri errori di verifica, pertanto SoftwareRateLimiter non supporta il rilevamento delle risposte duplicate quando Gatekeeper è il limitatore di frequenza principale.
Gli implementatori di Weaver possono scegliere di supportare il rilevamento delle risposte duplicate nell'implementazione di Weaver.