Cripta i dati nell'app mobile e invia al servizio web

Non puoi. Questo è un principio fondamentale del calcolo general purpose.

Ti stai imbattendo nella massima di Shannon:

The enemy knows the system. One ought design systems under the assumption that the enemy will immediately gain full familiarity with them.

Solo per chiarire il mio punto: stai dando a qualcuno un'auto e chiedendo loro di guidare sempre e solo verso un luogo particolare. Nulla impedisce loro di decidere di andare da qualche altra parte - si basa su di loro aderendo alla tua richiesta.

Se il tuo meccanismo di sicurezza fa affidamento 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 far rispettare che gli utenti si trovano all'interno di un'area specifica tramite le coordinate GPS, e vuoi anche assicurarti che non falsino quelle coordinate. Questo non può essere fatto su una piattaforma di calcolo generica come uno smartphone. Diamo un'occhiata allo stack tecnologico:

• La tua webapp si trova in "the cloud" da qualche parte. Tu controlli tutto questo.
• La tua app si trova su un telefono. Hai un controllo minimo su questo, se esiste. I possibili vettori di attacco includono reverse engineering, modifica dell'app, richieste dirette webapp, modifica della memoria, ecc.
• Il sistema operativo dello smartphone (ad esempio Android o iOS) viene eseguito sul dispositivo. Non hai il controllo su questo. 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 si trova all'interno del dispositivo. Non hai il controllo su questo. Il modulo GPS è responsabile della comunicazione con i satelliti GPS e trasmissione dei dati alla CPU tramite un bus standard. I possibili vettori di attacco includono: man-in-the-middle sul bus, modulo GPS sostitutivo, segnale satellitare GPS falso dalla radio definita dal software, ecc.

Quindi non puoi imporre che le coordinate GPS che ricevi nella tua webapp siano corrette, dal momento che potrebbero essere state manomesse a livello di app, livello del sistema operativo, livello hardware o persino il GPS livello del segnale. Oppure, a meno che non sia così, qualcuno potrebbe semplicemente saltare il telefono interamente e inviare manualmente richieste al tuo webapp contenente dati falsi!

La soluzione è accettare il rischio o cambiare il tuo modello di sicurezza.

Devi sempre usare SSL.

SSL ha una chiave pubblica integrata e fornisce "autenticazione", il che significa che garantisce che il server con cui stai comunicando sia effettivamente il webservice che desideri e non un impostore.

Dato che non si indica il contrario, o qualsiasi altra esigenza che si ha, penso che SSL risolverà tutte le vostre preoccupazioni sull'invio di dati a un server e sulla sua messa in sicurezza.

Aggiorna

Sulla base dei tuoi requisiti aggiornati nei commenti, ho capito che vuoi impedire lo spoofing dei dati GPS inviati al tuo webservice.

Se non si ha il controllo del 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 la tua applicazione. Ciò significa bloccare il telefono, mantenendo il controllo esclusivo della password dell'amministratore e non darlo 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 sulla chiave utilizzata.

La migliore pratica dipende dall'uso esatto.

Ciò che ricavo dalla tua domanda è che hai un'app che ti invia dati e ora GPS, come un'applicazione "footprint". Desiderate assicurarvi di non essere alimentati con dati falsi e quindi volete assicurarvi che i dati provengano dal vostro vero cliente e non da un falso.

Beh, sfortunatamente, come hanno affermato altre risposte, è impossibile. Dato il file APK per la tua app, qualcuno può decompilarlo in modo abbastanza fattibile nel codice sorgente Java, possibilmente non elegante come la tua fonte, ma sicuramente funzionale. Possono quindi utilizzare il tuo codice per creare la propria app, che comunica con la tua esattamente come ti aspetti e usarla per fornirti dati falsi.

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

Considera questa soluzione; il tuo server delle app è firmato con un certificato di chiave pubblica attendibile (potrebbe, in questa circostanza, essere considerato attendibile per la sola ragione per cui la tua applicazione conosce il certificato esatto che dovrebbe essere dato; questo è chiamato "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 chi lo richiede; è un'informazione pubblica, potresti incollare questa cosa su ogni forum degli hacker su Internet e non sarebbe meno sicuro. Il tuo 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 che il canale è aperto, la prossima cosa che ti aspetti è una richiesta di autenticazione contenente le credenziali dell'utente. Devi rifiutare qualsiasi richiesta di invio di dati GPS se la sessione non è stata autenticata. Le credenziali che l'utente fornisce in tale richiesta potrebbero essere il nome utente e la password, l'IMEI o l'indirizzo MAC del telefono, il codice a 10 cifre da un crypto key fob, qualsiasi cosa si ritenga necessaria per garantire correttamente che solo un particolare utente potrebbe essere in grado di fornire tali credenziali.

Una volta ottenute tali credenziali e verificato che corrispondono alle aspettative, tuttavia, si desidera farlo, restituire loro un "token di autenticazione". Questo è semplice come un numero casuale diverso da quello utilizzato per qualsiasi altra sessione aperta. Anche un V4 GUID è 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 essere accettato su questo particolare canale e solo fino a quando come questa sessione unica è aperta.

Una volta impostato tutto questo, qualsiasi chiamata di servizio effettuata sul canale sicuro di quella sessione che include il token di autenticazione corretto può generalmente essere considerata attendibile. Probabilmente dovresti includere un'altra cosa, che è una misura per proteggersi dagli attacchi di replay. Un attaccante non deve sapere esattamente cosa viene inviato avanti e indietro per rovinarti semplicemente ripetendo ciò che è già stato detto. Pertanto, per garantire che il tuo sistema gestisca un messaggio unico una sola volta, indipendentemente dal numero di volte inviato, ogni messaggio dovrebbe includere un nonce , un valore univoco utilizzato una volta. Un semplice valore del contatore di sequenza, 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 qualche tolleranza d'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).