it-swarm-eu.dev

Crittografa i dati all'interno dell'app mobile e invia al servizio web

Sto sviluppando un'applicazione mobile per Android e iOs. Qual è la migliore pratica quando si tratta di crittografia dei dati all'interno dell'applicazione mobile che verrà inviata a un servizio web?

Fondamentalmente genererò una stringa che consiste in alcuni parametri come GPS e tempo. Questa stringa deve essere crittografata e quindi passata a un servizio Web.

Ho considerato di farlo con la crittografia asimmetrica. Crittografare la stringa con la chiave pubblica (che deve essere codificata?) E decrittografare con la chiave privata. Poiché ogni applicazione può essere retroingegnerizzata, ciò non è affatto sicuro. Dopo aver trovato la chiave pubblica codificata e la funzione di generazione della stringa è facile forgiare quello che vuoi.

Ogni input è molto apprezzato.

EDIT: un approccio più chiaro alla mia domanda: una funzione della mia applicazione genererà una stringa e un'altra funzione crittograferà questa stringa, che verrà inviata a un server. Come posso impedire che una stringa creata automaticamente venga passata alla funzione di crittografia dopo il reverse engineering della mia applicazione? In altre parole, posso garantire con una tecnica di crittografia che i dati inviati dalla mia applicazione mobile a un server non siano realizzati da qualcun altro?

14
niklr

Non puoi. Questo è un principio fondamentale dell'informatica generale.

Stai incontrando la massima di Shannon:

Il nemico conosce il sistema. Si dovrebbero progettare sistemi partendo dal presupposto che il nemico acquisirà immediatamente piena familiarità con loro.

Giusto per chiarire il mio punto di vista: stai dando a qualcuno una macchina e stai chiedendo loro di guidare sempre e solo in un posto particolare. Nulla impedisce loro di decidere di andare altrove - ti affidi a loro aderendo alla tua richiesta.

Se il tuo meccanismo di sicurezza si basa sulla speranza che qualcuno non guardi il tuo eseguibile e scopra il tuo metodo di crittografia/chiavi incorporate, allora non è un meccanismo di sicurezza; è un meccanismo di oscurità.

Da quello che posso dire, stai cercando di imporre che gli utenti si trovino all'interno di un'area specificata tramite le coordinate GPS e desideri anche assicurarti che non falsino tali coordinate. Questo impossibile da eseguire su una piattaforma informatica generica come uno smartphone. Diamo un'occhiata allo stack tecnologico:

  • La tua webapp si trova nella "nuvola" da qualche parte. Tu lo controlli interamente.
  • L'app si trova su un telefono. Hai un controllo minimo su questo, se presente. I possibili vettori di attacco includono reverse engineering, modifica delle app, richieste di webapp dirette, modifica della memoria, ecc.
  • Il sistema operativo dello smartphone (ad es. Android o iOS) viene eseguito sul dispositivo. Non hai alcun controllo su questo. È responsabile della comunicazione con il dispositivo GPS e della traduzione dei dati in coordinate utilizzabili. I possibili vettori di attacco includono : false coordinate GPS tramite pannello di test (la maggior parte dei telefoni ha questa funzione), driver GPS modificato, API GPS agganciate, ecc.
  • Il modulo GPS è all'interno del dispositivo. Non hai alcun controllo su questo. Il modulo GPS è responsabile della comunicazione con i satelliti GPS e della trasmissione dei dati alla CPU tramite un bus standard. I possibili vettori di attacco includono: man-in-the-middle sul bus, modulo GPS falso sostitutivo, segnale satellitare GPS falso dalla radio definita dal software, ecc.

Quindi impossibile imponi che le coordinate GPS che ricevi nella tua webapp siano corrette, poiché potrebbero essere state manomesse a livello di app, a livello di sistema operativo, a livello di hardware o persino a livello di segnale GPS. Oppure, salvo tutto ciò, qualcuno potrebbe semplicemente saltare completamente il telefono e inviare manualmente richieste al tuo webapp contenente dati fasulli!

La soluzione è accettare il rischio o modificare il modello di sicurezza.

21
Polynomial

Dovresti sempre usare SSL.

SSL ha una chiave pubblica integrata e fornisce "autenticazione", il che significa che il server con cui stai comunicando è in realtà il servizio web che desideri e non un impostore.

Dal momento che non indichi diversamente, o qualsiasi altra esigenza di cui hai bisogno, penso che SSL risolverà tutte le tue preoccupazioni sull'invio di dati a un server e sulla loro sicurezza durante il trasporto.


pdate

In base ai tuoi requisiti aggiornati nei commenti, capisco che vuoi impedire lo spoofing dei dati GPS inviati al tuo servizio web.

