Sicurezza II Prof. 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 (luno sullaltra) 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 unidea (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 K Alice-Bob ) Alice Bob Sono Alice R (valore casuale) F(K Alice-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 Bob Sono Alice Enc K Alice-Bob (R) R

Osservazioni Il protocollo richiede crittografia invertibile Se K deriva da una pwd il protocollo è soggetto a dictionary attack.

Seconda variante Alice Bob Sono Alice, Enc K Alice-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 Enc K Alice-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 unautentica 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 Bob Sono Alice R Sign Alice (R)

Autentica con Public Key (II) Alice Bob Sono Alice Enc Alice (R) R

Potenziali problemi Potremmo forzare Alice a firmare un documento apparentemente innocuo (da utilizzare in seguito per autenticarci) Es: A impersona lindirizzo 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. Luso di nuovi protocolli (che utilizzano la stessa chiave) puo compromettere la sicurezza dei precedenti.

Mutua Autentica Alice Bob Sono Alice R 1 F(K Alice-Bob, R 1 ) R 2 F(K Alice-Bob, R 2 )

Variante (piu efficiente) Alice Bob Sono Alice, R 2 R 1, F(K Alice-Bob, R 2 ) F(K Alice-Bob, R 1 )

Problema Purtroppo questa variante ha un serio problema di sicurezza. Il che dimostra (ancora una volta!) che piccole modifiche possono avere conseguenze devastanti. Lattacco e noto come Reflection Attack

Reflection Attack Oscar Bob Sono Alice, R 2. R 1, F(K Alice-Bob, R 2 ) Oscar non puo proseguire in quanto non puo calcolare F(K Alice-Bob, R 1 ). Allora si limita ad fermare (senza abortire) il protocollo e a ripeterlo, (chiedendo R 1 )

Reflection Attack (cont.) Oscar Bob Sono Alice, R 1. R 3, F(K Alice-Bob, R 1 ) Anche stavolta Oscar non puo proseguire (non puo calcolare F(K Alice-Bob, R 3 ). Pero ha gia tutto il necessario per completare la prima autentica.

Realistico? Lattacco 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 Bob Sono Alice, R 2 R 1, F(K Alice-Bob, R 2 ) 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 Bob Sono Alice, Enc Bob (R 2 ) R 2, Enc Alice (R 1 ) R 1

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 SK Alice 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 Bob Sono Alice, F(K Alice-Bob,timestamp) F(K Alice-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(K Alice-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 lautentica dobbiamo usare crittografia. Puo essere necessario scambiare chiavi (di sessione) crittografiche. Obiettivo: Dopo lhandshake 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 (lautentica non e per entrambi)

Shared Secret Alice e Bob condividono K Alice-Bob. Supponiamo che lautentica sia stata fatta utilizzando un protocollo simile a quelli gia visti. Alice Bob Sono Alice R C=F(K Alice-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(K Alice-Bob +1,R) Oppure C=F(K Alice-Bob,R+1) Questultima, non e una buona idea.

Usare F(K Alice-Bob,R+1) Supponiamo R sia la challenge utilizzata nellautentica di Alice. Oscar memorizza tutte le conversazioni fatte da Alice e Bob e cifrate con la chiave F(K Alice-Bob,R+1). In un secondo momento Oscar si spaccia per Bob (con Alice) ed utilizza R+1 come challenge. Una volta ottenuto F(K Alice-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 Enc Bob (S), Msg Msg e uno dei messaggi scambiati durante lautentica. Questo protocollo ha un problema Oscar potrebbe scegliere un proprio S e sostituirlo a quello cifrato da Alice

Seconda soluzione Alice Bob C=Enc Bob (S), Sig Alice (C) Oscar non puo fare lattacco 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 Enc Bob (S 1 ) Enc Alice (S 2 ) La chiave condivisa e S 1 © S 2.

Terza Soluzione (cont) Qua non abbiamo bisogno di firmare Per quanto Oscar possa inserire valori del tipo Enc Bob (S 1 ) e Enc Alice (S 2 ) 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 Bob g x, Sign Alice (g x ) g y, Sign Bob (g y ) La chiave comune e g xy.

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 Bob R random Enc Bob (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, luso 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 nellambito di una comunicazione devono poter essere interpretati correttamente. Per ogni messaggio deve essere verificata lautenticita Anche messaggi autentici possono essere male interpretati se letti nellordine 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