Android protegge i dati utente, inclusi l'archiviazione criptata delle 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. Le LSKF sono in genere valori a bassa entropia, come PIN a 4 o 6 cifre, pertanto è necessaria la protezione dagli attacchi di forza bruta.
Android utilizza i limitatori di velocità Trusted Execution Environment (TEE) o Secure Element (SE) per rallentare e, dopo un numero sufficiente di tentativi, bloccare gli autori di attacchi di forza bruta sulle LSKF. CDD 9.11 specifica i requisiti e i consigli minimi di sicurezza per i limitatori di velocità LSKF. Android 16 QPR2 e versioni successive implementano criteri di limitazione della frequenza molto più rigidi rispetto alle versioni precedenti di Android. Per maggiori dettagli, vedi Policy di limitazione della frequenza predefinita più rigorosa in Android 16 QPR2 e versioni successive.
Sbloccare i dati utente protetti con le LSKF
LockSettingsService
gestisce l'archiviazione e la verifica delle LSKF. Un utente ha un solo LSKF attivo alla volta. L'assegnazione di una nuova chiave LSKF
invalida quella precedente e riavvia le norme di limitazione della frequenza dall'inizio.
Un limitatore di velocità principale nel TEE o SE, Gatekeeper
o Weaver,applica la limitazione della velocità per
l'LSKF attivo. LockSettingsService preferisce Weaver quando è disponibile un'implementazione.
I dati utente protetti vengono sbloccati solo quando viene fornito il valore LSKF corretto al limitatore di velocità principale. Se LSKF non è corretto, il rate limiter incrementa un contatore di errori e impone un timeout dopo un determinato numero di errori. Durante un timeout, rifiuta tutti i tentativi e fornisce il timeout rimanente.
Policy di limitazione di frequenza predefinita più rigorosa in Android 16 QPR2 e versioni successive
CDD 9.11 richiede la limitazione della frequenza LSKF in Android 6 e versioni successive. Storicamente, le norme di limitazione della frequenza richieste sono state piuttosto indulgenti. Ad esempio, un'implementazione che soddisfa i requisiti minimi di Android 16 consente fino a 10 tentativi nel primo minuto, 20 in 6 minuti, 50 in 25 minuti, 110 in 24 ore e 1800 tentativi in 5 anni.
Sebbene questo criterio sia ragionevolmente sicuro per le LSKF scelte in modo uniforme e casuale, in pratica gli utenti non scelgono le LSKF in modo uniforme e casuale. Alcuni LSKF si verificano molto più spesso di altri. Gli autori degli attacchi possono ottenere un tasso di successo significativo provando le LSKF in ordine di frequenza decrescente.
Ad esempio, lo studio This PIN Can Be Easily Guessed ha rilevato un tasso di successo del 16,2% per l'ipotesi di PIN reali dopo 100 tentativi e del 35,5% per i pattern. Se gli autori degli attacchi conoscono informazioni specifiche dell'utente, come la data di nascita, possono ottenere tassi di successo ancora più elevati.
Pertanto, Android 16 QPR2 e versioni successive forniscono una policy di limitazione della frequenza LSKF predefinita più efficace. Queste norme consentono fino a 6 tentativi nel primo minuto, 7 in 6 minuti, 8 in 25 minuti, 12 in 24 ore e 19 in 5 anni. Dopo 20 tentativi errati, non sono consentiti ulteriori tentativi. Il programma completo di timeout è riportato nella tabella seguente. È soggetto a modifiche nelle versioni future di Android.
| Conteggio di ipotesi errate | Timeout dopo un tentativo errato |
|---|---|
| 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 consentiti altri tentativi |
Limitatori di frequenza aggiornati
Android 16 QPR2 e versioni successive includono implementazioni aggiornate di Gatekeeper e Weaver che applicano il criterio di limitazione della frequenza nella tabella.
Limitatore di frequenza software
Android 16 QPR2 e versioni successive includono un limitatore di velocità secondario facoltativo, SoftwareRateLimiter..
È implementato nel server di sistema e consente ai dispositivi di offrire una policy di limitazione della velocità più rigorosa quando
il TEE o l'SE non possono essere aggiornati.
Configura SoftwareRateLimiter in modalità di applicazione tramite il valore di configurazione config_softwareLskfRateLimiterEnforcing. In modalità di applicazione, SoftwareRateLimiter applica i propri criteri di limitazione di frequenza contemporaneamente al limitatore di frequenza principale. Per un determinato conteggio di tentativi errati, il timeout è
il più lungo tra quello richiesto dal limitatore di frequenza principale e quello richiesto da SoftwareRateLimiter.
In modalità non applicativa, SoftwareRateLimiter trasmette tutte le richieste di verifica al
limiter di velocità principale senza applicare una policy di limitazione della velocità secondaria.
Rilevamento di tentativi duplicati
Per migliorare l'usabilità e consentire l'utilizzo di una policy di limitazione della frequenza più efficace, Android 16 QPR2 e versioni successive supportano il rilevamento di tentativi duplicati. Se abilitata, 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. Ciò comporta timeout non necessari se vengono conteggiati come tentativi multipli. Gli aggressori capaci non tentano più di una volta una determinata LSKF. Un criterio che non conteggia i tentativi duplicati migliora l'usabilità dell'inserimento delle LSKF per gli utenti legittimi senza semplificare l'indovinare delle LSKF per gli autori di attacchi capaci, consentendo l'applicazione di criteri di limitazione della frequenza più rigorosi. È meno probabile che gli utenti legittimi riscontrino un timeout, poiché l'utente deve inserire 5 tentativi errati unici anziché 5 tentativi errati inclusi i duplicati.
Sui dispositivi con Android 16 QPR2 e versioni successive, un'implementazione Weaver e SoftwareRateLimiter
configurata in modalità di applicazione, i tentativi duplicati vengono rilevati e rifiutati prima di essere passati a
Weaver. Questi rifiuti non aumentano il conteggio dei tentativi errati. Vengono memorizzate fino a 5 ipotesi errate uniche. Se il tracker è pieno, quello meno recente viene eliminato per fare spazio. Tutte
le ipotesi tracciate vengono eliminate 5 minuti dopo l'ultima ipotesi errata non tracciata.
Gatekeeper non separa i tentativi errati da altri errori di verifica, pertanto SoftwareRateLimiter
non supporta il rilevamento di tentativi duplicati quando Gatekeeper è il limitatore di velocità principale.
Gli implementatori di Weaver possono scegliere di supportare il rilevamento di ipotesi duplicate nell'implementazione di Weaver.