Demistificare gli strumenti di sblocco dei telefoni: Una panoramica tecnica.

Questo post è la trascrizione scritta di una presentazione intitolata Phone unlocking tools and where to find them che abbiamo tenuto in forma privata a diversi eventi e organizzazioni, tra cui Primavera Hacker 25, la Freedom of the Press Foundation e il Public Interest Technology Group. Fornisce una panoramica tecnica di come gli strumenti forensi commerciali compromettono i dispositivi mobili, concentrandosi sulle specifiche superfici di attacco sfruttate in ciascuna fase del ciclo di vita del dispositivo. Ulteriori post si concentreranno sull’analisi di campioni e sulle difese. Si vedano anche i post precedenti di questa serie:

• Cellebrite e l’uso ordinario della sorveglianza digitale in Italia
• Qualche informazione su Cellebrite: Un po’ di storia
• Qualche informazione su Cellebrite: Supporto Android aggiornato a febbraio 2025

Introduzione #

Gli strumenti commerciali di sblocco dei telefoni non sono magici. Sfruttano le stesse classi di vulnerabilità che i ricercatori di sicurezza pubblicano alle conferenze e negli articoli accademici. Ciò che li rende utili non è la novità delle tecniche, ma l’automazione e la vastità dei dispositivi supportati: acquisire o sviluppare exploit per ogni combinazione di hardware e software, raggiungere un certo grado di stabilità e confezionare il tutto in flussi di lavoro automatizzati che richiedono competenze minime da parte dell’operatore.

Questo post si propone di demistificare le basi tecniche di questi strumenti. I vettori di attacco disponibili per un analista forense con accesso fisico a un dispositivo sono vincolati da limiti ben noti: la boot chain, Il trusted execution environment (TEE), il secure element (quando presente) e lo stack dei driver delle periferiche del kernel. Questo post descrive principalmente gli aspetti interni di Android, tuttavia i concetti equivalenti su iOS sono tecnicamente simili.

Gran parte della ricerca di base qui citata si basa su materiale di Quarkslab, le cui ampie pubblicazioni su TEE, Titan M di Google e l’architettura di cifrature di Android sono state preziose per comprendere questi strumenti. Il loro lavoro, insieme ai rapporti di Amnesty International Security Lab e di altre ONG, e all’analisi del progetto GrapheneOS, fornisce la base empirica per le affermazioni contenute in questo post.

Architettura di sicurezza hardware #

Prima di esaminare i vettori di attacco, è necessario comprendere l’architettura di sicurezza hardware dei moderni dispositivi Android. Le sezioni seguenti descrivono i componenti che gli strumenti forensi devono in ultima analisi compromettere o aggirare.

Il System-on-Chip: Normal World e Secure World #

I moderni processori mobili basati su ARM implementano TrustZone™, un’estensione di sicurezza hardware che partiziona il processore in due ambienti di esecuzione: il Normal World e il Secure World. Il Normal World esegue il sistema operativo Android, le applicazioni utente e il kernel Linux. Il Secure World esegue un sistema operativo separato e minimale, il Trusted OS, insieme a piccole applicazioni specializzate note come Trusted Application (TA).

I due ambienti condividono gli stessi core fisici del processore ma sono isolati a livello hardware: il Normal World non può leggere o scrivere direttamente la memoria del Secure World. La comunicazione tra i due avviene attraverso il monitor, un componente software che opera al livello di privilegio più elevato (EL3 su ARMv8), che gestisce i cambi di contesto attivati dalle istruzioni Secure Monitor Call (SMC). Ogni core fisico del processore fornisce effettivamente due core virtuali, con il bit Non-Secure nel Secure Configuration Register che determina quale ambiente è attivo in un dato momento.

Il Trusted OS ospita servizi di sicurezza critici. Due sono direttamente rilevanti per lo sblocco dei dispositivi:

