Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Security
Code

Archiviazione sicura dei dati su Android

by
Difficulty:AdvancedLength:LongLanguages:

Italian (Italiano) translation by Mirko Pizii (you can also view the original English article)

Credibilità di un'app oggi altamente dipende dalla modalità di gestione dati privati dell'utente. Lo stack Android ha molte potenti API circostante credenziale e archiviazione delle chiavi, con specifiche caratteristiche disponibili solo in determinate versioni. Questa breve serie partirà con un approccio semplice per arrivare fino e in esecuzione controllando il sistema di archiviazione e come crittografare e memorizzare i dati sensibili tramite un codice di accesso fornito dall'utente. Nel secondo tutorial, vedremo più complessi modi di proteggere le chiavi e le credenziali.

Le nozioni di base

La prima domanda a pensare è la quantità di dati è effettivamente necessario acquisire. Un buon approccio è quello di evitare di memorizzare dati privati, se davvero non devi.

Per i dati che è necessario memorizzare, l'architettura Android è pronto ad aiutare. Dal 6.0 Marshmellow, crittografia completa del disco è attivata per impostazione predefinita, per i dispositivi con la capacità. File e SharedPreferences che vengono salvati dall'app vengono impostate automaticamente con la costante MODE_PRIVATE. Ciò significa che i dati sono accessibili solo dalla tua app.

È una buona idea quella di attaccare a questo difetto. È possibile impostare in modo esplicito quando si salva una preferenza condivisa.

O quando si salva un file.

Evitare di archiviare dati su storage esterno, come i dati quindi sono visibili da altri utenti e applicazioni. Infatti, per evitare di fare più difficile per le persone a copiare il file binario app e i dati, è possibile impedire agli utenti di essere in grado di installare l'app su archiviazione esterna. Aggiunta di android:installLocation con un valore di internalOnly per il file manifesto che compirà.

È inoltre possibile impedire l'applicazione e i relativi dati dal backup. Questo impedisce anche di scaricare il contenuto della directory di dati privati di un'applicazione utilizzando adb backup. A tale scopo, è necessario impostare l'attributo android:allowBackup su false nel file manifesto. Per impostazione predefinita, questo attributo è impostato su true.

Queste sono le migliori pratiche, ma non funzioneranno per un dispositivo radicato o compromesso, e crittografia del disco è utile solo quando il dispositivo è protetto con una schermata di blocco. Questo è dove avere una password app-lato che protegge i dati con crittografia è positivo.

Protezione dei dati di utente con una Password

Nascondere è un'ottima scelta per una libreria di crittografia perché si è installato e funzionante molto velocemente senza dovere preoccuparsi per i dettagli sottostanti. Tuttavia, un exploit mirato per un popolare framework influirà simultaneamente tutte le applicazioni che si basano su di esso.

Inoltre è importante essere ben informato sul funzionano dei sistemi di crittografia al fine di essere in grado di dire se si sta utilizzando un particolare framework in modo sicuro. Così, per questo post ci accingiamo a sporcarci le mani guardando direttamente il provider di crittografia.

AES e derivazione della chiave basata su Password

Utilizziamo lo standard AES consigliato, che crittografa i dati dati una chiave. La stessa chiave utilizzata per crittografare i dati viene utilizzata per decrittografare i dati, che si chiama crittografia simmetrica. Ci sono diverse dimensioni chiave e AES256 (256 bit) è la lunghezza preferita per l'utilizzo con dati sensibili.

Mentre l'esperienza utente della tua app dovrebbe obbligare un utente ad utilizzare un codice di protezione forte, c'è una possibilità che lo stesso passcode sarà scelti anche da un altro utente. Mettere la sicurezza dei nostri dati crittografati nelle mani dell'utente non è sicuro. I nostri dati ha bisogno di essere protetti invece con una chiave che è casuale e abbastanza grande (cioè. che ha abbastanza entropia) deve essere considerato forte. È per questo che mai si consiglia di utilizzare una password direttamente per crittografare dati — che è dove una funzione denominata funzione di derivazione di chiave basata su Password (PBKDF2) entra in gioco.

