La sicurezza degli smartphone e la memorizzazione dei dati
La sicurezza degli smartphone viene garantita nei principali sistemi operativi mobile attraverso diverse tecniche di cifratura. Su Android, dalla versione 6, il Full Disk Encryption protegge i dati, mentre Android 7 introduce la File-Based Encryption per una maggiore sicurezza. iOS utilizza il Secure Enclave, una soluzione avanzata che salvaguarda i dati con chiavi criptografiche uniche. Anche Windows Mobile offre protezione con BitLocker, ma presenta alcune vulnerabilità. Nel complesso, iOS e le versioni più recenti di Android offrono elevati livelli di protezione per i dati degli utenti.
Introduzione alla sicurezza dei dati sugli smartphone
Quanto sono protetti i dati memorizzati sugli smartphone da un utente malintenzionato?
Il quesito sorge dal film “Cosa vuoi che sia?”: nella scena finale, il protagonista porta il proprio smartphone in assistenza, dimenticando di eliminare dalla memoria un video osé prodotto con la propria compagna. Il tecnico, scoperto tale contenuto, carica il video su un noto sito di contenuti per adulti, rendendolo di dominio pubblico.
Si può pensare queste cose accadano solo nei film ma, riportando un post della Polizia di Stato Online o citando figure come Assange e Snowden, ci rendiamo conto che la realtà è diversa.
Analizzeremo quindi le metodologie di cifratura dei dati nei più diffusi SO mobile.
Cifratura dati su Android inferiori al 7
Google ha introdotto il Full Disk Encryption (FDE) della partizione utente /data a partire da Android 3, migliorandolo e rendendone obbligatoria l’implementazione con Android 6.
Il dispositivo genera una propria chiave, protetta da un il codice di sblocco definito dall’utente e custodita nella lockbox, con la quale cifra la suddetta partizione. È possibile modificare tale codice anche in un secondo momento senza dover crittografare nuovamente i dati.
Il sistema non è in grado né di decifrare, né di avviarsi senza /data, finché l’utente non si autentica tramite lockscreen. Ostacolo risolto montando una partizione effimera: ad autenticazione avvenuta, vi è la sostituzione della partizione effimera con quella utente e la prosecuzione delle fasi di boot.
Inoltre a seguito di ogni riavvio, accidentale o meno, le app non funzionano fino a che non avviene l’autenticazione: ciò comporta la perdita di ogni evento e la mancata ricezione di tutte le notifiche.
Per ovviare a questo inconveniente l’A6 consente di disabilitare l’autenticazione pre-avvio (TaskerON) tramite l’utilizzo di una “default_password” (letteralmente, ndr) come chiave di crittografia di /data:
In questo modo il dispositivo sarà in grado di mostrare chiamate, allarmi e notifiche anche prima dell’autenticazione.
L’approccio TaskerON protegge ancora i dati da situazioni di compromissione a sistema spento; viceversa, la protezione sarebbe basata sulla sola robustezza della lockscreen.
File-Based Encryption su Android 7: il Direct Boot e i problemi della cifratura
Con A7 vi è l’introduzione del Direct Boot. La crittografia passa a File-Based Encryption (FBE), risolvendo i problemi elencati in precedenza. FBE prevede due classi di archiviazione: Credential e Device Encrypted storage. La prima si occupa della locazione di memoria utente, protetta dalla lockscreen e disponibile dopo l’autenticazione; la seconda è sempre disponibile al sistema, protetta da una chiave generata dal dispositivo.
Le chiavi CE/DE vengono create per un owner e tanti users: i rispettivi dati saranno cifrati ed accessibili in maniera esclusiva. L’unica limitazione è che l’owner del dispositivo deve essere sempre il primo ad autenticarsi a seguito di un riavvio, poiché il suo DE viene considerato primario.
Problemi di questa implementazione:
- Ad ogni riavvio, non avendo accesso alla rubrica utente, il sistema mostra solo i numeri e non i contatti per le notifiche.
- Non è prevista la cancellazione delle chiavi CE/DE dalla memoria a seguito di un lock del dispositivo.
Figura 4 mostra che non vi è modo di notificare alle applicazioni se il sistema è stato re-bloccato. Se per ipotesi rimuovessimo le chiavi dalla memoria, le applicazioni in background troverebbero inaspettatamente negati i diritti di accesso ai file (Figura 5).
Detto ciò, in un laboratorio forense via (bus) hardware tali chiavi sono probabilmente intercettabili; via software non vi è necessità di rubarle: basta superare la lockscreen. Vien da sé che eseguire il “root” del dispositivo ed autorizzare l’esecuzione di software non firmato non è un’operazione intelligente.
Android 8: miglioramenti nella sicurezza ma stessi problemi
In ogni caso il problema è a monte: anche se le successive versioni di Android implementassero la rimozione delle chiavi, occorrerebbe riscrivere le app dell’intero PlayStore.
- Il Direct Boot non è abilitato di default su smartphone A7 non nativi: l’attivazione, a cura dell’utente ed attivabile tramite modalità developer, richiede una full-wipe del dispositivo.
Google ha migliorato Android:
- Introduce il Verified Boot 2, che protegge dal downgrade.
- Hardenizza il kernel (KASLR).
- Implementa l’HAL, astraendo lo strato software da quello hardware (Figura 6).
Ma nessun riferimento alle chiavi mantenute in RAM: A8 prevede soltanto una funzione Enterprise con la quale un amministratore di dominio può rimuovere le chiavi al fine di bloccare un utente.
La cifratura dei dati su iOS 7 e successivi
A partire da iOS 4, Apple ha introdotto la protezione dei dati di default tramite FBE. In seguito con iOS 7 è stato introdotto il Secure Enclave (SE).
Questo coprocessore integra funzioni biometriche, di crittografia e di gestione della UniqueID (UID)[1]. In aggiunta Apple ha collocato sui device un AES Engine.
All’avvio del dispositivo, vi è la creazione di una chiave effimera legata all’UID volta a codificare la RAM. Per la manipolazione dei file, AES-E si occupa delle fasi di cifratura/decifratura ed il SE fornisce le chiavi. Per evitare intercettazioni fisiche sul bus, SE ed AES-E usano il Diffie-Hellmann nelle loro interazioni.
Esistono tre tipi di chiavi per la cifratura:
- FileKey: per-file, generata dal Secure Enclave;
- ClassKey: relativa alla classe di sicurezza dei file, protegge la FileKey;
- File System Key[2]: chiave di sistema derivata dall’UID, generata ex-novo ad ogni nuova inizializzazione del sistema.
Ogni file è cifrato con una FileKey, a sua volta cifrata con una ClassKey. La FileKey è incapsulata nei metadati del file. Il pacchetto è infine cifrato con la File System Key (Figura 9).
Per un full wipe sicuro del device basta eliminare la FileSystemKey dal dispositivo, rendendo ogni FileKey inaccessibile.
Alla creazione di un file, un’app può attribuire allo stesso una delle quattro classi di sicurezza disponibili in funzione della modalità di accesso necessaria:
- Complete Protection (CP): cifra la FileKey. A seguito di una lock, la ClassKey in memoria viene scartata, rendendo i dati inaccessibili fino ad una nuova autenticazione.
- Protected Unless Open (PUO): alcuni file hanno bisogno di essere scritti mentre il dispositivo è bloccato, come in un download in background. In questo caso oltre alla FileKey vengono generate una coppia di chiavi asimmetriche effimere. Tramite la chiave privata effimera e la chiave pubblica della PUO, viene generato uno shared secret ed il conseguente hash, usato per crittografare la FileKey. La chiave privata effimera viene scartata, mentre la pubblica viene memorizzata insieme ai metadati del file. Alla chiusura del file, tutte le chiavi verranno rimosse dalla RAM. Per riaprire il file basterà ricreare l’hash dello shared secret con la chiave pubblica effimera (nei metadati) e la chiave privata della PUO fornita dal SE.
- Protected Until First User Autentication (PUFUA): simile alla CP, ma mai rimossa dalla RAM a dispositivo bloccato. Questa protezione è simile alla codifica FDE e protegge i dati dagli attacchi di tipo reboot. Questa classe è di default per tutti i dati ai quali non è stata assegnata una modalità di accesso specifica.
- No Protection (NP): usata per i file considerati pubblici, come i dati dell’app “cartella clinica”. Sono comunque dati archiviati in forma codificata.
Il SE protegge le ClassKey. Durante la prima inizializzazione, tramite l’unione di UID e codice di blocco stabilito dall’utente, crea, codifica e storicizza le ClassKey nella KeyBag[3]. L’utente autenticandosi rende utilizzabili le ClassKey.
Cifratura e sicurezza su Windows Mobile 8.1
Tratteremo brevemente questo SO, poiché Joe Belfiore, Corporate Vice President di Microsoft, ha recentemente dichiarato conclusa l’esperienza in ambito mobile da parte della sua azienda.
WM utilizza il Trusted Platform Module unitamente a Bitlocker per garantire la FDE tramite AES-128 bit. La gestione dell’accesso allo storage utente avviene tramite Microsoft Exchange ActiveSync o i Criteri di Gruppo.
In sostanza il TPM, avendo accesso alla chiave di cifratura dello storage, è in grado di avviare in autonomia il dispositivo. L’utente, tramite il PIN personale, si autentica sul device per svolgere le proprie mansioni.
La robustezza di questa architettura è intrinseca nel TPM, in grado di resistere ad attacchi hardware e di tipo brute force. Contrariamente, il problema sta nel fatto che Bitlocker è vulnerabile al Memory Remanence Attack: in sostanza vi sono alcuni modi per riuscire a carpire la chiave dell’FDE utilizzata durante la fase di boot.
Conclusioni sulla sicurezza degli smartphone: qual è il miglior sistema operativo mobile?
Nel marzo 2017, durante l’Android Security 2016 Year In Review, Google ha elargito elogi verso il proprio SO enfatizzando come il numero di dispositivi Android criptati sia aumentato con l’introduzione di A7.
Sarà stata di certo una svista, ma la stessa Google ha stranamente “dimenticato” di precisare che il numero di dispositivi A7.x in circolazione è appena il 15,8%.
Senza contare che, come descritto in precedenza, gli A7.x non nativi non sono cifrati di default, riducendo a 12,64% il dato precedente. Infine, da un rapido calcolo, si evince che solo il 25% della totalità dei dispositivi Android è crittografato. Ad ogni modo, con il tempo queste percentuali tenderanno a migliorare.
Cambiando argomento, sia Android che Windows Mobile consentono l’utilizzo di SD, cosa che iOS non fa in alcun caso. Anche questo attributo è un punto di debolezza dei primi due SO.
Ulteriori punti a sfavore di WM riguardano l’utilizzo della crittografia FDE, le difficoltà ad attivarla e l’utilizzo di l’AES a soli 128 bit.
Fra tutti, l’approccio iOS è sicuramente il più sofisticato: essendo stato progettato fin dal principio, Apple ha potuto sviluppare il device intorno all’architettura di sicurezza.
Nel complesso, anche se migliorabile, iOS attualmente offre il miglior compromesso tra usabilità e sicurezza degli smartphone, seguito a distanza da A8.
Note
[1] UID: generata al momento della creazione del chip, diversa per ogni dispositivo e sconosciuta ad Apple.
[2] FileSystemKey: storicizzata cifrata nella Effaceable Storage (area dedicata all’archiviazione delle chiavi).
[3] Keybag: contenitore delle ClassKey cifrate; ad esclusione della NP memorizzata nella Effaceable Storage.
A cura di: Daniele Rigitano
Laureato in Tecnologie Informatiche e con un Master in Sicurezza delle Reti.
Da sempre appassionato di Sicurezza Informatica e vicino alle tematiche come Threat Intelligenze, Computer Fosensics ed Information Security Management, entra come Cyber Security Specialist nel Computer Emergency Response Team del Ministero dell'Economia e delle Finanze.
