Protezione della comunicazione [Autenticità, privacy e integrità] con l'app mobile?

Question

Un'app Android/Iphone accederà ai dati dell'applicazione dal server. [Django-Python]

Come posso proteggere la comunicazione con l'app mobile?

Aspettativa: Abbastanza sicuro per informazioni sensibili come le password, non ci sarà alcun modo diretto di decrittazione tranne brute-forzatura.

miei requisiti:

• autenticazione [l'applicazione è autorizzata solo]
• integrità [I messaggi non devono essere modificati in mezzo]
• Privacy [La comunicazione non deve essere leggibile se annusato]

Il mio impegno:

• SSL autentica solo il server, non il client.
• posso-non usare una crittografia simmetrica [Fornisce solo Privacy]
• firma digitale non è possibile [Manca Privacy]
• PGP pieno riempie tutti e 3 i requisiti.

Problema:

• PGP richiede ai tasti memorizzare sul client app.
• Non sembra esserci un modo sicuro per proteggere le chiavi sull'app client.
• Se la chiave è fuori, la crittografia PGP o Symmetric è ugualmente vulnerabile.
• Le chiavi PGP o tasti simmetrici di Reverse Engineering sono ugualmente difficili.
• In questo caso PGP è un onere non sense sul processore mobile.
• OAuth è di nuovo inutile, poiché ha anche una chiave client.

Quindi, come posso/devo andare avanti su questo? Come funziona il settore?

Devo implementare approccio informale:

• Usa semplice SSL e incrocio le dita?, poiché l'autenticazione non è possibile se le chiavi vengono rubate?(Autenticazione del server è il solo possibile con questo)

Aggiornamento:

Conclusione era di usare AES, dal momento che se riesco a tenere la chiave sicuro allora io sono buono come SSL. Inoltre, posso continuare a modificare i tempi di consegna della chiave per una maggiore sicurezza. Contribuisci se pensi che ci sia un modo migliore, leggi l'intero post prima di postare.

Answer 1

Stai lavorando su cattive informazioni. SSL può assolutamente autenticare il client, non è qualcosa che viene fatto per la maggior parte dei protocolli SSL in quanto il protocollo è (o almeno lo era) in genere utilizzato per proteggere i siti di e-commerce in cui l'autenticazione del server era importante ma lo faceva con il client non era importante e/o non fattibile. Quello che vuoi fare è utilizzare SSL reciprocamente autenticati, in modo che il tuo server accetti solo le connessioni in entrata dalla tua app e la tua app comunichi solo con il tuo server.

Ecco l'approccio di alto livello. Creare un certificato SSL del server autofirmato e distribuirlo sul proprio server web. Se utilizzi Android, puoi utilizzare lo strumento Keytool incluso con l'SDK di Android per questo scopo; se usi un'altra piattaforma di app come iOS, esistono strumenti simili anche per loro. Quindi creare un client autofirmato e distribuirlo all'interno dell'applicazione in un keystore personalizzato incluso nell'applicazione come risorsa (anche lo strumento keytool genererà questo). Configurare il server per richiedere l'autenticazione SSL sul lato client e accettare solo il certificato client generato. Configurare il client per utilizzare tale certificato sul lato client per identificarsi e accettare solo il certificato sul lato server installato sul server per quella parte di esso.

Se qualcuno/qualcosa di diverso dall'app tenta di connettersi al server, la connessione SSL non verrà creata, in quanto il server rifiuterà le connessioni SSL in ingresso che non presentano il certificato client che è stato incluso nell'app.

Un passo per passo è una risposta molto più lunga di quanto è giustificato qui. Suggerirei di farlo in fasi poiché ci sono risorse sul Web su come gestire il certificato SSL autofirmato sia in Android che in iOS, sia lato server che lato client. Nel mio libro c'è anche un passaggio completo, Application Security for the Android Platform, pubblicato da O'Reilly.

Answer 2

Utilizzare l'autenticazione del client con SSL o semplicemente sovrapporre l'autenticazione del client (nome utente/password, token, ecc.) Sopra SSL di autenticazione server.

(Edit: Spostando il commento qui, dal momento che non si adatta come un commento)

Elaborare un po ', qualsiasi informazioni di autenticazione deve essere memorizzato o inserito in app. Se hai persone che inseriscono la password ogni volta, non è necessario salvarla, ma è chiaramente scomodo. Puoi crittografarlo con una chiave specifica del dispositivo, quindi non è visibile sui dispositivi rooted. Con una chiave privata, è necessario proteggerla con una password inserita dall'utente (vedi sopra) o proteggerla dal sistema. È disponibile solo da Android 4.0 (ICS) con l'API pubblica al keystore di sistema, la classe KeyChain. In questo caso, l'utente deve sbloccare (utilizzando pattern/password o PIN) il telefono per accedere al keystore.

Answer 3

SSL ha un'autenticazione a due vie come già menzionato dagli altri commentatori. Ma, non penso che dovresti provare ad autenticare il client, ovvero l'app. Si autentica solo l'utente (proprietario della risorsa in termini Oauth) non l'agente o il client.

È un dato di fatto che le app mobili non possono contenere alcun segreto. Quindi non inserire mai certificati/password sul dispositivo.Tipico esempio negativo sarebbe quello di salvare il nome utente e la password in alcuni keystore di sistema, come il portachiavi IOS. Se l'utente dell'app non imposta la password sul telefono, l'intero keystore viene salvato in testo normale e chiunque può scaricare tutte le informazioni. Incorporare un certificato nell'app è quasi altrettanto sbagliato, diversamente da un server, il cellulare non è bloccato in una sala computer. Le persone li perdono.

Su questa base, è necessaria una soluzione basata su token, in modo che l'app non debba contenere segreti. Si passano i segreti (credenziali di accesso dell'utente) e si cancellano immediatamente dalla memoria. Hai solo bisogno di tenere il token, che sarà di breve durata (scade tra 30 minuti ecc.)