• Gatekeeper: responsabile della verifica delle credenziali utente (PIN, password, sequenza). Implementa il rate-limiting per limitare i tentativi di brute-force e, in caso di autenticazione riuscita, emette un token di autenticazione firmato.
• Keymaster: il servizio di gestione delle chiavi che memorizza e opera sulle chiavi crittografiche. Alcune chiavi sono authentication-bound, ovvero possono essere utilizzate solo dopo che Gatekeeper ha emesso un token valido.

Diversi produttori di SoC forniscono implementazioni diverse di TrustZone™. Google (e AOSP in generale) utilizza TrustyOS; Qualcomm utilizza QSEE; Samsung utilizza TEEGRIS (sia su SoC Exynos che MediaTek nei dispositivi Samsung); Huawei utilizza TrustedCore; Kinibi di Trustonic è utilizzato su SoC MediaTek e Exynos. Le proprietà di sicurezza variano tra le diverse implementazioni.

Il Secure Element #

Un Secure Element (SE) è un chip hardware fisicamente separato e resistente alle manomissioni che fornisce un ulteriore livello di sicurezza oltre al TEE. A differenza del Secure World, che funziona sullo stesso SoC del Normal World, un Secure Element è un processore indipendente con la propria boot chain, il proprio firmware e la propria archiviazione di chiavi crittografiche.

Nell’ecosistema Android, il Secure Element è esposto attraverso l’API StrongBox (introdotta in Android 9). I telefoni Pixel di Google, a partire dal Pixel 3, includono il chip Titan M come Secure Element, che è stato poi sostituito con il Titan M2 dal Pixel 6 in poi. Sui dispositivi Apple, l’equivalente è il Secure Enclave Processor (SEP).

Il ruolo del Secure Element nella crittografia del dispositivo è quello di custodire le chiavi di cifratura delle chiavi e di imporre il rate-limiting per la verifica delle credenziali in hardware che il SoC principale non può manomettere, anche se completamente compromesso. Questa è una distinzione importante: su un dispositivo senza Secure Element, compromettere il TEE è sufficiente per estrarre o aggirare le chiavi derivate dalle credenziali. Su un dispositivo con Secure Element, l’attaccante deve inoltre compromettere un chip separato.

Purtroppo, solo i dispositivi di fascia alta includono tipicamente un Secure Element. La maggior parte dei dispositivi di fascia media e bassa si affida esclusivamente al TEE per la protezione delle credenziali. Questo divario architetturale è il singolo fattore più importante nel determinare le possibilità di un dispositivo di resistere allo sblocco forense quando è spento.

La boot chain #

La boot chain stabilisce una chain of trust dall’hardware immutabile al sistema operativo in esecuzione. Ogni fase verifica l’integrità della successiva prima di eseguirla.

La chain procede come segue:

1. Boot ROM: il primo codice eseguito all’accensione. È scritto nel silicio in fase di produzione ed è, in linea di principio, immutabile e non aggiornabile (con alcune moderne eccezioni per il rilascio di patch per le vulnerabilità). La Boot ROM verifica e carica la fase successiva (il preloader o il bootloader secondario). Costituisce la radice di fiducia hardware.

2. Preloader/Secondary Bootloader (BL2): caricato e verificato dalla Boot ROM. Sui SoC MediaTek, è spesso chiamato preloader. Inizializza l’hardware, carica il Trusted OS nel Secure World e carica il bootloader principale nel Normal World.

3. Trusted OS: caricato nel Secure World dal preloader. Ospita Gatekeeper, Keymaster e altre Trusted Application. La sua integrità è verificata dal preloader come parte della boot chain sicuro.

4. Bootloader (BL3): il bootloader del Normal World (ad es. Little Kernel su MediaTek, ABL su Qualcomm). Impone Android Verified Boot (AVB), le protezioni anti-rollback e i controlli sullo stato del dispositivo prima di caricare il kernel Android.

5. Sistema operativo Android: il kernel Linux e lo userspace. Il Verified Boot (dm-verity) garantisce l’integrità delle partizioni di sistema a runtime.

