Sicurezza Android indietro rispetto all'iPhone di almeno sei anni

Fonte foto: Shutterstock

Se un tempo il telefono serviva solo per fare e ricevere chiamate, adesso è diventato un elemento centrale delle attività quotidiane di tutti gli utenti che lo usano per navigare in Internet, chattare e addirittura per pagare, o per lo meno, per effettuare transazioni online. Matthew Green, crittografo e professore presso la Johns Hopkins University, ha delineato le caratteristiche generali della crittografia e analizzato i sistemi di protezione adottati da iOS e Android. E Google ne è uscito con le ossa rotte. Nougat, l’ultima versione del sistema di Mountain View, è migliorato sotto questo punto di vista, ma c’è ancora molto lavoro da fare.

Le basi della crittografia

La crittografia degli hard disk è, ovviamente, molto più “vecchia” di quella degli smartphone e può – attualmente – essere realizzata in due modi diversi:

– Full Disk Encryption (FDE) è un sistema – come Truecrypt, BitLocker e FileVault – che codifica i dischi a livello di settori. È un approccio del tipo – tutto o niente – visto i driver di crittografia non hanno necessariamente idea di quali file siano contenuti nei vari settori. FDE, tra l’altro, è molto usato soprattutto proprio perché è estremamente facile da implementare.

– File-based Encryption (FBE), invece, è un sistema – come EncFS ed eCryptFS – che codifica i file singolarmente. È un approccio più complicato perché richiede di apportare modifiche al filesystem, ma che offre un controllo degli accessi più versatile in cui più file di diversa natura vengono crittografati utilizzando chiavi diverse.

Va da sé che la soluzione Full Disk Encryption, proprio perché più semplice da implementare, è attualmente la più utilizzata nel settore degli hard disk.

Tutto questo cos’ha a che fare con Android?

Semplice, perché i primi tentativi di Android di aggiungere la crittografia ai propri smartphone ha seguito la tecnologia alla base del Full Disk Encryption (FDE), ossia la crittografia completa degli hard disk. I sistemi Android – a partire dal Android 4.4 (KitKat) fino ad arrivare ad Android 6.0 (Marshmallow) – sfruttavano una soluzione basata su un kernel – chiamato dm-crypt – progettato per codificare i dischi a livello di settori. Si è trattato di un tentativo semplice – e soprattutto rapido – di risolvere il problema convinti che gli smartphone fossero, alla fine fine, dei computer i miniatura. Niente di più sbagliato spiega Matthew Green: il problema è che gli smartphone non sono computer!

La differenza principale è che gli utenti di telefonini sono incoraggiati a tenere sempre acceso il proprio dispositivo. Questo significa che – inserita una volta la password dopo l’accesso – le persone passano l’intera giornata con tutte le chiavi di crittografia memorizzate nella RAM dello smartphone. E poiché le batterie durano per tutto il giorno, a volte anche di più, la crittografia non offre – in questo modo – un’efficace protezione contro possibili attacchi se qualche malintenzionato – con le competenze giuste – riesce a metterci le mani sopra in quell’arco di tempo. È vero che molti utenti hanno l’abitudine di bloccare i propri smartphone. Una buona soluzione se implementata potrebbe, in linea di principio, cancellare le chiavi di crittografia più importanti quando il telefono è bloccato, per poi ripristinarle quando si effettua nuovamente l’accesso. Android, purtroppo, questo non lo fa perché gli utenti gli utenti Android voglio che il telefono funzioni senza interruzioni e, senza le chiavi di crittografia nella memoria RAM, il sistema FDE (Full Disk Encryption) impedirebbe l’accesso a tutti i dati archiviati nel disco rendendolo inutilizzabile. Una volta effettuato il boot di un telefono Android con tecnologia FDE, proprio per questa ragione, non cancellerà mai le sue chiavi di codifica dalla RAM. E, secondo il crittografo, non è una buona soluzione.

Qual è l’alternativa? Apple!

Android non è l’unico “player” quando si tratta di crittografia degli smartphone. C’è anche Apple. Anche il colosso di Cupertino ha riflettuto a lungo su questa spinosa questione arrivando a una soluzione leggermente diversa. A un approccio diverso. Apple – a partire da iOS 4 – ha introdotto una funzione per la protezione dei dati che codifica tutto il contenuto presente sul dispositivo. Apple non ha scelto l’opzione di crittografare l’intero disco a settori (FDE), bensì si è orientata verso la codifica dei singoli file (FBE). Il sistema iOS codifica tramite un’unica chiave il contenuto di ogni singolo file e ogni chiave viene, a sua volta, criptata con una delle numerose “chiavi di classe” generate partire dalla password usata dall’utente e alcuni “strumenti” hardware presenti nel processore. Il principale vantaggio dell’approccio scelto da Apple è che, invece di usare una singola password (FDE) che gestisca tutto, l’azienda di Cupertino fornisce agli sviluppatori delle API (Application Programming Interface) – ossia un insieme di procedure per eseguire una determinata operazione all’interno di una specifica applicazione – che permette di specificare il tipo di classe di chiave da utilizzare per un dato file. Apple fornisce le seguenti “classi di protezione”:

