Come posso proteggere totalmente una connessione tra due nodi?

0

Sto costruendo un server di autenticazione in python e mi chiedevo come avrei potuto proteggere totalmente una connessione tra due peer? Non riesco a vedere come in alcun modo un utente malintenzionato non sarebbe in grado di copiare pacchetti e semplicemente analizzarli se capisce cosa viene in quale ordine.

Ammettere uno schema server client. Il cliente richiede un account. Anche se SRP, i pacchetti possono essere copiati e inviati in seguito per consentire il login.

Quindi ora, se aggiungo la crittografia a chiave pubblica-privata, come posso inviare la chiave pubblica a vicenda senza passare in un canale non crittografato?

Scusa se le mie domande rimangono oscene o sembra che non mi sia dispiaciuto per la domanda, ma ho davvero difficoltà a capire, come posso creare un processo di autenticazione senza avere molti buchi nella sicurezza.

    
posta cp151 05.08.2013 - 20:54
fonte

4 risposte

2

Fondamentalmente, la soluzione che stai cercando implicherà una sorta di trasferimento offline. I due computer che costituiscono i nodi endpoint del tuo tunnel sicuro devono essere "introdotti" tra loro, scambiandosi un segreto che permetterà a una parte di iniziare una connessione in modo tale che solo l'altro nodo possa capirlo.

Mentre questo segreto condiviso potrebbe essere la chiave simmetrica in sé, questo può essere problematico; gli algoritmi simmetrici sono più sicuri quando non si conosce nulla sulla chiave, anche se si tratta della stessa chiave usata per un'altra comunicazione. Un utente malintenzionato può osservare più "conversazioni" tra i nodi e, se sa che le conversazioni utilizzano la stessa chiave e IV, e se riesce a indovinare il testo normale (che è probabile che faccia come le informazioni inviate nelle fasi iniziali della comunicazione è abbastanza standard), può usare il testo cifrato per decodificare la chiave. Per questo motivo, la chiave simmetrica deve essere rinegoziata spesso, anche sullo stesso canale sicuro, a seconda della quantità di dati inviati.

La soluzione ideale è la crittografia asimmetrica o a chiave pubblica. Comprendi una cosa; le chiavi pubbliche sono destinate a essere pubbliche. Potresti dipingere a spruzzo la tua chiave pubblica sul lato della tua auto e guidarla attraverso Black Hat o DEF CON, e chiunque potrebbe fare è tentare di connettersi al tuo endpoint in modo sicuro (che non è più di quello che potrebbero fare per qualsiasi altro TLS -endpoint sicuro, e non andrebbero lontano qui, continua a leggere). La chiave privata è necessaria in qualsiasi schema a chiave pubblica per poter decifrare i dati in modo efficiente (e quindi perché le informazioni siano a rischio).

Ora, non puoi distribuire pubblicamente questo certificato; potresti, abbastanza plausibilmente, implementare una semplice variante dello schema TLS di base in cui il normale primo passo, la richiesta del client per il certificato del server, verrebbe ignorato dal server. Invece, il client deve già disporre di un certificato per il server "appuntato" nell'archivio certificati del sistema operativo e non dovrebbe (non potrebbe) verificare che abbia la versione più recente. Sarebbe quindi in grado di negoziare una connessione sicura senza che un singolo bit di dati effettivi venga inviato chiaramente (i dati a pacchetto sarebbero ancora in un pacchetto IP ben formato).