Quando è presente un Secure Element, esso esegue la propria boot chain indipendente in parallelo: Boot ROM → Bootrom EXT → Bootloader → OS. La boot chain del Secure Element è completamente separata da quella del SoC, fornendo il massimo isolamento.

Se una qualsiasi fase della boot chain viene compromessa, tutte le fasi successive non sono più affidabili. Ecco perché le vulnerabilità nella Boot ROM sono così devastanti: sono spesso non correggibili, compromettono tutto ciò che è costruito sopra di esse e colpiscono ogni dispositivo che utilizza quel silicio vulnerabile per l’intera durata della sua vita hardware.

Crittografia dei dati Android #

Per comprendere i vettori di attacco è necessario capire ciò che l’attaccante sta cercando di ottenere: le chiavi di decrittazione dei dati dell’utente.

Full Disk Encryption vs. File-Based Encryption #

Android ha utilizzato due schemi di crittografia nel corso della sua storia:

Full Disk Encryption (FDE) cifra l’intera partizione dati con una singola chiave, derivata dalle credenziali dell’utente. La chiave deve essere disponibile prima che il sistema operativo possa avviarsi, quindi all’utente viene richiesto il PIN o la password all’avvio. FDE era l’impostazione predefinita fino ad Android 6 ed è stata deprecata a partire da Android 13.

File-Based Encryption (FBE) cifra i singoli file con chiavi diverse, consentendo un controllo degli accessi più granulare. FBE è l’impostazione predefinita da Android 7 ed è obbligatoria da Android 10. Suddivide l’archiviazione in due classi:

• Device Encrypted (DE) storage: disponibile immediatamente dopo l’avvio, prima dell’autenticazione dell’utente. Utilizzato per funzionalità critiche del sistema (sveglie, dialer telefonico, Direct Boot). La chiave DE è derivata senza le credenziali dell’utente.
• Credential Encrypted (CE) storage: disponibile solo dopo che l’utente si è autenticato per la prima volta dopo l’avvio. Qui risiedono tutti i dati dell’utente: messaggi, foto, dati delle applicazioni. La chiave CE è derivata dalle credenziali dell’utente, rafforzata tramite scrypt e protetta da chiavi custodite nel TEE (e, quando presente, nel Secure Element).

Derivazione della chiave CE: Il ruolo delle credenziali #

La spiegazione di Quarkslab Android Data Encryption in depth fornisce l’analisi pubblica più dettagliata di come viene derivata la chiave CE. Il processo, in forma semplificata, procede come segue:

1. Le credenziali dell’utente (PIN, password o sequenza) vengono rafforzate usando scrypt, una funzione di derivazione delle chiavi ad alta intensità di memoria, con parametri e salt memorizzati in file protetti da DE sotto /data/system_de/<uid>/spblob. Il passaggio con scrypt è intenzionalmente lento: introduce un ritardo trascurabile per un singolo tentativo di autenticazione, ma rende il brute-force computazionalmente costoso.

2. Le credenziali rafforzate vengono combinate con altro materiale per formare un password blob, che viene inviato alla Trusted Application Gatekeeper nel TEE. Gatekeeper verifica il blob confrontandolo con un password handle memorizzato utilizzando un HMAC con una chiave interna. Se la verifica ha successo, Gatekeeper emette un token di autenticazione firmato.

3. Il token di autenticazione viene presentato a Keymaster, che lo utilizza per sbloccare una chiave authentication-bound. Questa chiave viene utilizzata per eseguire la prima decrittazione della Synthetic Password, un segreto intermedio memorizzato in forma cifrata nel filesystem.

4. La Synthetic Password viene decifrata una seconda volta utilizzando una chiave derivata dalle credenziali dell’utente (l’applicationId). Questa seconda decrittazione utilizza AES-GCM, che fornisce cifratura autenticata: se vengono fornite credenziali errate, il tag GCM non corrisponderà e la decrittazione fallirà. Questo è il controllo crittografico che in ultima analisi lega la chiave CE alle credenziali corrette.

