sicurezza ii prof. dario catalano security handshake pitfalls

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”