Weaver

Il livello di astrazione hardware (HAL) Weaver (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 utente sicura. L'implementazione di Weaver HAL 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.

Componenti

Weaver è composto da tre componenti:

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

Interfaccia

L'interfaccia di Weaver presenta un array di slot persistenti di dimensioni fisse, 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 alla chiave memorizzata.

L'interfaccia di Weaver è costituita da:

  • getConfig(): recupera il numero di slot, le dimensioni della chiave e le dimensioni del valore supportati dall'implementazione.
  • write(): sovrascrive lo slot specificato con una nuova coppia chiave-valore. Questa operazione è atomica e rende i dati precedenti irrecuperabili in modo permanente 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 dalla TA) non è attivo e la chiave fornita corrisponde esattamente alla chiave memorizzata.

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 utente. Per ogni utente sul dispositivo, LockSettingsService gestisce uno slot Weaver:

  • Chiave dello slot (weaverKey): un hash dell'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.

weaverSecret è progettato per essere recuperato solo da:

  • Fornendo la weaverKey corretta alla TA Weaver all'interno della sua policy di limitazione della frequenza.
  • Compromettendo l'ambiente sicuro in cui viene eseguita la TA Weaver. Questa operazione è intenzionalmente molto difficile.

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

Weaver vs. Gatekeeper

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

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

Perché passare a Weaver?

Con l'introduzione dei token di reimpostazione del passcode sicuro in Android 8.1, la "password sintetica" è diventata il secret crittografico principale. I due ruoli descritti sopra vengono ora gestiti da registrazioni Gatekeeper separate, una per l'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 il supporto per le implementazioni basate su elementi sicuri (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 implementarla perché l'interfaccia supporta un numero illimitato di registrazioni.
Hardware Ottimizzato per gli elementi sicuri, ma funziona anche nei TEE. Efficacemente solo TEE. L'implementazione in un elemento sicuro 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 errati ed 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 le modifiche LSKF in modo atomico. Tutti i dati utente potrebbero andare persi se si verifica un problema durante la modifica dell'LSKF.

Codice di riferimento

Il codice di riferimento per le implementazioni di Weaver negli elementi sicuri compatibili con ISO/IEC7816-4 è disponibile in AOSP: external/libese/.

Test

Per convalidare un'implementazione di Weaver, utilizza VtsHalWeaverTargetTest: 

atest VtsHalWeaverTargetTest

oppure:

vts-tradefed run vts -m VtsHalWeaverTargetTest