5. Dalla Synthetic Password, il sistema deriva le chiavi di crittografia dei file CE utilizzate dal sottosistema fscrypt del kernel Linux per decifrare i singoli file.

L’osservazione importante è che le credenziali dell’utente sono crittograficamente incorporate nella processo di key derivation. Non esiste modo di aggirarle attraverso attacchi puramente software: un attaccante che compromette il TEE può aggirare il controllo del token di autenticazione, ma deve comunque effettuare il brute-force delle credenziali attraverso scrypt per ottenere le chiavi corrette.

Key derivation con un Secure Element (Weaver) #

Sui dispositivi con un Secure Element, il processo di derivazione delle chiavi include un passaggio aggiuntivo. Invece di affidarsi esclusivamente a Gatekeeper nel TEE, il sistema utilizza Weaver, un servizio in esecuzione sul Secure Element. Weaver memorizza un valore segreto che viene sbloccato solo dopo la corretta verifica delle credenziali e impone il proprio rate-limiting indipendente.

Questo significa che anche se un attaccante compromette completamente il TEE, o un’altra delle Trusted Applications come descritto da Synacktiv nel blogpost su Kinibi TEE, non può estrarre il segreto di Weaver o aggirare il suo throttling, se implementato correttamente. Il brute-force deve procedere online, alla velocità consentita dal Secure Element, che, per un dispositivo come il Pixel con Titan M, significa backoff esponenziale.

Vettori di attacco #

Con l’architettura definita, possiamo ora mappare le specifiche superfici di attacco sfruttabili. Queste si dividono in due categorie principali, corrispondenti a due stati del dispositivo: spento o acceso ma mai sbloccato (BFU), e acceso e precedentemente sbloccato (AFU).

Attacchi BFU su dispositivi senza Secure Element #

La forma più completa di attacco BFU prende di mira la boot chain stessa. Se un attaccante riesce a compromettere la Boot ROM o il preloader, può spezzare l’intera catena di fiducia, incluso il TEE.

L’attacco procede come segue:

1. Exploitation della Boot ROM: l’attaccante si collega al dispositivo via USB e sfrutta una vulnerabilità nella Boot ROM (o utilizza una modalità di download/recovery specifica del produttore, come la Download Mode di MediaTek o la modalità EDL di Qualcomm) per ottenere l’esecuzione di codice prima che il bootloader si avvii.

2. Modifica della boot chain: con accesso a livello di Boot ROM, l’attaccante modifica o sostituisce il preloader per disabilitare la verifica del secure boot delle fasi successive. Questo consente di caricare un Trusted OS modificato e Trusted Application modificate.

3. Modifica del TEE: l’attaccante sostituisce o modifica Gatekeeper affinché accetti qualsiasi credenziale ed emetta token di autenticazione validi indipendentemente dall’input. Modifica o estrae anche le chiavi da Keymaster. Come dimostrato da Quarkslab nel loro proof-of-concept sui dispositivi Samsung A22 (SoC MT6769V e MT6833V), questo ha comportato la modifica del sistema operativo TEEGRIS di Samsung: prima disabilitando la verifica del filesystem root, poi disabilitando la verifica delle firme delle TA, e infine modificando il confronto delle credenziali di Gatekeeper affinché avesse sempre successo.

4. Estrazione del materiale chiave: con un sistema Android rootato e un TEE compromesso, l’attaccante estrae la Synthetic Password cifrata e il risultato di decrittazione intermedio da Keymaster.

5. Brute-force offline: l’attaccante dispone ora di tutto il materiale necessario per il brute-force offline. Il ciclo di brute-force è:

   • Generare una password candidata
   • Rafforzarla attraverso scrypt con i parametri memorizzati
   • Derivare l’applicationId
   • Tentare la decrittazione AES-GCM della Synthetic Password
   • Se il tag GCM corrisponde, le credenziali corrette sono state trovate

