Come "associare" un'applicazione client / server in modo sicuro?

Question

Come "associare" un'applicazione client / server in modo sicuro?

#1 da (3 voti)
#2 da (1 voti)

3

Per favore perdonami se la mia domanda è una riformulazione di un problema comune, ma non sono sicuro di cosa cercare!

Il mio caso d'uso è un programma client-server. Il server viene eseguito sul PC dell'utente e il client viene eseguito sui dispositivi mobili. I client devono essere abbinati al server in modo sicuro (ad es. Inserire un PIN o una password una tantum) e una volta completato l'accoppiamento, è necessario assicurarsi che il client possa verificare in sicurezza il server, prima di trasmettere i dati riservati da di volta in volta.

In precedenza nella mia ricerca ho pensato che sarebbe stato possibile utilizzare le chiavi RSA, ma questo approccio sembrava troppo nuovo e complesso da implementare in modo sicuro.

La mia idea attuale è di implementare uno schema come questo:

All'accoppiamento iniziale, scambio di chiavi Diffie-Hellman tra client e server
Server visualizza un PIN casuale e il client lo inserisce per la verifica (impedendo il mitm). Sono consentiti solo un paio di tentativi PIN errati prima che il tentativo di abbinamento venga interrotto.
Poiché il server e il client ora concordano su una chiave segreta, possiamo semplicemente crittografare tutte le comunicazioni con questa chiave. Sebbene il server possa avere più client noti (ad esempio fino a dieci client), il server potrebbe semplicemente controllare qualsiasi connessione in entrata con tutte e dieci queste chiavi. E poiché il client utilizza la stessa chiave segreta, se il server è un impostore, la decrittografia non sarà possibile.

Ora la mia domanda è uno schema ragionevole o esiste un protocollo standard chiaro che può raggiungere obiettivi simili?

authentication cryptography encryption

posta fabspro 20.10.2015 - 01:30

fonte

2 risposte

Leggi altre domande sui tag authentication cryptography encryption

Un unico sito per segnalare virus sconosciuti Come si può eseguire codice all'entrata della cartella in Windows?

score 3 · Answer 1

Reinventare la ruota è una cattiva idea nello sviluppo del software in generale, ma soprattutto quando si tratta di sicurezza. Prima (o invece di) progettare il proprio protocollo di autenticazione, dovresti considerare quelli esistenti come TLS o Kerberos, capire come mitigano i possibili attacchi e forse anche scegliere un protocollo esistente da utilizzare nella tua applicazione. Eviterete molte insidie comuni, risparmiate sui tempi di sviluppo e la vostra app avrà una migliore compatibilità, se volete averla. Specificamente TLS sembra essere adatto al tuo caso d'uso.

A proposito, potresti spiegare come visualizzare un pin casuale impedirebbe gli attacchi MitM? L'attaccante non vedrebbe lo stesso pin pure?

score 1 · Answer 2

Può essere sicuro, ma il diavolo è nei dettagli. C'è un numero di cose che potrebbero essere fatte in modo errato lasciando il protocollo completamente aperto agli attacchi.

Diffie-Hellman primo troppo piccolo. Se esegui l'hardcode di un numero primo nel tuo protocollo, allora il primo deve essere più grande di quanto sarebbe se fosse generato dinamicamente.
Verifica PIN incline agli attacchi mitm. Un attacco di mitm attivo contro Diffie-Hellman è banale. Ecco perché hai bisogno del PIN, in primo luogo. Tuttavia, è necessario ricordare che lo scopo del PIN non è verificare il PIN ma piuttosto verificare la chiave. Se ad esempio si invia semplicemente il PIN così come avviene attraverso il canale crittografato stabilito con Diffie-Hellman, un avversario può semplicemente mitizzare la connessione e inoltrare il PIN ricevuto da un lato all'altro.
Utilizzo di una singola chiave per troppi dati. Più dati vengono inviati crittografati con la stessa chiave, più facile sarà per un avversario attaccare detta chiave. Il re-keying periodico sarebbe una buona idea. Non reinserire le chiavi in chiaro. Effettua il re-keying all'interno del canale protetto dalla chiave precedente, ma allo stesso tempo progetta il protocollo di re-keying in modo tale che sarebbe plausibilmente sicuro se non fosse stato all'interno del canale protetto. Questa è la difesa in profondità.
Se crittografate i dati in transito senza proteggere l'integrità utilizzando una sorta di codice di autenticazione dei messaggi, sarete vulnerabili a una vasta gamma di attacchi.

Quanto sopra non è in alcun modo un elenco esauriente di possibili punti deboli. Se riesci a trovare un protocollo ben noto esistente che soddisfi le tue esigenze, ti consiglio di utilizzarlo.

L'unica cosa che mi viene in mente dalla tua descrizione è il protocollo di accoppiamento Bluetooth. Purtroppo non conosco abbastanza il protocollo Bluetooth da consigliare a favore o contro il suo utilizzo.