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.
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.
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.
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.
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.
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.
Google ha migliorato Android:
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.
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:
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:
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.
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.
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.
[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
L'Unione Europea si trova nel mezzo di una trasformazione normativa senza precedenti con eIDAS 2,…
Al 22° Forum ICT Security, Igor Serraino – Independent ICT Advisor – ha trattato argomenti…
Il Federated Learning (FL) si configura come un paradigma emergente e altamente promettente nell'ambito dell'apprendimento…
Nel corso del Forum ICT Security 2024, l’intervento “Test di sicurezza avanzati: La sicurezza va…
L’intervento di Valerio Pastore, cofondatore di Cyber Grant, intitolato “Allarme Data Breach: 7 attacchi su…
L'evoluzione dell'Internet of Things (IoT) ha portato alla luce un fenomeno emergente nel panorama del…