Poiché questo brute-force viene eseguito interamente offline, sull’hardware dell’attaccante, è limitato solo dalle risorse computazionali e dalla complessità della password. Un PIN numerico di sei cifre o meno è banalmente recuperabile. Anche PIN numerici più lunghi cedono rapidamente su hardware dedicato. Solo una password alfanumerica forte con simboli offre una resistenza significativa.

I dispositivi MediaTek sono particolarmente vulnerabili a questo attacco. Diversi SoC MediaTek contengono vulnerabilità nella Boot ROM che sono pubblicamente note e sfruttate da strumenti open-source come MTKClient. Poiché il codice della Boot ROM è immutabile, queste vulnerabilità non possono essere corrette: ogni dispositivo che utilizza il silicio interessato è permanentemente compromesso, indipendentemente dalla versione di Android o dal livello delle patch di sicurezza. Il proof-of-concept di Quarkslab ha preso di mira esattamente questa classe di dispositivi, dimostrando l’intera catena dall’exploit della Boot ROM al recupero della chiave CE.

Attacchi BFU su dispositivi con Secure Element #

Quando è presente un Secure Element, la catena di attacco è fondamentalmente più difficile. Anche se l’attaccante riesce a ottenere tutto quanto descritto sopra, non può comunque estrarre il segreto di Weaver dal Secure Element, in circostanze normali. Le probabilità di un exploit del Secure Element sono piuttosto basse, specialmente se distribuito come parte di una suite forense commerciale ampiamente disponibile.

Come anticipato, il Secure Element esegue la propria boot chain indipendente su silicio fisicamente separato. Le sue chiavi non possono essere estratte dal SoC principale e la sua logica di rate-limiting è imposta in hardware che l’attaccante non controlla.

Il risultato è che il brute-force può spesso procedere solo online: ogni tentativo deve interrogare il Secure Element, che impone una qualche forma di backoff. Questo rallenta significativamente l’attacco. Un PIN di dieci cifre che cede in pochi secondi con il brute-force offline può richiedere molto tempo contro un Secure Element correttamente implementato. Una password alfanumerica diventa probabilmente impossibile da forzare.

Ecco perché, secondo la stessa matrice di supporto di Cellebrite di febbraio 2025, le capacità di brute-force non sono generalmente disponibili per i dispositivi Pixel con Titan M. Il Secure Element sta facendo esattamente ciò per cui è stato progettato.

Detto ciò, il Secure Element non è immune alle vulnerabilità. Quarkslab ha dimostrato l’esecuzione di codice sul chip Titan M attraverso la CVE-2022-20233, una scrittura out-of-bounds di un singolo byte nel task Keymaster che poteva essere sfruttata per dirottare il flusso di esecuzione. Questa vulnerabilità è stata corretta, ma dimostra che i Secure Element, pur essendo enormemente più resistenti delle configurazioni basate solo sul TEE, possono comunque avere problemi. Google offre fino a $1,500,000 per vulnerabilità zero-click che affliggono il Pixel Titan M2.

Attacchi AFU: La schermata di blocco è solo interfaccia #

Dopo il primo sblocco, il modello di minaccia cambia completamente. Nello stato AFU, le chiavi di decrittazione CE sono caricate in memoria e vi rimangono. La schermata di blocco non è più una barriera crittografica: è solo un elemento dell’interfaccia utente, una sovrapposizione sullo schermo che impedisce l’interazione ma non cifra nuovamente i dati.

Questo significa che un attaccante in stato AFU non ha bisogno di effettuare il brute-force delle credenziali. Deve ottenere l’esecuzione di codice nel kernel o in un processo privilegiato, a quel punto ha accesso diretto al filesystem decifrato. La schermata di blocco viene aggirata e nessuna crittografia deve essere violata.

La superficie di attacco principale nello stato AFU è l’interfaccia USB. Quando un dispositivo è bloccato ma in stato AFU, il controller USB rimane attivo e espone il kernel del dispositivo a una superficie di attacco considerevole.

