Android, dispositivi mobili: quanto sono al sicuro i dati in memoria?

Negli ultimi anni abbiamo assistito all’esplosione del mondo mobile che, con una crescita esponenziale, ha portato nelle tasche di miliardi di utenti dei nuovi dispositivi mobile, all’interno dei quali risiede un’innumerevole quantità d’informazioni confidenziali. Per tale motivo è divenuto fondamentale garantire la sicurezza dei dati salvati su smatphone e tablet, per proteggere l’accesso in caso di compromissione della sicurezza del device, in particolare in caso di furto.

A tale scopo è buona norma garantire che tutte le informazioni riservate, gestite da un’applicazione mobile, siano rese inaccessibili a chiunque non sia autorizzato ad accedervi. Pertanto è necessario far ricorso alla crittografia ogniqualvolta sia necessario salvare nella memoria persistente del telefono tali dati. Tutti gli algoritmi crittografici si basano sulla generazione di una chiave (o di una coppia, nel caso asimmetrico) e sul fatto che solo chi ne è in possesso è in grado di decriptare le informazioni. Si rende pertanto indispensabile la disponibilità di strumenti che consentano il salvataggio delle chiavi in maniera sicura e persistente.

In Android, a partire dalla versione 4.3 della piattaforma, è stato introdotto il Keystore di sistema, un componente che consente alle applicazioni di salvare le proprie chiavi private, rendendole inaccessibili a qualsiasi processo non autorizzato. Nonostante la componente sia estremamente utile in ottica di sicurezza (per i motivi descritti in precedenza), presenta una problematica cruciale: in alcune situazioni sussiste il rischio che la chiave venga definitivamente eliminata dal sistema, rendendo inaccessibili tutti i dati crittografati.

In particolare, tale circostanza può verificarsi quando il metodo di sblocco (PIN, password o sequenza) viene disabilitato o azzerato, o nel caso in cui venga aggiunta / rimossa un’impronta digitale (in caso di sblocco biometrico). In funzione della versione del dispositivo, il comportamento può variare, in particolare nelle versioni precedenti alla 6.0 la circostanza descritta si verifica sempre.

Da Marshmallow in poi invece, è possibile evitare tale rischio non richiedendo la crittografia “at rest” (a riposo) delle chiavi. Ciò significa che le chiavi saranno salvate in chiaro, all’interno del keystore, aumentando il rischio che un eventuale attaccante possa riuscire a estrarle con conseguente accesso ai dati riservati.

Il rischio è notevolmente inferiore nei dispositivi dotati del componente di crittografia hardware, ed è pertanto possibile verificare la presenza di questo elemento prima di procedere, tenendo presente che ciò comporterebbe l’esclusione di una buona fascia di device dall’utilizzo dell’applicazione.

Se i vincoli appena descritti non sono accettabili per l’applicazione che si intende sviluppare è necessario considerare le possibili alternative. Potrebbero, ad esempio, esistere situazioni in cui la perdita delle informazioni salvate viene ritenuta una conseguenza accettabile pur di garantire la sicurezza delle stesse. Tale approccio si presta bene alle casistiche in cui le informazioni sono in sola lettura per l’utente, assumendo che esista un meccanismo di ripristino in caso di perdita. In queste situazioni l’ownership dello stato appartiene al server, mentre il database in app svolge esclusivamente il ruolo di cache temporanea.

Diversamente, qualora nel database siano presenti anche dati prodotti dall’utente stesso, l’approccio non sarebbe opportuno: le informazioni potrebbero infatti divenire irrecuperabili nel caso si verifichino le casistiche sopra descritte.

Se tutte le soluzioni proposte finora non sono ritenute accettabili, è necessario prevedere un metodo alternativo per la generazione ed il salvataggio della chiave. Esistono molteplici strumenti sviluppati da compagnie o developer indipendenti allo scopo di fornire un’alternativa al Keystore di sistema. La soluzione va valutata con estrema cautela, in quanto si sta affidando ad una libreria sviluppata da terzi una funzionalità cruciale per la sicurezza dell’applicazione.

Alternativamente si potrebbe valutare di cambiare completamente approccio ed evitare di salvare le chiavi all’interno del device, utilizzando ad esempio una password nota solamente all’utente. Questa soluzione massimizzerebbe il livello di sicurezza, ma avrebbe un impatto non indifferente sull’usabilità, in quanto l’utente sarebbe obbligato a immettere la password per ogni accesso ai dati sensibili. Va inoltre considerato che è necessario imporre una password policy che non sia né troppo complessa né troppo semplice. In un caso infatti aumenterebbe il rischio che venga dimenticata, con conseguente perdita delle informazioni, nell’altro potrebbero essere state utilizzate parole molto semplici da indovinare

Risorse e riferimenti consigliati

• https://developer.android.com/training/articles/keystore.html
• https://doridori.github.io/android-security-the-forgetful-keystore/#sthash.TK6Hh6qa.SHIbK52N.dpbs