Concettualmente, funzionerebbe come segue; il client avrebbe la chiave pubblica del server, che è stata data offline (qui, l'unica differenza tra "client" e "server" che ci interessa è che il client è l'unico che avvia la comunicazione, entrambi i computer possono essere "server" "in altri sensi della parola, come i file server nel cloud). Il server avrebbe la chiave pubblica del client, che ha ricevuto offline. Il client crittografa una richiesta utilizzando la chiave pubblica del server, che conterrà il certificato del cliente. Quella richiesta va all'IP del server, e solo il server può decrittografarlo, anche se qualcun altro stava sniffando o spoofando il traffico sullo stesso indirizzo IP. La richiesta può contenere un nonce, ad esempio un semplice valore contatore, impedendo attacchi di riproduzione (il server può ignorare più richieste dallo stesso client con lo stesso nonce, sebbene debba decodificare ogni richiesta ricevuta per determinarlo, il che potrebbe renderlo vulnerabile a DDoS).

Il server utilizza quindi il certificato client, che può verificare in modo indipendente come client autorizzato perché una copia esatta del certificato client risiede nell'archivio del sistema operativo del server, per inviare una negoziazione di chiavi simmetriche. Da questo punto lo schema è praticamente identico alla negoziazione TLS a due certificati; il server invia al client la richiesta di negoziazione della chiave, il client riceve, imposta il proprio codice e restituisce un riconoscimento crittografato simmetricamente o l'altra metà del protocollo di scambio di chiavi in modo che il server ora sappia che sta parlando la stessa lingua. Da quel momento, client e server possono comunicare utilizzando il canale simmetrico. Tutto questo, senza che un osservatore di terze parti vedesse alcun pacchetto di dati in testo semplice.

Ora, questo è solo per creare un canale sicuro. Anche se il nodo client ha un IP statico, è sempre bene verificare successivamente, dopo aver negoziato il tunnel sicuro, che l'essere umano che controlla il computer dall'altra parte è autorizzato a utilizzare il sistema. Scambio di credenziali come nome utente / password o l'immissione di un valore di chiave a tempo limitato generato da un fob, sono mezzi comuni e perfettamente fattibili per autenticare l' utente dei computer autenticati.

    
risposta data 05.08.2013 - 22:00
fonte
1

Se una chiave simmetrica è già condivisa, è possibile utilizzare un semplice contatore per impedire la riproduzione. Solo i messaggi che hanno senso e hanno un conteggio valido devono essere onorati e un utente malintenzionato può essere in grado di entrare, ma non sarebbe in grado di dare un senso al traffico o aggiungere istruzioni alla serie.

Allo stesso modo, per la crittografia asimmetrica, le chiavi pubbliche sono pubbliche e possono essere semplicemente condivise allo scoperto. Questi possono quindi essere utilizzati per scambiare una chiave simmetrica per la comunicazione effettiva e la risposta alla sfida può essere utilizzata per impedire la riproduzione dell'autenticazione asimmetrica. La chiave principale è che la fiducia nella chiave pubblica deve essere stabilita, questo può essere fatto verificando l'identificazione digitale della chiave pubblica tramite un canale sicuro (come fare una telefonata) o fatto firmando la chiave pubblica in un certificato ( come avviene con i certificati SSL da un'autorità di certificazione). In alternativa, una rete di fiducia può essere utilizzata per dare fiducia che la chiave privata corrispondente di una chiave pubblica è detenuta dall'individuo per cui il pubblico dichiara di essere a favore.

    
risposta data 05.08.2013 - 21:18
fonte
1

Non reinventare la ruota e non complicare eccessivamente le cose.

Basta configurare un IPSec VPN tra i due nodi e passare il traffico su quello.

Lascia le cose sulla sicurezza alle persone che sanno come codificare la sicurezza e concentra i tuoi sforzi sui bit del codice Python necessari per il business attuale piuttosto che perdere tempo a codificare, testare e eseguire il debug dei canali TLS o qualsiasi altra cosa .

    
risposta data 04.08.2014 - 19:20
fonte
0

Un minimo assoluto di traffico non protetto potrebbe essere un cretificate (probabilmente autofirmato, forse una tantum o unico per utente). Tutto il traffico in corso può essere inviato attraverso un canale crittografato con SSL. Una sicurezza aggiuntiva può essere fornita da Session e / o One-time key per un ulteriore livello di crittografia sopra il Tunnel SSL. L'autenticazione con challenge / response e l'accordo di chiave Diffie-Hellmann per Session dovrebbero bloccare la maggior parte degli attaccanti senza accesso fisico a entrambi i lati del collegamento di comunicazione.

    
risposta data 05.08.2013 - 21:50
fonte

Leggi altre domande sui tag