Se non hai alcun controllo sul dispositivo (amministrativo o di altro tipo) ciò che @Polynomial dice è corretto. Se stai creando un sistema chiuso, incorporato o in una società, potresti avere più opzioni.

Supponiamo di avere il pieno controllo di ogni telefono su cui verrà eseguita l'applicazione. Ciò significa bloccare il telefono, mantenere il controllo esclusivo della password dell'amministratore e non consegnarla mai agli utenti finali.

Successivamente, è possibile assegnare a ciascun dispositivo una chiave univoca per crittografare i dati da inviare a un servizio Web.

Se un determinato telefono è compromesso, sarai in grado di determinare quale dispositivo era basato sul tasto utilizzato.

4

La migliore pratica dipende dall'uso esatto.

Quello che raccolgo dalla tua domanda è che hai un'app che ti invia dati e tempo GPS, come un'applicazione "footprint". Vuoi assicurarti di non ricevere dati falsi, e quindi vuoi assicurarti che i dati provengano dal tuo vero cliente e non da un falso.

Bene, sfortunatamente, come hanno affermato altre risposte, è impossibile. Dato il file APK per la tua app, qualcuno può decompilarlo abbastanza facilmente in Java di Java, forse non elegante come il tuo sorgente, ma sicuramente realizzabile. Possono quindi usare il tuo codice per costruire il loro propria app, che comunica con la tua esattamente come ti aspetti e la usa per fornirti dati falsi.

Pertanto, qualunque schema tu utilizzi per il trasporto dei dati dovrebbe mai fidarsi del cliente. Dovrebbe invece fidarsi di tente.

Considera questa soluzione; l'app server è firmato con un certificato di chiave pubblica attendibile (potrebbe, in questa circostanza, essere considerato attendibile per il solo motivo che l'applicazione conosce il certificato esatto che deve essere dato; questo si chiama "certificato" pinning "e funziona indipendentemente dal fatto che il certificato sia stato firmato da una CA globale o meno). Su richiesta, presenta questo certificato a chiunque lo richieda; sono informazioni pubbliche, potresti intonacare questa cosa su ogni forum di hacker su Internet e non sarebbe meno sicuro. Il cliente utilizza questo certificato per negoziare un tunnel di comunicazione sicuro; questa è roba abbastanza standard.

Ora hai riservatezza. Hai bisogno di autenticità; non importa che nessun altro possa ascoltare la conversazione tra voi due se non sapete con certezza chi è dall'altra parte. Quindi, una volta aperto il canale, la prossima cosa che ti aspetti è una richiesta di autenticazione contenente le credenziali dell'utente. È necessario rifiutare qualsiasi richiesta di invio di dati GPS se la sessione non è stata autenticata. Le credenziali fornite dall'utente in tale richiesta potrebbero essere il nome utente e la password, l'indirizzo IMEI o MAC del telefono, il codice di 10 cifre da un portachiavi crittografico, qualunque cosa tu ritenga necessario per garantire che solo = un determinato utente potrebbe essere in grado di fornire tali credenziali.

Una volta che hai quelle credenziali e hai verificato che corrispondono alle aspettative, comunque tu voglia farlo, le rispedisci un "token di autenticazione". Questo è semplice come un numero casuale distinto da quello utilizzato per qualsiasi altra sessione aperta. Un GUID V4 è anche una buona scelta. Questo identificatore sarà richiesto come parte di qualsiasi richiesta di invio o ricezione di dati su questo canale durante questa sessione, sarà solo accettato su questo particolare canale e solo finché poiché questa sessione unica è aperta.

Dopo aver impostato tutto ciò, in genere è possibile considerare attendibile qualsiasi chiamata di servizio effettuata sul canale protetto di quella sessione che include il token di autenticazione corretto. Probabilmente dovresti includere un'altra cosa, che è una misura per proteggerti dagli attacchi replay. Un attaccante non deve sapere esattamente cosa viene inviato avanti e indietro per incasinarti semplicemente ripetendo ciò che è già stato detto. Quindi, per garantire che il tuo sistema gestisca un messaggio unico una sola volta, indipendentemente da quante volte viene inviato, ogni messaggio dovrebbe includere un nonce, un valore univoco usato una volta. Un semplice valore del contatore di sequenze, che fa parte della struttura della richiesta e crittografato dal canale sicuro, dovrebbe essere sufficiente per questo; quindi, tutto ciò che devi fare è ignorare qualsiasi messaggio il cui numero di sequenza non è il successivo che ti aspetti di ricevere dal client (può esserci una tolleranza di errore inerente a questo, ma mai accetta lo stesso tipo di richiesta di servizio dallo stesso client con lo stesso numero di sequenza due volte).

4
KeithS