Sicurezza II Prof. Dario Catalano Security Handshake Pitfalls.

Slides:



Advertisements
Presentazioni simili
Misure ed Errori Prof Valerio CURCIO.
Advertisements

Elementi di Crittografia MAC e FUNZIONI HASH
Il FURTO D’IDENTITÀ Dijana Kryezi IV A SIA.
Protocolli HB+ e HB# Lezione tenuta dal Presentazione realizzata da
Microsoft Visual Basic MVP
SSL/TLS.
La sicurezza nelle Griglie
Sicurezza II Prof. Dario Catalano Errori di Implementazione.
Sicurezza II Prof. Dario Catalano
Sicurezza II Prof. Dario Catalano Introduzione. Il problema fondamentale di questo corso Alice e Bob vogliono comunicare utilizzando un canale non del.
Sicurezza II Prof. Dario Catalano Autentica Mediata.
Sicurezza II Prof. Dario Catalano Sistemi di Autentica.
Sicurezza II Prof. Dario Catalano Autentica di Umani.
Sicurezza II Prof. Dario Catalano Strong Password Protocols.
Lez. 13a1 Universita' di Ferrara Facolta' di Scienze Matematiche, Fisiche e Naturali Laurea Specialistica in Informatica Algoritmi Avanzati Funzioni Hash.
Autenticazione dei messaggi e funzioni hash
RSA Monica Bianchini Dipartimento di Ingegneria dellInformazione Università di Siena.
Per crittografia si intende la protezione
Introduzione alla firma elettronica
Politecnico di Milano Algoritmi e Architetture per la Protezione dellInformazione Multichannel Adaptive Information Systems Paolo Maistri Dipartimento.
Camil Demetrescu, Irene Finocchi, Giuseppe F. ItalianoAlgoritmi e strutture dati Copyright © The McGraw - Hill Companies, srl Capitolo 4 Ordinamento:
Testo consigliato Crittografia, P. Ferragina e F. Luccio, Ed. Bollati Boringhieri, € 16.
Secure Shell Giulia Carboni
Alberi di Ricorrenza Gli alberi di ricorrenza rappresentano un modo conveniente per visualizzare i passi di sostitu- zione necessari per risolvere una.
Ricerca della Legge di Controllo
Sicurezza su Reti /2007 Commessa 1 : Protocollo di pagamento online utilizzato nella commessa.
SSL (Secure Socket Layer)
Il codice in materia di protezione dei dati personali è un decreto legislativo (atto avente forza di legge) della Repubblica Italiana emanato il 30 giugno.
Ecdl modulo 7.
Assicurazioni vita e mercato del risparmio gestito
Un servizio di autenticazione per sistemi di rete aperti
Protocollo di autenticazione KERBEROS
Modulo 7 – reti informatiche u.d. 2 (syllabus – )
LA CRITTOGRAFIA QUANTISTICA
Metodo della moltiplicazione
CORSO DI CRITTOGRAFIA Quinto incontro PROGETTO LAUREE SCIENTIFICHE
CRITTOGRAFIA E FIRMA DIGITALE
Il processo per generare una Firma Digitale
ESTENSIONI SEMPLICI e TEOREMA DELL’ELEMENTO PRIMITIVO
Capitolo 8 La sicurezza nelle reti
RSA e questioni relative
Nemesi Creazione e pubblicazione di una rivista online tramite l’utilizzo di Java Message Service.
Analisi e sperimentazione di una Certification Authority
La sicurezza dei sistemi informatici. Il sistema deve soddisfare i seguenti requisiti di sicurezza (CIANA)  Confidenzialità (Riservatezza)  Integrità.
Implementazione di dizionari Problema del dizionario dinamico Scegliere una struttura dati in cui memorizzare dei record con un campo key e alcuni altri.
Rappresentazione dell’informazione nel calcolatore.
Misure ed Errori.
UNIVERSITÀ DEGLI STUDI DI PAVIA Anno accademico 2009/2010 Sicurezza e frodi informatiche in Internet: la Firma Digitale come garanzia di autenticità e.
La Crittografia nell’ambito del protocollo HTTP Classe: V istituto professionale (gestione aziendale) Obiettivo 1: Generazione di competenze e preparazione.
Sicurezza informatica
PKI e loro implementazione Corso di Sisitemi Informativi Teledidattico A.A. 2006/07
Infrastruttura per la gestione distribuita di un sistema di prenotazione Progetto di: Fabio Fabbri Matricola
Progetto di un Gestore di Nomi Corso di Reti di Calcolatori L-S prof. Antonio Corradi A.A 2003/2004 Autore: Molesini Ambra.
Sicurezza delle comunicazioni1 Introduzione Consistente sviluppo delle applicazioni telematiche dovuto a: –Evoluzione tecnologica delle trasmissioni –potenze.
Elgamal Corso di Sicurezza – A.A. 2006/07 Angeli Fabio29/05/2007.
Reti di calcolatori e sicurezza “Configurare il web-server Apache” a cura di Luca Sozio.
Progetto e Realizzazione di un servizio di Chat Progetto di: Nicoli Leonardo Corso di: Reti di Calcolatori L-S.
Università “G. d’Annunzio” Corso di Laurea Specialistica in Economia Informatica SECURE PROGRAMMING Prof. Stefano Bistarelli SEMINARIO “Authentication.
DES e RSA a confronto: crittografia al servizio della sicurezza.
Comunicazioni. 5.1 POSTA ELETTRONICA 5.1 POSTA ELETTRONICA.
Agenda – Parte II La creazione del documento informatico e la firma digitale La classificazione del documento e il protocollo informatico La trasmissione.
Informatica Lezione 10 Psicologia dello sviluppo e dell'educazione (laurea magistrale) Anno accademico:
Corso integrato di Matematica, Informatica e Statistica Informatica di base Linea 1 Daniela Besozzi Dipartimento di Informatica e Comunicazione Università.
IT SECURITY Comunicazioni. Posta elettronica I messaggi ( ) commerciali viaggiano in rete “criptati”, cioè scritti con una “chiave pubblica” nota.
Procedure operative di sicurezza di un sistema informatizzato in un dipartimento servizi.
La firma digitale. Che cosa é la firma digitale? La firma digitale è una informazione aggiunta ad un documento informatico al fine di garantirne integrità.
Analisi matematica Introduzione ai limiti
Sistemi di equazioni lineari. Sistemi di primo grado di due equazioni a due incognite Risolvere un sistema significa trovare la coppia di valori x e y.
Cenni di Crittografia Luigi Vetrano TechnoLabs S.p.A. L’Aquila, Aprile 2011.
Un sistema di sicurezza dei dati.  La crittografia, il cui termine indica "nascosto", è la branca della crittologia che tratta delle "scritture nascoste",
Transcript della presentazione:

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