Protezione completa: i file crittografati con questa classe chiave sono accessibili solo quando il dispositivo è acceso e sbloccato. La chiave di classe è eliminata dalla RAM, ma solo per qualche secondo, dopo il blocco del dispositivo.

Protezione fino alla prima autenticazione dell’utente: i file crittografati con questa classe chiave sono protetti fino al primo accesso dell’utente – e dopo un riavvio – e restano poi in memoria.

Nessuna protezione: questi file sono accessibili anche quando il dispositivo è stato riavviato, e l’utente non ha ancora effettuato l’accesso.

Apple, fornendo ai programmatori la possibilità di proteggere i singoli file, ha reso possibile lo sviluppo di applicazioni in grado di funzionare anche quando il dispositivo è bloccato fornendo, al contempo, una protezione ai file che contengono dati sensibili. Il colosso di Cupertino, inoltre, ha previsto anche una quarta opzione per le app che hanno semplicemente bisogno di creare nuovi file crittografati quando le chiavi sono eliminate dalla RAM. È una classe, insomma, che ha il solo compito di fornire nuove chiavi: questo è il motivo per cui, per esempio, in iOS è possibile scattare una foto anche quando il dispositivo è bloccato. Anche l’approccio di Apple non è perfetto, però, è evidente che è il risultato di uno studio lungo e meditato. La domanda è perché anche Android non ha seguito lo stesso approccio?

Android alla ricerca di una soluzione

Google, in realtà, sta cercando una soluzione per garantire una maggiore sicurezza ai propri dispositivi, ma è partita tardi e con il “piede” sbagliato, e sta affannosamente cercando di recuperare il tempo perduto. Android – a partire dalla versione Nougat 7.0 – ha abbandonato la cifratura completa del disco come meccanismo principale di protezione dei dati “a riposo”. I sistemi Android N, se si imposta una password di accesso sul dispositivo, possono essere configurati per supportare un approccio molto più simile a quello di Apple che utilizza la crittografia a livello di file. E fin qui è un’ottima scelta. Il nuovo sistema – chiamato Direct Boot – va quindi a sostituire l’FDE usato fino alle release precedenti. Il vantaggio principale di questo “cambio di rotta” permette agli smartphone di accedere ad alcuni dati addirittura prima di inserire una password. Questa novità è stata possibile fornendo agli sviluppatori due diversi “contesti di crittografia”:

Archiviazione con credenziali crittografate: i file in quest’area sono codificati tramite la password digitata dall’utente e non saranno disponibili finché non viene eseguita questa operazione, almeno una volta.

Archiviazione con dispositivo crittografato: i file non sono codificati tramite la password dell’utente, sebbene potrebbero essere crittografati utilizzando strumenti a livello hardware. I dati sono, così, disponibili dopo l’avvio, anche prima che l’utente digiti una password.

Il Direct Boot, insomma, fornisce due opzioni separate per i diversi utenti del telefono anche se, spiega sempre il crittografo Matthew Green, il motivo di questa scelta non è chiara. Ma, dice, «perché no?»

Se Android sta “recuperando”, qual è il problema?

Se avete seguito il quadro generale fin qui, avrete notato un dettaglio: Apple offre quattro categorie di protezione, mentre Android Nougat solo due. E il problema sono proprio queste due categorie mancanti che consentono all’utente di bloccare i propri dispositivi dopo la prima autenticazione ed eliminare le chiavi dalla memoria. È importante sottolineare che il vero problema di Android non è tanto la crittografia, quanto piuttosto che Google non offre agli sviluppatori delle direttive appropriate lasciando a metà la questione della sicurezza dei propri dispositivi. Android, senza una soluzione che definisca una classe di protezione “completa”, non permette ai programmatori di sviluppare correttamente le applicazioni in modo che i dispositivi possano davvero essere – al tempo stesso – bloccati e funzionanti. Tutto questo discorso porta alla classica “morale della favola”: Apple, anche se con un sistema migliorabile, è sei anni avanti rispetto ad Android nel settore della crittografia.