PDKDF2 deriva una chiave da una password hash molte volte sopra con un sale. Questo è chiamato chiave di stretching. Il sale è una sequenza casuale di dati e rende unica la chiave derivata anche se la stessa password è stata utilizzata da qualcun altro. Lascia inizio generando quello sale.

La classe SecureRandom garantisce che l'output generato sarà difficile prevedere — è un "Generatore numeri casuali crittograficamente sicuro". Ora possiamo mettere il sale e la password in un oggetto di crittografia basata su password: PBEKeySpec. Il costruttore dell'oggetto prende anche un modulo di conteggio di iterazione fare la chiave più forte. Infatti, aumentando il numero di iterazioni espande il tempo che ci sarebbe voluto per operare su un set di chiavi durante un attacco a forza bruta. Il PBEKeySpec viene quindi passato SecretKeyFactory, che infine genera la chiave come una matrice di byte[]. Potremo avvolgere array di byte[] non elaborati in un oggetto SecretKeySpec.

Si noti che la password viene passata come un array di char[] e la classe PBEKeySpec memorizza come un array di char[] pure. array di Char[] sono usati solitamente per le funzioni di crittografia perché mentre la classe String non è modificabile, un array di char[] contenente informazioni riservate possono essere sovrascritti — eliminando in tal modo i dati sensibili completamente da phyc del dispositivo RAM.

Vettori di inizializzazione

Ora siamo pronti per crittografare i dati, ma ne abbiamo un'altra cosa da fare. Ci sono diverse modalità di crittografia AES, ma useremo quella consigliata: (CBC) cipher block chaining. Questo opera su nostri dati un blocco alla volta. La cosa grandiosa di questa modalità è che ogni blocco di dati non crittografato successivo è che XOR ha avuto con il precedente blocco cifrato per rendere la crittografia più forte. Tuttavia, significa che il primo blocco non è mai unico, proprio come tutti gli altri!

Se un messaggio da crittografare dovesse iniziare lo stesso un altro messaggio da crittografare, l'output di inizio crittografato sarebbe lo stesso, e che darebbe un utente malintenzionato un indizio per capire che cosa potrebbe essere il messaggio. La soluzione consiste nell'utilizzare un vettore di inizializzazione (IV).

Un IV è solo un blocco di byte casuali che sarà XOR ha avuto con il primo blocco di dati utente. Poiché ogni blocco è dipende da tutti i blocchi elaborati fino a quel punto, l'intero messaggio verrà crittografato in modo univoco — identici messaggi crittografati con la chiave stessa non produrrà risultati identici. Consente di creare un IV ora.

Una nota riguardo SecureRandom. Sulle versioni 4.3 e sotto, il Java Cryptography Architecture aveva una vulnerabilità a causa di improprio inizializzazione del generatore numero pseudocasuale sottostante (PRNG). Se la destinazione è versioni 4.3 e sotto, è disponibile una correzione.

Crittografia dei dati

Armati con un IvParameterSpec, ora possiamo fare la crittografia effettiva.

Qui si passa nella stringa "AES/CBC/PKCS7Padding". Questo specifica la crittografia AES con cypher block chaining. L'ultima parte di questa stringa si riferisce PKCS7, che è uno standard consolidato per imbottitura dati che non rientrano perfettamente nella dimensione del blocco. (Blocchi sono a 128 bit, e imbottitura avviene prima della crittografia).

Per completare il nostro esempio, metteremo questo codice in un metodo di crittografia che confezionerà il risultato in un HashMap contenente i dati crittografati, insieme con il vettore di inizializzazione e di sale necessario per la decrittografia.

Il metodo di decrittografia

