Upload
genoveffa-grandi
View
238
Download
3
Embed Size (px)
Citation preview
Sicurezza IIProf. Dario Catalano
Security Handshake Pitfalls
Introduzione La sicurezza della comunicazione,
include necessariamente una prima “presentazione” autenticata dei partecipanti. Alice e Bob devono conoscere una
qualche informazione (l’uno sull’altra) a priori.
Oggi parleremo di protocolli di presentazione (handshake)
Introduzione Per quanto molti di essi sembrino
semplici, minime varianti possono essere letali.
Molti protocolli utilizzati in pratica hanno problemi.
Non ci cureremo di presentare il protocollo migliore. Protocolli differenti possono essere
difficilmente confrontabili. Situazioni differenti richiedono soluzioni
diverse.
Obiettivi Il nostro obiettivo e’ di capire
determinati problemi e cercare di evitarli nel progettare applicazioni.
In particolare, bisogna imparare ad evitare di apportare modifiche avventate (anche minime).
In pratica molti protocolli sono sviluppati a partire da un’idea (sovente errata) che poi viene “ripulita”.
Login
Alice manda la sua login e pwd (in chiaro) a Bob.
Bob verifica i dati ricevuti. Se corretti, allora Alice e’ autenticata.
Molti protocolli sono stati ideati per applicazioni in cui spiare (eavesdropping) non e’ considerato un reale pericolo.
Un modo ovvio per migliorare tale protocollo e’ utilizzare crittografia.
Primo protocollo (Alice e Bob condividono KAlice-Bob)
Alice BobSono Alice
R (valore casuale)
F(KAlice-Bob,R)
F e’ una qualche funzione crittografica.
Osservazioni Il protocollo non garantisce mutua
autenticita’ Bob autentica Alice, ma Alice non
autentica Bob. Alice potrebbe parlare con Oscar
senza rendersene conto. Se e’ una pwd (o e’ derivata da
una pwd) e’ possibile fare un dictionary attack.
Prima variante (minima)
Alice BobSono Alice
EncKAlice-Bob(R)
R
Osservazioni
Il protocollo richiede crittografia “invertibile”
Se K deriva da una pwd il protocollo è soggetto a dictionary attack.
Seconda variante
Alice BobSono Alice, EncKAlice-Bob
(T)
T e’ un timestamp (marca temporale)
Pro… E’ facilmente adattabile a protocolli
pensati per inviare pwd in chiaro. Il protocollo e’ estremamente efficiente.
Risparmiamo due flussi Il server (Bob) non deve generare valori
casuali Puo’ facilmente aggiunto a protocolli di
tipo domanda/risposta.
… e Contro Un avversario in ascolto puo’ utilizzare
EncKAlice-Bob(T) per impersonare Alice piu’
volte (nello stesso intervallo di tempo)Contromisura: Bob ricorda tutti i timestamps
inviati da Alice. Se Alice usa lo stesso segreto per piu’
server, un avversario “rapido” puo’ impersonare Alice in un server guardando un’autentica fatta per un altro server.Contromisura: concatenare il nome del server al
timestamp
Contro (cont.) Se A riuscisse a modificare il clock di
Bob, potrebbe riutilizzare crittotesti visti in passato per quello che Bob crede essere il futuro. Il clock non e’ necessariamente una risorsa
considerata a rischio. Se i protocolli di sicurezza non sono del
tutto compresi, puo’ non risultare ovvio capire che proteggere il clock e’ importante.
Schemi basati su tecnologia a chiave pubblica.
Se A entra nel server di Bob puo’ estrarre tutte le chiavi degli utenti che interagiscono con Bob.
Questo problema puo’ essere evitato utilizzando tecnologia a chiave pubblica.
Autentica con Public Key (I)
Alice BobSono Alice
R
SignAlice(R)
Autentica con Public Key (II)
Alice BobSono Alice
EncAlice(R)
R
Potenziali problemi
Potremmo “forzare” Alice a firmare un documento apparentemente innocuo (da utilizzare in seguito per autenticarci) Es: A impersona l’indirizzo di Bob,
attende il login di Alice in modo da fornirle un R da firmare. (Difficile da realizzare)
Es: Alice usa la stessa chiave di firma per operazioni differenti.
Soluzione Mai utilizzare la stessa chiave per
operazioni diverse (e non coordinate) Coordinazione: R dovrebbe avere una
struttura precisa e diversa per ogni (diversa) applicazione.
Parte del compito di PKCS standard e’ di stabilire formati specifici che permettano di evitare problemi quando la stessa chiave RSA e’ usata per scopi diversi.
Conseguenze inquietanti
Potremmo avere schemi singolarmente sicuri che combinati insieme, non sono piu’ sicuri.
L’uso di nuovi protocolli (che utilizzano la stessa chiave) puo’ compromettere la sicurezza dei precedenti.
Mutua Autentica Alice Bob
Sono Alice
R1
F(KAlice-Bob, R1)
R2
F(KAlice-Bob, R2)
Variante (piu’ efficiente)
Alice BobSono Alice, R2
R1 , F(KAlice-Bob, R2)
F(KAlice-Bob, R1)
Problema
Purtroppo questa variante ha un serio problema di sicurezza.
Il che dimostra (ancora una volta!) che piccole modifiche possono avere conseguenze devastanti.
L’attacco e’ noto come Reflection Attack
Reflection Attack
Oscar Bob Sono Alice, R2.
R1 , F(KAlice-Bob, R2)
Oscar non puo’ proseguire in quanto non puo’ calcolare F(KAlice-Bob, R1).
Allora si limita ad fermare (senza abortire) il protocollo e a ripeterlo, (chiedendo R1)
Reflection Attack (cont.)
Oscar Bob Sono Alice, R1.
R3 , F(KAlice-Bob, R1)
Anche stavolta Oscar non puo’ proseguire (non puo’ calcolare F(KAlice-Bob, R3).
Pero’ ha gia’ tutto il necessario per completare la prima autentica.
Realistico?
L’attacco e’ abbastanza realistico. E’ spesso possibile aprire sessioni
parallele. Spesso diversi utenti usano la stessa
chiave per server differenti. Per riuscire a risolvere il problema
bisogna capire da dove esso sorga.
Le origini del male
Principio importante: Client e Server non dovrebbero MAI fare esattamente la stessa cosa.
Usare chiavi diverse. Alice e Bob potrebbero usare chiavi
leggermente diverse (es K e K+1). Usare Challenges di formato
differente.
Le origini del male (cont) Si noti che il primo protocollo non
“soffre” di reflection attack. Questo perche’ chi si autentica (Alice) e’
il primo a doversi “presentare” Principio utile: colui che ha piu’ interesse ad
entrare e’ (in generale) piu’ probabilmente il cattivo.
Idealmente non dovremmo provare la nostra identita’ fino a quando colui col quale parliamo non fa altrettanto.
Pwd guessing Altro problema della variante
descritta (se la chiave e’ ottenuta da pwd)
Oscar puo’ effettuare un off-line dictionary attack, senza nemmeno spiare la conversazione. Basta mandare un msg a Bob,
contenente un num da cifrare, ed attendere la risposta.
Pwd guess
Oscar BobSono Alice, R2
R1 , F(KAlice-Bob, R2)
A questo punto, Oscar blocca (abortisce) il protocollo e prova tutte le possibili pwd.
Osservazioni Il problema non sorge nel protocollo
iniziale perche’, in tal caso, Oscar dovrebbe prima “presentarsi”.
Ovviamente nel caso in cui la chiave e’ ottenuta da pwd il problema del dictionary attack rimane, in presenza di avversari che possono origliare.
In pratica pero’ origliare e’ piu’ complicato che mandare messaggi a caso e leggere le corrispondenti risposte.
Mutual Auth con chiavi pubbliche
Alice BobSono Alice, EncBob(R2)
R2 , EncAlice(R1)
R1
Mutual Auth con chiavi pubbliche
Bisogna assumere che Alice e Bob conoscano le rispettive chiavi pubbliche.
Inoltre bisogna essere sicuri che la chiave sia autentica. Problema non del tutto banale. Vedremo meglio questi aspetti
studiando PKI.
Mutual Auth con chiavi pubbliche
Come fa la workstation di Alice ad ottenere la chiave privata (di Alice), quando la sola cosa che ottiene e’ la pwd? Il server al quale Alice si autentica in generale
puo’ non contenere SKAlice E’ facile ottenere una chiave simmetrica a
partire da una pwd, ma nel caso asimmetrico le cose sono piu’ complicate.
Spesso il metodo utilizzato in pratica e’ di lasciare la workstation accedere ad un directory service contenente la chiave di Alice cifrata con la pwd.
Che tipo di cifrari utilizzare?
Problema molto piu’ sottile. In generale il cifrario utilizzato dal
server (Bob) dovrebbe essere sicuro contro attacchi attivi.
Per il cifrario usato da Alice, talvolta puo’ bastare un cifrario sicuro contro attacchi passivi.
Mutual Auth con due msg
Alice BobSono Alice, F(KAlice-Bob,timestamp)
F(KAlice-Bob,timestamp+1)
Timestamps Ridurre il protocollo a due messaggi, lo
rende (in principio) “aggiungibile” a qualsiasi protocollo di tipo domanda/risposta
Bob invia un timestamp diverso rispetto ad Alice (ovviamente!)
Qualsiasi altra modifica (nota) del timestamp otterrebbe lo stesso effetto.
Timestamp+1 viene dal protocollo Needham-Schroeder
Questa soluzione puo’ essere rischiosa.
Potenziale attacco Oscar potrebbe utilizzare
F(KAlice-Bob,timestamp+1) per impersonare Alice in un secondo momento.
Un metodo migliore sarebbe quello di utilizzare una risposta che non puo’ essere “riciclata” come domanda.
Protezione dei dati Per proteggere (privacy e/o integrita’) i dati
dopo l’autentica dobbiamo usare crittografia. Puo’ essere necessario scambiare chiavi (di
sessione) crittografiche. Obiettivo: Dopo l’handshake iniziale, Alice
e Bob vogliano stabilire una chiave di sessione
Tre modelli di base per scambiare chiavi I due utenti hanno gia’ una chiave condivisa Chiavi pubbliche One way PK (l’autentica non e’ per entrambi)
Shared Secret
Alice e Bob condividono KAlice-Bob. Supponiamo che l’autentica sia
stata fatta utilizzando un protocollo simile a quelli gia’ visti. Alice Bob
Sono Alice R
C=F(KAlice-Bob,R)
Come derivare la chiave di sessione?
Idea: modificare C in modo da ottenere qualcosa di ignoto ad A.
Potremmo utilizzare, ad esempio, C’=F(KAlice-Bob+1,R)
Oppure C’’=F(KAlice-Bob,R+1) Quest’ultima, non e’ una buona
idea.
Usare F(KAlice-Bob,R+1)
Supponiamo R sia la challenge utilizzata nell’autentica di Alice.
Oscar memorizza tutte le conversazioni fatte da Alice e Bob e cifrate con la chiave F(KAlice-Bob,R+1).
In un secondo momento Oscar si spaccia per Bob (con Alice) ed utilizza R+1 come challenge.
Una volta ottenuto F(KAlice-Bob,R+1), Oscar potra’ decifrare la conversazione di Alice e Bob.
Cosa rende buona una chiave di sessione?
Domanda difficile…Alcune caratteristiche che una
buona chiave di sessione dovrebbe possedere:
Differente per ogni sessione Non (facilmente) indovinabile Non cifrata con la chiave a lungo
termine.
Chiavi Pubbliche (con MA)
Alice e Bob conoscono le rispettive chiavi pubbliche.
Discuteremo varie possibilita’ per scambiare chiavi di sessione in tale contesto.
Prima soluzione
Alice Bob EncBob(S), Msg
Msg e’ uno dei messaggi scambiati durante l’autentica.
Questo protocollo ha un problema Oscar potrebbe scegliere un proprio
S’ e sostituirlo a quello cifrato da Alice
Seconda soluzione
Alice Bob C=EncBob(S), SigAlice(C)
Oscar non puo’ fare l’attacco di prima in quanto non puo’ falsificare firme.
Piccolo problema di sicurezza Se Oscar entra nel server di Bob, puo’
decifrare tutte le conversazioni (precedentemente origliate)
Terza soluzione
Alice Bob EncBob(S1)
EncAlice(S2)
La chiave condivisa e’ S1©S2.
Terza Soluzione (cont) Qua non abbiamo bisogno di firmare
Per quanto Oscar possa inserire valori del tipo EncBob(S1) e EncAlice(S2) a piacimento, non potrebbe comunque decifrare.
Oscar puo’ creare confusione (creando false chiavi), ma non puo’ decifrare la vera chiave.
Rimane il problema del Man in the middle
Quarta Soluzione
Alice Bobgx, SignAlice(gx)
gy, SignBob(gy)
La chiave comune e’ gxy.
Una sola parte ha PK Normalmente (i.e. SSL) il server, Bob,
ha una coppia (PK,SK) e il cliente, Alice, non ha nulla.
I protocolli sono volti ad assicurare ad Alice che sta parlando con Bob.
Inizialmente Bob accetta Alice. Quindi una chiave crittografica e’ stabilita e Alice puo’ (eventualmente) essere autenticata.
Stabilire una chiave di sessione – I metodo
Alice BobR random EncBob(R)
R e’ la chiave di sessione. Problema: Se Oscar registra le
conversazioni e quindi entra nel server di Bob, puo’ decifrare tutte le conversazioni conservate.
Stabilire una chiave di sessione – II metodo Alice e Bob fanno uno scambio DH
(ma solo Bob firma) Leggermente piu’ sicuro del
precedente Assumendo che Bob cancella tutte le
chiavi di sessione gia’ utilizzate, Oscar non puo’ decifrare eventuali conversazioni precedentemente osservate.
Privacy ed Integrita’ (allo stesso tempo) Nel caso simmetrico, l’uso di MAC
consente di realizzare autenticita’. MAC possono essere realizzati a
partire da cifrari a blocchi (es. CBC MAC), funzioni hash (HMAC), etc
Non conosciamo metodi standard per ottenere privacy ed autenticita’ a partire da una sola primitiva (con una sola chiave).
Privacy ed Integrita’ (cont) Una volta stabilite (due) chiavi per privacy
e integrita’ bisogna vedere come utilizzarle correttamente.
Problema: I messaggi scambiati nell’ambito di una comunicazione devono poter essere interpretati correttamente. Per ogni messaggio deve essere verificata
l’autenticita’ Anche messaggi autentici possono essere
male interpretati se letti nell’ordine sbagliato.
Oscar potrebbe intercettare un msg e rispedirlo in seguito.
Privacy ed Integrita’ (cont)
Soluzioni: Indici sequenziali (Kerberos)
I numeri di seq. devono essere scelti in intervalli sufficientemente grandi.
Riutilizzare lo stesso numero puo’ essere molto pericoloso
Il codice di integrita’ puo’ contenere dati su tutti i messaggi gia’ scambiati (Novell)
Reflection Attack
Adv registra msg da Alice a Bob e lo ri-invia nel senso contrario (da Bob ad Alice) Se il numero sequenziale segue la
stessa logica per entrambi msg puo’ essere male interpretato.
Soluzione semplice: usare notazioni diverse o un direction bit.
Key Rollover Cambio di chiave durante una
conversazione. Pratica molto consigliabile, se ben realizzata.
Possibile soluzione: Alice sceglie una chiave random e la cifra con la chiave vecchia.
Uno scambio di chiavi Diffie Hellman e’ pero’ piu’ indicato.
Mantenere numeri sequenziali e fare key rollover puo’ diventare difficilissimo se il protocollo di comunicazione non “collabora”