Come illustra il diagramma, un emulatore di periferiche collegato alla porta USB di un dispositivo bloccato può interagire con il kernel attraverso circa 200 driver raggiungibili, tra cui MTP (Media Transfer Protocol), MSC (Mass Storage Class), HID (Human Interface Device), Audio e sottosistemi CVC (Communication Voice Class). Ciascuno di questi driver è una potenziale superficie di attacco per vulnerabilità di corruzione della memoria.

L’exploit utilizzato da Cellebrite contro il dispositivo di un attivista serbo nel dicembre 2024, come documentato da Amnesty International, ha tentato di utilizzare almeno tre vulnerabilità nei driver USB del kernel Linux:

• CVE-2024-53104: una vulnerabilità nel driver USB Video Class (UVC).
• CVE-2024-53197: una scrittura out-of-bounds nel driver ALSA USB-audio, attivata quando un dispositivo USB malevolo fornisce un valore bNumConfigurations che eccede la memoria allocata. Questa vulnerabilità riguarda codice legacy presente dal kernel Linux 2.6.26 (2008) ed è stata confermata da CISA come attivamente sfruttata in natura.
• CVE-2024-50302: un memory leak nel sottosistema HID che espone memoria del kernel non inizializzata, incluse chiavi di crittografia e token di autenticazione, durante l’elaborazione di report USB HID appositamente costruiti.

Il dispositivo Cellebrite Turbo Link, un adattatore hardware specializzato che si collega tra la workstation forense e il dispositivo bersaglio, funziona probabilmente come un emulatore di periferiche capace di presentarsi come diversi tipi di dispositivi USB in rapida successione, sondando ciascuna vulnerabilità per ottenere l’esecuzione di codice a livello kernel.

Molti di questi driver USB sono caricati di default e rimangono raggiungibili anche quando il dispositivo è bloccato. Il kernel non distingue tra un accessorio USB legittimo e un emulatore di periferiche malevolo, e questa è la principale debolezza su cui l’exploitation AFU spesso si basa.

Attacchi AFU su dispositivi bloccati nella pratica #

Una volta che l’attaccante ottiene l’esecuzione di codice nel kernel attraverso l’exploitation dei driver USB, la schermata di blocco è irrilevante. L’attaccante può:

• Leggere direttamente il filesystem decifrato, poiché le chiavi CE sono già in memoria
• Eseguire un’estrazione Full File System (FFS) di tutti i dati dell’utente
• Accedere a dati delle applicazioni, messaggi, foto, credenziali e metadati
• Potenzialmente installare backdoor persistenti

Come già sapevamo, un dispositivo in stato AFU è fondamentalmente meno sicuro di un dispositivo in stato BFU, indipendentemente dalla robustezza della password dell’utente o dalla presenza di un Secure Element. Il Secure Element protegge le chiavi derivate dalle credenziali all’avvio; non protegge i dati già decifrati in memoria dopo il primo sblocco.

Ciò è confermato dalla matrice di supporto di Cellebrite di febbraio 2025, che mostra capacità di estrazione AFU anche per dispositivi (inclusi Pixel recenti con Android stock) che resistono agli attacchi BFU. In particolare, secondo la stessa documentazione, GrapheneOS sui dispositivi Pixel resiste all’estrazione AFU, probabilmente grazie alla riduzione della superficie di attacco e alle restrizioni USB implementate oltre Android stock.

Una nota su iOS: checkm8 e USB Restricted Mode #

I dispositivi Apple affrontano superfici di attacco analoghe. L’exploit checkm8, rilasciato pubblicamente nel 2019, prende di mira una vulnerabilità nella Boot ROM non correggibile presente in tutti i dispositivi Apple dall’iPhone 4S all’iPhone X (SoC da A5 ad A11). Come le vulnerabilità nella Boot ROM di MediaTek, checkm8 non può essere corretto tramite aggiornamenti software: ogni dispositivo interessato è permanentemente sfruttabile.

Per i dispositivi Apple più recenti, gli attacchi AFU si basano sull’exploitation via USB. Apple ha introdotto la USB Restricted Mode in iOS 11.4.1 per mitigare questo rischio: se il dispositivo è bloccato da più di un’ora, la porta Lightning o USB-C viene limitata alla sola ricarica, disabilitando le connessioni dati necessarie agli strumenti forensi.