È sufficiente memorizzare il IV e il sale con i vostri dati. Mentre sali e IVs sono considerati pubblici, assicurarsi che non in sequenza vengono incrementati o riutilizzati. Per decrittografare i dati, tutto quello che dobbiamo fare è cambiare la modalità nel costruttore cifrario da ENCRYPT_MODE a DECRYPT_MODE. Il metodo decrypt porterà un HashMap contenente le stesse informazioni richieste (dati crittografati, sale e IV) e restituire una matrice di byte[] decrittografata, dato la password corretta. Il metodo decrypt verrà rigenerata la chiave di crittografia dalla password. La chiave non deve mai essere archiviata!

Prova la crittografia e la decrittografia

Per mantenere l'esempio semplice, noi stiamo omettendo il controllo degli errori che assicurerebbe che la HashMap contiene la chiave necessaria, coppie valore. Ora possiamo testare i nostri metodi per garantire che i dati viene decrittografati correttamente dopo la crittografia.

I metodi utilizzano una matrice di byte[] in modo che è possibile crittografare dati arbitrari anziché solo gli oggetti String.

Salvataggio dei dati crittografati

Ora che abbiamo un array di byte[] crittografati, possiamo salvarlo per deposito.

Se non volevi salvare il IV e il sale separatamente, HashMap è serializzabile con le classi ObjectInputStream e ObjectOutputStream.

Salvataggio sicuro dei dati a SharedPreferences

È anche possibile salvare dati sicuri per SharedPreferences della tua app.

Poiché il SharedPreferences è un sistema XML che accetta solo specifici primitive e oggetti come valori, abbiamo bisogno di convertire i nostri dati in un formato compatibile, ad esempio un oggetto String. Base64 permette di convertire i dati non elaborati in una rappresentazione di stringa che contiene solo i caratteri consentiti dal formato XML. Crittografare la chiave e il valore in modo un utente malintenzionato non può capire che un valore potrebbe essere per. Nell'esempio precedente, encryptedKey ed encryptedValue sono entrambe matrici di byte[] crittografati restituite dal nostro metodo di encryptBytes(). Il IV e il sale possono essere salvati nel file di preferenze o come file separato. Per ottenere indietro i byte crittografati dalla SharedPreferences, possiamo applicare un Base64 decodificare la stringa memorizzata.

Dati che puliscono insicuri da vecchie versioni

Ora che i dati memorizzati sono sicuri, può essere il caso che avete una versione precedente dell'app che aveva i dati memorizzati in modo non sicuro. Un aggiornamento, i dati potrebbero essere spazzato via e re-encrypted. Il seguente codice salviette sopra un file utilizzando dati casuali.

In teoria, si possono semplicemente eliminare le preferenze di condivise rimuovendo i file /data/data/com.your.package.name/shared_prefs/your_prefs_name.xml e your_prefs_name.bak, e cancellare le preferenze di in memoria con il seguente codice:

Tuttavia, anziché tentare di pulire i dati precedenti e la speranza che funziona, è meglio cifrare esso in primo luogo! Questo è particolarmente vero in generale per unità a stato solido che spesso si diffondono fuori dati-scrive a regioni diverse per prevenire l'usura. Ciò significa che anche se si sovrascrive un file nel filesystem, la memoria a stato solido fisica potrebbe conservare i dati nella posizione originale sul disco.

Conclusione

Che avvolge il nostro tutorial sulla memorizzazione di dati crittografati. In questo post, hai imparato in modo sicuro crittografare e decrittografare i dati sensibili con una password fornita dall'utente. È facile da fare quando si sa come, ma è importante seguire tutte le procedure consigliate per garantire i dati degli utenti sono veramente sicuri.

Nel prossimo post, prenderemo un'occhiata a come sfruttare il KeyStore e altre API correlate a credenziali per archiviare gli elementi in modo sicuro. Nel frattempo, Scopri alcuni dei nostri altri grandi articoli sullo sviluppo di app per Android.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.