Vuoi l'autenticazione reciproca tra client e server.
Come per il protocollo SSL / TLS , questo è supportato con certificati client. Sia il server che il client hanno un certificato; il server mostra il suo certificato al client e quindi richiede al client di mostrare il proprio certificato e provare il controllo della chiave privata corrispondente. Funziona, questo è standard, questo è supportato dalle solite librerie; ma richiede, naturalmente, che il client abbia un certificato installato.
Il modello di certificato doppio va bene nei casi in cui il client non si fida effettivamente del server. Nel tuo caso, puoi fare qualcosa di più semplice, perché la tua app ha fiducia nel tuo server (l'app vuole essere sicura che parli al server originale, ma una volta che ha questa sicurezza, parla liberamente senza restrizioni): puoi usare il mostra il modello di password che è veramente comune in tutto il Web. In tutti i dettagli:
- Quando l'applicazione viene installata o avviata per la prima volta, comunica con il server, identificandolo tramite il suo certificato. Il protocollo SSL garantisce che ciò che l'app invierà vada davvero solo al tuo server e non può essere alterato o spiato mentre è in transito.
- Durante la prima connessione, l'app genera un valore casuale K e lo memorizza localmente; dice anche al tuo server: "Ciao, sono un nuovo cliente e la mia chiave è K ".
- Il tuo server memorizza nel suo database le informazioni sul nuovo client, incluso h (K) dove h () è una funzione di hash crittografica (ad esempio, SHA-256 ).
- Più tardi, quando l'app si ricollega, apre una nuova connessione SSL, anche in questo caso assicurandosi che parli con il server giusto (grazie al certificato del server); e invia quindi K al server. Il server calcola h (K) (sul valore K dal client) e lo confronta con il valore memorizzato; se c'è una corrispondenza, il server sa che è lo stesso client di prima.
Quando K è qualcosa che l'utente umano ricorda e digita (una "password"), deve essere prestata molta attenzione, specialmente con la funzione hash h () che dovrebbe quindi essere qualcosa di molto più complesso di SHA-256. Ma qui, il valore K viene generato e memorizzato da un'applicazione, che può utilizzare un PRNG crittograficamente strong e gestire un K di 128 bit o più, che sarà immune a il tipo di attacchi che si applicano alle password.
Naturalmente, tutto ciò riguarda la protezione delle comunicazioni client-server da parte di estranei. Il cliente stesso (ovvero l'utente dell'app) può eseguire il reverse-engineering dell'app a volontà; non puoi assicurarti che ciò che è sul lato client sia "la tua app", non modificato. Tuttavia, SSL e il concetto di show-the-password ti permettono di assicurarti che se i dati finiscono nelle mani sbagliate, il cliente stesso è disonesto (o il suo smartphone è stato rubato).