Oauth 2.0 Il flusso implicito è progettato per risolvere questo problema. Tuttavia, è tutt'altro che perfetto. E ci sono alcuni problemi fondamentali con le specifiche Oauth 2.0. In particolare, l'implementazione di questo flusso richiede che l'app utilizzi UIWebView (browser incorporato), che a sua volta può essere un'esperienza utente insicura e negativa. Quindi questo praticamente elimina tutti i flussi basati sul reindirizzamento. L'unica app conosciuta che utilizza il flusso di reindirizzamento di OAuth 2 è Facebook, ed è mal fatta.

OAuth 2.0 Il flusso del proprietario di risorse è un'opzione. Con questo flusso, l'intero livello di sicurezza dei sistemi può essere alto quanto la soluzione B2C: una soluzione di banking online basata su browser come esempio. Questo significa che chiunque abbia la password del nome utente sarà in grado di accedere alle risorse sul server - lo stesso livello di sicurezza per una soluzione basata su browser.

Tuttavia, è necessario fare attenzione, come già detto, le specifiche OAuth 2 hanno alcuni problemi fondamentali: in questo caso, non è possibile seguire le specifiche per implementare la logica di aggiornamento dei token, che in genere implica l'utilizzo di un mai -expire token refreshing, che può essere visto come l'implementazione di Google OAuth 2. Quel token diventa quindi un segreto stesso - sconfigge lo scopo di usare OAuth.

Una soluzione è di rinnovare automaticamente il token in base all'ultima attività.

In ogni caso, la sicurezza delle app mobili non è affatto un argomento nuovo, ma purtroppo non disponiamo ancora di strumenti/meccanismi standard per risolvere queste sfide uniche.

Ecco perché le banche pagano milioni di persone a fare il loro soluzione di mobile banking e tuttavia ancora non riescono (http://hothardware.com/News/Mobile-Banking-Apps-for-iOS-Vulnerable-to-Man-in-the-Middle-Attacks/) ;-)