Attacco ad un protocollo di sicurezza
Ciao!
Mi trovo a provare a risolvere il seguente esercizio:
La prima domanda chiede di indicare quali proprietà garantisce il protocollo. E su questa non ho problemi.
Ecco la risposta:
La seconda domanda chiede di trovare un attacco che viola le proprietà sopra.
Ecco domanda e risposta:
Il mio problema è su questa risposta.
La risposta inizia con "il protocollo non è vulnerabile" dando l'idea che nessun tipo di attacco riesca a violarne le proprietà.
Però nelle righe successive cita solo l'utilizzo di un reflection attack.
Secondo voi il protocollo resiste solo all'attacco indicato o è possibile trovare altri tipi di attacco che lo violano?
A me sembra di aver trovato un man in the middle attack che lo viola ma magari c'è qualcosa di sbagliato. Eccolo:
Lo commento:
(1) I invia ad A la sua identità e una nouce cifrata con la chiave pubblica di A
(2) A prende il messaggio ricevuto. Lo decifra con la sua chiave privata. Prende la nounce ricevuta e la invia a B insieme alla sua identità tutto cifrato con la chiave pubblica di B.
(3) B decifra con la sua chiave privata. Invia ad A la sua identità ed una nouce generata da lui tutto cifrato con la chiave pubblica di A
(4) A decifra con la sua chiave privata ed invia la nouce ricevuta da B ad I
Alla fine di questi 4 passi B crede di parlare con A in modo confidenziale, mentre invece:
1 I è in grado di creare messaggi inviandoli a B facendo credere che provengano da A
2 I è in grado di leggere tutto il traffico scambiato fra A e B
Cosa ne pensate?
Grazie
Mi trovo a provare a risolvere il seguente esercizio:
La prima domanda chiede di indicare quali proprietà garantisce il protocollo. E su questa non ho problemi.
Ecco la risposta:
La seconda domanda chiede di trovare un attacco che viola le proprietà sopra.
Ecco domanda e risposta:
Il mio problema è su questa risposta.
La risposta inizia con "il protocollo non è vulnerabile" dando l'idea che nessun tipo di attacco riesca a violarne le proprietà.
Però nelle righe successive cita solo l'utilizzo di un reflection attack.
Secondo voi il protocollo resiste solo all'attacco indicato o è possibile trovare altri tipi di attacco che lo violano?
A me sembra di aver trovato un man in the middle attack che lo viola ma magari c'è qualcosa di sbagliato. Eccolo:
Lo commento:
(1) I invia ad A la sua identità e una nouce cifrata con la chiave pubblica di A
(2) A prende il messaggio ricevuto. Lo decifra con la sua chiave privata. Prende la nounce ricevuta e la invia a B insieme alla sua identità tutto cifrato con la chiave pubblica di B.
(3) B decifra con la sua chiave privata. Invia ad A la sua identità ed una nouce generata da lui tutto cifrato con la chiave pubblica di A
(4) A decifra con la sua chiave privata ed invia la nouce ricevuta da B ad I
Alla fine di questi 4 passi B crede di parlare con A in modo confidenziale, mentre invece:
1 I è in grado di creare messaggi inviandoli a B facendo credere che provengano da A
2 I è in grado di leggere tutto il traffico scambiato fra A e B
Cosa ne pensate?
Grazie
Risposte
Non entro nel merito dell'esercizio, ma quello che proponi tu non è un attacco man in the middle*. I non opera all'insaputa di A e B, lo fa con l'aiuto di A, A fa da "garante" ad I.
È come se dicessi: A e B si scambiano una chiave e instaurano una connessione sicura, ma A poi comunica la chiave (o direttamente i dati scambiati) a I. Non c'è nessun algoritmo di crittografia che possa impedire una cosa del genere.
È come se dicessi: A e B si scambiano una chiave e instaurano una connessione sicura, ma A poi comunica la chiave (o direttamente i dati scambiati) a I. Non c'è nessun algoritmo di crittografia che possa impedire una cosa del genere.
Grazie!
Mi sembrava che sulle dispense venisse considerato pure quello come un attacco man in the middle ma ora non lo trovo.
Comunque mi era venuta la tua stessa obiezione.
Questo sotto è invece un corretto (tentativo di) attacco man in the middle?
Non va a buon fine perchè nel passaggio (3) I non riesce ad accedere a ciò che B gli manda (la nounce che lui ha generato) e quindi I non riesce a conoscere la chiave.
L'unica cosa che non capisco è: perchè A cifra con la chiave pubblica di I se vuole parlare con B?
Mi sembrava che sulle dispense venisse considerato pure quello come un attacco man in the middle ma ora non lo trovo.
Comunque mi era venuta la tua stessa obiezione.
Questo sotto è invece un corretto (tentativo di) attacco man in the middle?
Non va a buon fine perchè nel passaggio (3) I non riesce ad accedere a ciò che B gli manda (la nounce che lui ha generato) e quindi I non riesce a conoscere la chiave.
L'unica cosa che non capisco è: perchè A cifra con la chiave pubblica di I se vuole parlare con B?
L'unica cosa che non capisco è: perchè A cifra con la chiave pubblica di I se vuole parlare con B?
Forse I è riuscito a far credere ad A che la chiave pubblica di B sia K_i, e lo schema mostra se un attacco è possibile o meno.
Nel punto 3 I potrebbe inviare direttamente il messaggio {B, N_b} ad A, senza decifrarlo. A quel punto A e B conoscerebbero i valori di N_a, N_b quindi potrebbero generare una chiave simmetrica e comunicare con quella. I invece non conosce N_b quindi non può fare nulla.
Però aspetta che qualcun altro confermi quanto ho detto, non sono sicurissimo.
Confermo. E' lo schema man-in-the-middle "classico" ovvero l'intruder si "spaccia" per A nei confronti di B e viceversa.
PS. Perché parlate di chiavi pubbliche?
PS. Perché parlate di chiavi pubbliche?
"claudio86":L'unica cosa che non capisco è: perchè A cifra con la chiave pubblica di I se vuole parlare con B?
Forse I è riuscito a far credere ad A che la chiave pubblica di B sia K_i, e lo schema mostra se un attacco è possibile o meno.
E' quello che ho pensato anch'io ma non è un problema facilmente risolvibile con l'utilizzo di certificati digitali?
"Rggb":
Confermo. E' lo schema man-in-the-middle "classico" ovvero l'intruder si "spaccia" per A nei confronti di B e viceversa.
Scusa la domanda. Ti riferisci al secondo?
"Rggb":
PS. Perché parlate di chiavi pubbliche?
Forse non ho capito la domanda.
Parlo di chiavi pubbliche perchè il protocollo dell'esercizio utilizza chiavi pubbliche e non private.
"hee136":
Ti riferisci al secondo?
Si, esatto.
"hee136":
Parlo di chiavi pubbliche perchè il protocollo dell'esercizio utilizza chiavi pubbliche e non private.
Non l'avevo capito: nelle immagini che hai postato non ve n'è traccia. :\
"Rggb":
[quote="hee136"]Parlo di chiavi pubbliche perchè il protocollo dell'esercizio utilizza chiavi pubbliche e non private.
Non l'avevo capito: nelle immagini che hai postato non ve n'è traccia. :\[/quote]
Scusa, hai ragione.
Ecco la notazione che usiamo:
$K_a$, $K_b$ e $K_i$ sono le chiavi pubbliche di A, B e I.
Mentre $ (K_a)^(-1 ) $, $ (K_b)^(-1) $ e $ (K_i)^(-1) $ sono le rispettive chiavi private.
"Rggb":
Confermo. E' lo schema man-in-the-middle "classico" ovvero l'intruder si "spaccia" per A nei confronti di B e viceversa.
L'intruder si "spaccia" per B nei confronti di A nel senso che, quando A chiede a B la sua chiave pubblica, l'intruder manda ad la chiave pubblica sua e non quella di B?
Scrivo un pò meglio quello che intendevo sopra:
A -> I : mi serve la chiave pubblica di B $K_b$
I -> A: eccoti la chiave pubblica di B $K_i$
Ora A cifrerà i messaggi per B con $K_i$ non sapendo che in realtà questa è la chiave pubblica di I e non di B
Eccomi qui con un altro esercizio che non ho capito.
$K_a$ e $K_b$ sono le chiavi pubbliche di A e di B.
La soluzione mostrata in basso nella seconda immagine dice che il protocollo mostrato nella seconda immagine non è violabile con l'attacco man in the middle.
Però la traccia che scrivo qui sotto non è un man in the middle? Cosa c'è di sbagliato?
(1) A -> I : { A , B , $N_a$ } cifrato con $K_i$
(1) I -> B : { A , B , $N_a$ } cifrato con $K_b$
(2) B -> I : { $N_a$ , $N_b$ , B } cifrato con $K_a$
(2) I -> A : { $N_a$ , $N_b$ , B } cifrato con $K_a$
Ciò che non capisco è perchè la presenza dell'identità B nel passo (2) impedisca il mitm perchè:
1 A vuole parlare con B
2 A è convinta che $K_i$ sia la chiave pubblica di B.
Grazie nuovamente!
$K_a$ e $K_b$ sono le chiavi pubbliche di A e di B.
La soluzione mostrata in basso nella seconda immagine dice che il protocollo mostrato nella seconda immagine non è violabile con l'attacco man in the middle.
Però la traccia che scrivo qui sotto non è un man in the middle? Cosa c'è di sbagliato?
(1) A -> I : { A , B , $N_a$ } cifrato con $K_i$
(1) I -> B : { A , B , $N_a$ } cifrato con $K_b$
(2) B -> I : { $N_a$ , $N_b$ , B } cifrato con $K_a$
(2) I -> A : { $N_a$ , $N_b$ , B } cifrato con $K_a$
Ciò che non capisco è perchè la presenza dell'identità B nel passo (2) impedisca il mitm perchè:
1 A vuole parlare con B
2 A è convinta che $K_i$ sia la chiave pubblica di B.
Grazie nuovamente!
Tiro sù il 3d perchè l'esame si avvicina e sono in ansia per queste cose che non ho capito. Grazie!
Se le chiavi sono pubbliche un attacco del genere non si può basare sul fatto che un intruder I riesca a "convincere" qualcuno che la sua chiave pubblica è quella di un altro. Quindi
questo non può succedere. Oppure, può succedere se considero che lo schema non sia a chiave pubblica, o se le chiavi pubbliche non sono depositate presso un'autorità affidabile.
Quel che succede in questi casi, con l'attacco man-in-the-middle, è che i messaggi fra A e B vengono intercettati dall'intruder.
"hee136":
(1) A -> I : { A , B , $N_a$ } cifrato con $K_i$
questo non può succedere. Oppure, può succedere se considero che lo schema non sia a chiave pubblica, o se le chiavi pubbliche non sono depositate presso un'autorità affidabile.
Quel che succede in questi casi, con l'attacco man-in-the-middle, è che i messaggi fra A e B vengono intercettati dall'intruder.
"Rggb":
Se le chiavi sono pubbliche un attacco del genere non si può basare sul fatto che un intruder I riesca a "convincere" qualcuno che la sua chiave pubblica è quella di un altro. Quindi
[quote="hee136"](1) A -> I : { A , B , $N_a$ } cifrato con $K_i$
questo non può succedere. Oppure, può succedere se considero che lo schema non sia a chiave pubblica, o se le chiavi pubbliche non sono depositate presso un'autorità affidabile.
Quel che succede in questi casi, con l'attacco man-in-the-middle, è che i messaggi fra A e B vengono intercettati dall'intruder.[/quote]
Grazie della risposta
Anche se avrei potuto essere meno insistente siccome ho scoperto dopo che la risposta alla mia domanda era scritta su wikipedia.
Unfortunately, this protocol is vulnerable to a man-in-the-middle attack. If an impostor I can persuade A to initiate a session with him, he can relay the messages to B and convince B that he is communicating with A.
link
Nonostante sia spesso indicato come MITM(*), quell'attacco è un po' differente. Vabbé, mi rendo conto che l'importante sia capire il funzionamento di queste cose - ed effettivamente non c'è nemmeno una condivisa formale definizione di MITM attack.
(*) Io sono un po' pignolo
(*) Io sono un po' pignolo
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo