Comunicazione server sicura in un'applicazione Android

Naviga le tue risposte
1

Prima di tutto, non ho una solida esperienza nella sicurezza delle informazioni e ho solo bisogno di alcune linee guida di base per la mia domanda. Ho postato la stessa domanda su crittografia stackexchange, ma questo sembra essere il posto più appropriato.

Quindi ci sono un'applicazione Android e un server HTTP (S) remoto. Per accedere alle funzionalità del server, l'applicazione deve ricevere un token (generato per ogni singolo dispositivo in base all'id del dispositivo) e per eseguire questa app è necessario fornire una chiave API valida.

Supponiamo che la comunicazione con il server sia sicura e che il pericolo principale per un attacco sia quello di decodificare l'applicazione. Non esiste una difesa al 100% contro il reverse engineering, ma l'eseguibile dex dell'app (virtual machine bytecode) viene offuscato utilizzando strumenti specializzati.

Quindi la domanda è quale sia il modo migliore per memorizzare la chiave API?

Attualmente sto considerando due opzioni:

  1. La chiave API è memorizzata all'interno della parte di codice nativo dell'applicazione, no in testo semplice, ma crittografato con un algoritmo molto complesso e quindi più difficile da decodificare rispetto al bytecode VM. Quindi ho bisogno di un metodo per eliminare l'attacco di replay, in cui un utente malintenzionato può semplicemente chiamare a specifica funzione nativa e ottenere la chiave. Assumiamo che tutti i nativi il codice è una casella nera per un utente malintenzionato.
  2. Non utilizzare affatto una chiave API fissa, ma usa una sorta di API dinamica chiave per autenticare sul server per ricevere un token. Inoltre implementa tutte le informazioni relative alla sicurezza nel codice nativo.
posta bvk256 26.12.2016 - 12:16
fonte

1 risposta

2

API key is stored inside native code portion of the application, not in plain text, but encrypted with an algorithm that is very complex and thus harder to reverse engineer than VM bytecode. So I need a method to eliminate replay attack, where an attacker can just call a specific native function and get the key. We assume that all native code is black box to an attacker.

Questa è sicurezza attraverso l'oscurità. Sebbene abbia un certo senso rallentare l'aggressore, non è affatto un meccanismo che fornisce sicurezza reale, ad es. prevenzione degli attacchi.

So the question is what the best way to store the API key?

Per definire le difese è necessario definire il modello di minaccia: che tipo di minacce stai proteggendo? Reverse engineering utente? App di malware? Radiando in remoto il dispositivo tramite una vulnerabilità? Questi vettori di minacce suggeriscono difese diverse.

Mettendo a parte la sicurezza attraverso l'oscurità, potresti voler proteggere la chiave API crittograficamente:

  1. Rendilo casuale e crittograficamente strong (ad esempio forza da dura a forza bruta)
  2. Criptalo con un segreto, che non è memorizzato sul dispositivo: PIN / password / impronta digitale.
  3. Se stai proteggendo contro il proprietario del dispositivo (che è leggermente diverso da quello che stai scrivendo), non c'è una buona tattica di prevenzione delle minacce, mi spiace.
  4. Per evitare attacchi di replay, avrai bisogno della chiave dinamica, che viene aggiornata ad ogni comunicazione riuscita con il server.

Note:

  1. Cerca di evitare encrypted with an algorithm that is very complex and thus harder to reverse engineer than VM bytecode , perché abusa del principio di Kerckhoffs ( link 's_principle), e ti porta a luoghi bui.
  2. Affidati a una buona crittografia comprovata e gestisci correttamente il segreto. Derivare / nascondere il segreto vicino ai dati protetti finirà male prima o poi - questa è la sicurezza dell'acciaio attraverso l'oscurità, una buona funzionalità aggiuntiva ma nessuna base per una buona sicurezza.
risposta data 26.12.2016 - 14:52
fonte

Leggi altre domande sui tag

Sfruttare il percorso del servizio non quotato non funzionante Sulla piattaforma Android, è sicuro utilizzare uno schema URI personalizzato per ricevere una risposta di autorizzazione OAuth 2.0 dalla piattaforma Google Identity?