Weaver

Il livello di astrazione hardware (HAL) (IWeaver.aidl), introdotto in Android 8.1, fornisce un'interfaccia sicura per l'autenticazione utente con il fattore di conoscenza della schermata di blocco (LSKF), ad esempio PIN, sequenza e password.

Weaver sostituisce la funzionalità di verifica LSKF di Gatekeeper. Tuttavia, Gatekeeper viene ancora utilizzato per generare token di autenticazione hardware.

In Android 9 e versioni successive, CDD 9.11.2 richiede che i dispositivi che supportano StrongBox forniscano hardware sicuro dedicato che supporti l'autenticazione sicura dell'utente. L'implementazione dell'HAL Weaver utilizzando questo hardware sicuro soddisfa il requisito di "autenticazione utente sicura".

Sui dispositivi senza un Secure Element (SE) dedicato, Weaver può comunque essere implementato in un Trusted Execution Environment (TEE) come Trusty.

In Android 17 e versioni successive, l'implementazione di Weaver è fortemente consigliata anche sui dispositivi senza un Secure Element dedicato.

Componenti

Weaver è costituito da tre componenti:

  • Interfaccia Weaver AIDL (IWeaver): La specifica formale dell'HAL. Android 13 e versioni precedenti utilizzavano HIDL anziché AIDL.
  • Servizio Weaver Hardware Abstraction Layer (HAL):Un processo Android specifico del fornitore che implementa l'interfaccia IWeaver.
  • Applicazione attendibile (TA) Weaver: La logica di base in esecuzione in un ambiente sicuro. Esegue la verifica LSKF e applica la limitazione della frequenza. Il servizio HAL comunica con il TA utilizzando un canale sicuro specifico dell'implementazione.

Interfaccia

L'interfaccia di Weaver presenta un array di dimensioni fisse di slot persistenti, ognuno contenente una chiave e un valore di dimensioni fisse. Ogni slot è identificato dal suo ID, un numero intero nell'intervallo [0, numSlots - 1]. Il valore di uno slot è accessibile solo quando viene fornita una chiave corrispondente a quella memorizzata.

L'interfaccia di Weaver è costituita principalmente da:

  • getConfig(): recupera il numero di slot, le dimensioni della chiave e le dimensioni del valore supportate dall'implementazione.
  • write(): Sovrascrive lo slot specificato con una nuova coppia chiave-valore. Questa operazione è atomica e rende i dati precedenti permanentemente irrecuperabili (eliminazione sicura).
  • read(): tenta di recuperare il valore dello slot specificato. Questa operazione ha esito positivo solo quando il timeout di limitazione della frequenza (applicato dal TA) non è attivo e la chiave fornita corrisponde esattamente a quella memorizzata.
  • warmUp(): in Android 17 e versioni successive, indica che una lettura o una scrittura potrebbe avvenire a breve.

Per la specifica completa dell'interfaccia, consulta IWeaver.aidl.

Utilizzo da parte di Android

Quando è disponibile un'implementazione di Weaver, LockSettingsService nel server di sistema Android la utilizza per proteggere i dati degli utenti. Per ogni utente sul dispositivo, LockSettingsService gestisce uno slot Weaver:

  • Chiave slot (weaverKey): un hash della LSKF dell'utente. Se l'utente non ha un blocco schermo, viene utilizzata una stringa predefinita.
  • Valore dello slot (weaverSecret): un secret crittografico ad alta entropia generato in modo casuale.

Il weaverSecret è progettato per essere recuperato solo da:

  • Fornendo il weaverKey corretto a Weaver TA entro i limiti della sua policy di limitazione di frequenza.
  • Compromettere l'ambiente sicuro in cui viene eseguito Weaver TA. Questo è intenzionalmente molto difficile.

LockSettingsService utilizza sia weaverKey sia weaverSecret per criptare la password sintetica dell'utente. Poiché la password sintetica protegge l'archivio con crittografia delle credenziali (CE) dell'utente per la crittografia basata su file (FBE) e le chiavi associate all'autenticazione nell'Android Keystore, i dati rimangono inaccessibili finché Weaver non rilascia il segreto.

In Android 17 e versioni successive, LockSettingsService chiama il metodo warmUp() di Weaver quando si inizia a inserire la LSKF. Le implementazioni di Weaver possono utilizzare questo indicatore per far uscire l'hardware sicuro da uno stato di basso consumo energetico e ridurre la latenza per una richiesta read() imminente.

Weaver contro Gatekeeper

Storicamente, l'HAL Gatekeeper svolgeva due ruoli distinti in una singola chiamata verify():

  1. Verifica:controllo della LSKF, con limitazione della frequenza imposta da TEE.
  2. Attestazione:emissione di un HardwareAuthToken per notificare a KeyMint (in precedenza Keymaster) che l'autenticazione LSKF è riuscita.

Perché il passaggio a Weaver?

Con l'introduzione dei token di reimpostazione sicura del passcode in Android 8.1, la password sintetica è diventata il segreto crittografico principale. I due ruoli descritti sopra vengono gestiti da registrazioni Gatekeeper separate, una per la LSKF in userId + 100000 e una per la password sintetica in userId.

Weaver è stato introdotto per assumere il primo ruolo, utilizzando un'interfaccia HAL più semplice con supporto per implementazioni basate su Secure Element (SE).

Funzionalità Weaver Gatekeeper
Eliminazione sicura L'eliminazione sicura è obbligatoria ed è facile da implementare perché l'interfaccia utilizza un numero fisso di slot di dimensioni fisse. L'eliminazione sicura non è obbligatoria ed è difficile da implementare perché l'interfaccia supporta un numero illimitato di registrazioni.
Hardware Ottimizzato per gli SE, ma funziona anche nei TEE. Efficace solo per TEE. L'implementazione in un SE non offre un vantaggio in termini di sicurezza con la progettazione attuale.
Gestione degli errori Codici di errore più chiari. Codici di errore ambigui. Di conseguenza, la schermata di blocco non distingue tra LSKF errate e errori non correlati.
Atomicità Il codice in LockSettingsService che utilizza Weaver esegue le modifiche LSKF in modo atomico. I nuovi dati vengono scritti in un nuovo slot Weaver e il vecchio slot viene cancellato solo quando è sicuro farlo. Il codice in LockSettingsService che utilizza Gatekeeper non esegue modifiche LSKF in modo atomico. Tutti i dati utente potrebbero andare persi se si verifica un problema durante la modifica della LSKF.

Codice di riferimento

AOSP contiene due implementazioni di riferimento di Weaver:

  • In Android 17 e versioni successive, system/weaver/ contiene un'implementazione di Weaver per ambienti sicuri generali.
  • In Android 8.1 e versioni successive, external/libese/ contiene un'implementazione di Weaver per elementi sicuri compatibili con ISO/IEC7816-4.

Test

Per convalidare un'implementazione di Weaver, utilizza VtsHalWeaverTargetTest: 

atest VtsHalWeaverTargetTest

oppure:

vts-tradefed run vts -m VtsHalWeaverTargetTest