Comunicazione sicura bidirezionale utilizzando due coppie di chiavi pubbliche / private?

3

Diciamo che voglio creare un protocollo per comunicare in modo sicuro tra due endpoint - ciascuno dei due endpoint conosce la chiave pubblica dell'altro e tutti i dati scambiati vengono codificati utilizzando la propria chiave pubblica e decrittografati utilizzando la chiave privata del destinatario. La mia domanda è a parte l'uomo nell'attacco centrale che può essere evitato usando un PKI (?), A quali altri tipi di attacco è vulnerabile questo protocollo? E in che modo è paragonato a SSL in quanto abbiamo rimosso il passaggio iniziale di handshake?

    
posta Ryan Saka 08.05.2013 - 23:53
fonte

3 risposte

3

Questo protocollo è vulnerabile a un attacco di riproduzione. In notazione comune

A -> I_B: {m}_PK(B)
I_A -> B: {m}_PK(B)
I_A -> B: {m}_PK(B)

Se m era un messaggio che diceva loan me $10 e B era un po 'ingenuo ...

Questo protocollo è anche vulnerabile agli attacchi di riordino dei messaggi, ad es.

A -> I_B: {m}_PK(B)
A -> I_B: {m'}_PK(B)
I_A -> B: {m'}_PK(B)
I_A -> B: {m}_PK(B)

Se assumiamo RSA, se non c'è padding, tale protocollo sarebbe debole per gli attacchi di crittografia omomorfici.

Vari altri attacchi sono ovvi ma non interessanti (come la negazione del servizio da parte dell'intruso che blocca tutti i messaggi, gli attacchi di dizionario che consentono all'hacker di verificare un'ipotesi del messaggio, gli attacchi di dizionario che consentono all'indicatore di rilevare i messaggi ripetuti, gli attacchi di troncamento dei messaggi ecc. .)

    
risposta data 08.05.2013 - 23:57
fonte
1

Un PKI è un sistema per consentire una distribuzione sicura della chiave pubblica. I certificati emessi dalla PKI consentono ai vari sistemi di conoscere le rispettive chiavi pubbliche con un certo livello di garanzia che le chiavi sono autentiche. Nel tuo caso, presumi già che ciascuno dei tuoi due endpoint conosca la chiave pubblica dell'altro endpoint, cioè che il problema con cui PKI si sforza di risolvere sia già stato risolto. Non c'è bisogno di un PKI nel tuo caso, quindi.

Questa conoscenza reciproca delle chiavi pubbliche può quindi essere trasformata in un canale protetto bidirezionale per i dati, ma non è una cosa facile da fare; non è possibile evacuare con un semplice "crittografiamo i dati con la chiave pubblica dell'altro sistema"; come altri hanno sottolineato, questo subirà attacchi di replay (almeno). Ci sono molti dettagli di cui preoccuparsi. Un protocollo in cui tutti questi dettagli sono stati trattati dolorosamente, lungo un corso di due decenni di interruzioni e correzioni, è, in effetti, SSL . Finora, molte persone che pensavano di poter fare meglio hanno fallito, a volte in modo esilarante, spesso in modo spettacolare. SSL include tutti i tipi di funzionalità che tengono traccia dei singoli blocchi di dati ("record" in linguaggio SSL) e rilevano in modo affidabile alterazioni esterne, inclusi pacchetti riordinati, rilasciati o duplicati; assicura anche la terminazione verificata (quando la connessione viene chiusa da una macchina, l'altra macchina ha una certa garanzia che questa è stata effettivamente attivata dall'altra macchina, non da un utente malintenzionato che inserisce un pacchetto RST falso).

Si noti che in SSL, il client e il server inviano le loro chiavi pubbliche l'un l'altro come parte delle catene di certificati. Questo supporta il modello PKI in cui un client (rispettivamente un server) impara una chiave pubblica del server (rispettivamente una chiave pubblica del client) attraverso la convalida del certificato. Tuttavia, nulla impone al client e al server l'elaborazione dei certificati in modo PKI X.509 puro. Ciò che importa è che il client (o il server) utilizzi la chiave pubblica corretta del server (o del client). Se il client conosce già la chiave del server, il client può semplicemente usarlo in SSL e ignorare qualsiasi blob che il server ha inviato come certificato. Pertanto, SSL non è intrinsecamente legato a X.509 oa qualsiasi altro tipo di PKI.

    
risposta data 05.07.2013 - 20:13
fonte
0

Oltre ai problemi di riproduzione e ordinamento identificati da jhoyla , non vi è alcuna autenticazione di origine di entità o messaggio in questo protocollo.

Qualsiasi parte con la chiave pubblica di entrambi i peer può inviare messaggi arbitrari al peer e il peer non ha modo di autenticarne l'origine. In effetti, potrebbero persino simulare una conversazione tra due peer, soprattutto se possono bloccare i messaggi in uscita dai partecipanti oi dettagli dello schema del numero di sequenza che hai implementato ha permesso ai messaggi dell'attaccante di "entrare per primi".

Poiché si tratta di una chiave pubblica, puoi tranquillamente presumere che l'utente malintenzionato abbia accesso ad essa.

    
risposta data 12.05.2013 - 20:58
fonte

Leggi altre domande sui tag