Best practice per crittografare i dati in un'applicazione Android

Userò semplicemente SSL con una chiave pubblica hardcoded del server. Nessuno in arrivo può manipolare o leggere ciò che hai inviato. Non c'è bisogno di inventare il tuo protocollo.

Ma ovviamente l'utente stesso può manipolare e leggere i dati in questo modo, ma risolvere questo è un problema di DRM e non un problema di sicurezza.

Credo che BouncyCastle possa essere usato per quell'Android. Preferisco TLS 1.2 con una ciphersuite basata su DHE AES128, ma a seconda di cosa supporta il server, potrebbe essere necessario eseguire il downgrade a una suite minore.

L'implementazione della propria soluzione crittografica ad hoc non è una buona idea. Probabilmente avrai qualcosa di sbagliato. (Ad esempio, AES con una passphrase hardcoded è terribile . Chiunque può ottenere la passphrase semplicemente scaricando l'app ed estraendo la passphrase. Non so perché dubiti che qualcuno lo farebbe.)

Raccomando di utilizzare soluzioni standard e ben controllate. Se hai un canale di comunicazione che devi proteggere, usa SSL / TLS. Se si desidera proteggere i dati memorizzati, utilizzare GPG / PGP / OpenPGP. Ci sono librerie e codice disponibili per entrambi che dovrebbero renderli facili da integrare nel tuo software.

Probabilmente opterei per la soluzione menzionata dall'OP, e fare uso di RSA e avere solo la chiave pubblica nell'applicazione. In genere si desidera evitare che l'applicazione sia in grado di eseguire sia la crittografia sia la decrittografia (in particolare con una chiave codificata) poiché la chiave finirà per uscire. Se l'input dell'utente è possibile, allora è possibile anche la crypto simmetrica.

Esistono strumenti di reverse engineering per cercare funzioni di crittografia e hash ben conosciute tramite gli sbox in uso, e di solito è abbastanza semplice estrarre le chiavi se le memorizzi nel binario.

Ricorda che rsa è piuttosto lento, il che è uno dei motivi per cui la maggior parte degli usi comporta l'uso di crittografare una chiave simmetrica che viene utilizzata per eseguire la crittografia effettiva.

I'm still pondering about what would be the best way to encrypt the data.

Se si desidera memorizzare i dati sul dispositivo stesso, è possibile chiedere una password utente e derivare una chiave simmetrica utilizzando una funzione di derivazione della chiave. Bcrypt e PBKDF2 sono esempi ben noti.

Il modo migliore per crittografare i dati non è sul lato client. Tramite POST HTTP i dati tramite un tunnel TLS 1.2 correttamente configurato, si può essere certi della riservatezza della rete. Implementando solide pratiche di sviluppo sicure (ad esempio OWASP ASVS L4) insieme a test periodici, ma rigorosi (ad es. Test di penetrazione delle applicazioni avanzate con Burp Suite Professional, wXf / Buby e fuzzdb) - si può aiutare a prevenire il compromesso sul lato server, sebbene certamente questo non è limitato al solo sviluppo, ma anche implementazione sicura, operazioni sicure, ecc. I programmi ISO 27k sono normalmente consigliati per questi tipi di ambienti.

Di solito non è consigliabile memorizzare dati sul lato client che rappresentino un compromesso tra informazioni specifiche personali o critiche per l'applicazione, crittografate o meno. Ad esempio, l'archiviazione (o anche la memorizzazione per troppo tempo) di credenziali attive su un'applicazione bancaria, in particolare con nomi utente, password, nomi reali, numeri di account, ecc. È un assoluto no-no.