Tuttavia, l’analisi di Quarkslab della CVE-2025-24200 (segnalato da CitizenLab) ha rivelato che la USB Restricted Mode era aggirabile. La vulnerabilità, segnalata da Citizen Lab e corretta in iOS 18.3.1, permetteva a un attaccante con accesso fisico di riabilitare le connessioni dati USB su un dispositivo bloccato sfruttando una falla nel framework Accessibility. Il daemon profiled, che gestisce le impostazioni di gestione del dispositivo, non verificava se il dispositivo fosse bloccato prima di elaborare le richieste di disabilitazione della USB Restricted Mode. In altre parole, la porta USB era solo disabilitata a livello software: qualcosa di semplice come un bug logico nell’applicazione della policy consentiva di riattivarla.

Implicazioni difensive #

I vettori di attacco descritti sopra portano a un chiaro insieme di priorità difensive.

BFU è la migliore difesa #

L’azione singola più efficace di fronte a un potenziale sequestro del dispositivo è spegnere il dispositivo. Questo lo riporta allo stato BFU, dove:

• Lo storage CE è cifrato e le chiavi non sono in memoria
• L’exploitation dei driver USB non può fornire direttamente dati decifrati
• L’attaccante deve compromettere la boot chain e effettuare il brute-force delle credenziali
• Sui dispositivi con Secure Element, il brute-force è limitato in frequenza dall’hardware

Auto-reboot: tornare in BFU automaticamente #

Se un dispositivo non può essere spento manualmente, un meccanismo di riavvio automatico fornisce la seconda migliore difesa. Dopo un periodo configurabile senza autenticazione dell’utente, il dispositivo si riavvia, tornando allo stato BFU e cancellando le chiavi di decrittazione dalla memoria.

GrapheneOS ha implementato questa funzionalità da anni. Apple l’ha introdotta in iOS 18. Android stock sui dispositivi Pixel ha ottenuto una versione limitata in Android 15, ma la sua implementazione rimane meno configurabile e meno aggressiva rispetto a quella di GrapheneOS. La funzionalità è più utile quando il timeout è breve (2-4 ore) e perde il suo valore quando si tratta di più giorni, come imposto da Google probabilmente a seguito di negoziazioni con le forze dell’ordine.

Restrizione della porta USB #

Disabilitare il trasferimento dati USB quando il dispositivo è bloccato elimina direttamente la superficie di attacco AFU descritta sopra. Android 15 introduce opzioni di restrizione USB; iOS dispone della USB Restricted Mode dalla versione 11. GrapheneOS fornisce restrizioni USB più affidabili e configurabili.

Robustezza della password #

L’analisi del brute-force rende il caso delle password forti inequivocabile:

• Un PIN di 4 cifre: banalmente forzabile offline, e forzabile anche online in ore o giorni
• Un PIN di 6 cifre: banalmente forzabile offline; forzabile online in giorni o settimane a seconda dell’implementazione del rate-limiting
• Una sequenza: equivalente o inferiore a un PIN corto in termini di entropia
• Una password alfanumerica di 10+ caratteri con maiuscole, minuscole e simboli: computazionalmente improbabile da forzare offline attraverso scrypt; quasi impossibile da forzare online contro un Secure Element

La password è richiesta solo all’avvio. L’autenticazione biometrica (impronta digitale, riconoscimento facciale) gestisce lo sblocco quotidiano, a meno che l’utente non si trovi in una giurisdizione dove la coercizione fisica è probabile, legalmente o meno. Il disagio marginale di inserire una password forte una volta dopo ogni riavvio è minimo rispetto alla protezione che offre.

Scelta del dispositivo #

Secondo la stessa documentazione di Cellebrite di febbraio 2025:

• Dispositivi basati su MediaTek: nessuna mitigazione possibile contro gli attacchi BFU a causa di vulnerabilità non correggibili nella Boot ROM.
• La maggior parte dei dispositivi Android non Pixel e non Samsung: considerati sbloccabili, con poche eccezioni, a causa di una combinazione di aggiornamenti di sicurezza in ritardo, implementazioni TEE deboli e Secure Element assenti.
• Dispositivi Samsung (Exynos): protezione parziale, variabile per modello e livello di patch.
• Google Pixel con Android stock: resistenti agli attacchi BFU sui modelli recenti, ma l’estrazione AFU del file system è possibile.
• Google Pixel con GrapheneOS: resistenti sia agli attacchi BFU che AFU sui modelli recenti (6a e successivi). Questa è la protezione più forte disponibile su qualsiasi dispositivo Android.

Vale la pena notare che distribuzioni Android alternative come LineageOS o CalyxOS, sebbene preziose per altri motivi, non cambiano in modo significativo il quadro dello sblocco forense rispetto alla ROM stock o del produttore.

Crittografia a livello applicativo #

Le applicazioni che implementano il proprio livello di crittografia con una password separata possono fornire difesa in profondità contro la compromissione completa del dispositivo. I vault con master password dei gestori di password ne sono un buon esempio: anche se l’intero filesystem del dispositivo viene estratto, il vault rimane cifrato con una chiave che lo strumento forense non ha ottenuto.

Tuttavia, l’efficacia della protezione a livello applicativo dipende da diversi fattori: se l’app implementa effettivamente una propria crittografia indipendente dalla protezione delle credenziali del sistema operativo, se le chiavi di decifratura rimangono in memoria dopo il primo sblocco (rendendole vulnerabili all’estrazione AFU), se l’app si affida all’autenticazione biometrica di sistema (che, senza un Secure Element, è compromessa insieme al resto della gerarchia di chiavi del sistema operativo), e se le notifiche o le anteprime dei messaggi sono memorizzate in chiaro al di fuori dello storage cifrato dell’app.

Conclusione #

Il modo in cui questi strumenti operano non è né magia né segreto. Più raccogliamo campioni, facciamo reverse engineering e leggiamo materiale promozionale e di supporto, meglio comprendiamo capacità e difese.

Come abbiamo detto molte volte, questi strumenti semplicemente non dovrebbero esistere in commercio. Le aziende che costruiscono questi strumenti sono partecipanti attivi nel commercio di vulnerabilità zero-day, accumulando falle di sicurezza che indeboliscono ogni dispositivo, per ogni utente, ovunque. Le difese tecniche qui descritte sono efficaci ma pongono l’onere su individui e comunità.

Riferimenti #

• Quarkslab, “Android Data Encryption in depth” (2023)
• Quarkslab, “Introduction to Trusted Execution Environment: ARM’s TrustZone™” (2018)
• Quarkslab, “A Deep Dive into Samsung’s TrustZone™” (serie)
• Quarkslab, “Attacking Titan M with Only One Byte” (2022)
• Quarkslab, “First analysis of Apple’s USB Restricted Mode bypass (CVE-2025-24200)” (2025)
• Quarkslab, “Reverse Engineering Samsung S6 SBoot” (serie)
• Synacktiv, “Kinibi TEE: Trusted Application exploitation” (2018)
• Amnesty International Security Lab, “A Digital Prison: Surveillance and the suppression of civil society in Serbia” (2024)
• Amnesty International Security Lab, “Cellebrite zero-day exploit used to target phone of Serbian student activist” (2025)
• GrapheneOS, “Discussion on Cellebrite Premium July 2024 documentation” (2024)
• Samsung Knox, “Encryption systems description”
• Google, “Titan Hardware Chip documentation”
• Google, “Titan M makes Pixel 3 our most secure phone yet” (2018)
• Android Source, “File-Based Encryption”
• Android Source, “Full-Disk Encryption”
• Bjoern Kerler, “MTKClient” — strumento open-source per lo sfruttamento delle vulnerabilità nella Boot ROM di MediaTek