Gestione delle chiavi

1. Gestione delle chiavi • Distribuzione delle chiavi pubbliche • Uso dei protocolli a chiave pubblica per distribuire chiavi segrete

2. Distribuzione delle chiavi pubbliche • Annuncio pubblico • Elenco pubblico • Autorità di distribuzione • Certificati

3. Annuncio pubblico • L’utente rende di pubblico dominio la propria chiave pubblica • Pubblicazione chiavi: • Tutti possono pubblicare la propria chiave • Accesso: • Tutti possono accedere alle chiavi degli altri

4. K pub A Utente A K pub A Ad esempio: la chiave pubblica viene messa in allegato ai messaggi di posta elettronica K pub A K pub B Utente B K pub B K pub B

5. Annuncio pubblico • Vantaggi • Semplice, veloce, non necessita di intermediari • Svantaggi • Nessuna garanzia: l’annuncio può essere facilmente alterato. L’intruso può pubblicare la propria chiave pubblica a nome di un altro utente !

6. Elenco pubblico (directory) • Directory mantenuta da un’entità fidata (authority) • Pubblicazione chiavi: • Ogni partecipante registra la propria chiave presso l’authority (di persona o in modo sicuro) • Può aggiornarla nello stesso modo in qualsiasi momento

7. Elenco chiavi pubbliche K pub A K pub B Utente A Utente B

8. Elenco pubblico • Accesso: • Pubblicazione periodica della directory (ad esempio su un periodico ad ampia diffusione) • Accesso diretto alla directory tramite comunicazione elettronica (occorre una comunicazione autenticata e sicura)

9. Elenco pubblico • Vantaggi • Garantisce l’identità dei partecipanti che devono autenticarsi con l’authorithy per poter pubblicare una chiave. • Svantaggi • Necessita di un’entità fidata super-partes: authority • Necessita di protocolli di comunicazione sicuri per la pubblicazione e l’accesso alle chiavi • La Directory può essere violata

10. Autorità di distribuzione • Directory mantenuta da una Authority che ne ha l’accesso esclusivo. • Controllo più rigido sulla distribuzione delle chiavi rispetto alla tecnica dell’elenco pubblico. • Pubblicazione chiavi: • Le chiavi vengono registrate presso l’Authority in maniera sicura (es: di persona)

11. KAut(KpubA,req,t2) 5 2 req,t2 KAut(KpubB,req,t1) req,t1 KPubB(IDA,N1) 1 4 3 6 KPubA(N1,N2) 7 KPubB(N2) Autorità di distribuzione A B

12. Autorità di distribuzione • Vantaggi • Garantisce l’identità dei partecipanti e l’attualità delle chiavi • Svantaggi • Necessita di un’entità fidata super-partes che va interpellata per ogni nuovo partecipante • La Directory può essere violata

13. Certificati • L’autenticità delle chiavi è certificata da una Autorità • Pubblicazione chiavi: • L’interessato riceve la certificazione della propria chiave pubblica tramite una comunicazione autenticata con l’Authority

14. KpubB CA=KAut(t2,IDB, KpubB) CA=KAut(t1,IDA, KpubA) KPubA CA 1 2 CB Autorità di certificazione A B

15. Certificati • Vantaggi • Garantisce l’identità dei partecipanti e l’attualità delle chiavi (mitiga il problema del furto della chiave privata) • Elimina il collo di bottiglia determinato dall’autorità di distribuzione. • Svantaggi • Necessita di un’entità fidata super-partes che possa certificare in maniera sicura

16. Distribuzione delle chiavi segrete • Crittografia a chiave pubblica relativamente lenta • Una volta distribuite le chiavi pubbliche le uso per distribuire le chiavi segrete

17. Un primo protocollo • A genera (KpubA, KprivA) • A  B: KpubA ,IDA • B genera Ks • B  A: KpubA(Ks) • Si scartano (KpubA, KprivA)

18. Un primo protocollo • Garantisce riservatezza ma non autenticazione • Es.: Man in the middle attack • A  E: KpubA,IDA • E B: KpubE ,IDA • B  E: KpubE(Ks) • E A: KpubA(Ks)

19. Un secondo protocollo:chiavi pubbliche già distribuite. • Le chiavi pubbliche sono già state distribuite • Per autenticazione: • A  B: KpubB(IDA,N1) • B  A: KpubA(N1,N2) • A  B: KpubB(N2)

20. Un secondo protocollo:chiavi pubbliche già distribuite. • A genera Ks e la spedisce a B: A  B: KpubB(KprivA(Ks)) • Vantaggi • Garantisce riservatezza ed autenticazione • Svantaggi • Computazionalmente pesante

21. Uno schema ibrido • C’è un Key Distribution Center che distribuisce le chiavi di sessione usando una Ks principale • La chiave principale viene aggiornata usando un sistema a chiave pubblica • Usato da alcuni mainframe IBM

22. Uno schema ibrido • Vantaggi • Garantisce riservatezza ed autenticazione • Mantiene buone prestazioni anche con forte ricambio delle chiavi per molti utenti • Svantaggi • Richiede la presenza di un KDC sicuro

23. Lunghezza delle chiavi • Pesantezza dei protocolli dipende dalla lunghezza della chiave • Chiave serve lunga per contrastare brute force attack • Attenzione a non spedire con Kpub messaggi troppo corti!

24. SSL Secure Socket Layer

25. SSL: applicazioni telematiche • E-commerce • Trading on-line • Internet banking • ......

26. SSL • Protocollo proposto dalla Netscape Communications Corporation • Garantisce confidenzialità e affidabilità delle comunicazioni su Internet • Protegge da intrusioni, modifiche o falsificazioni.

27. SSL • Confidenzialità + Autenticazione. • Sistema ibrido. • Ibrido: Cifrari Simmetici + Cifrari Asimmetrici + Cerificati + MAC

28. HTTPS SSL SSL Utente U: Client Sistema S: Server HTTP HTTP TCP/IP TCP/IP

29. SSL Handshake crea un canale sicuro, affidabile e autenticato tra U e S entro il quale ... SSL SSL Handshake SSL Record ... SSL record fa viaggiare i messaggi incapsulandoli in blocchi cifrati e autenticati.

30. SSL Handshake e SSL Record • Handshake: definisce il canale ovvero una suite crittografica che contiene i meccanismi di cifratura e autenticazione e le relative chiavi. • Record implementa il canale utilizzando la suite per cifrare e autenticare i blocchi prima di darli in pasto a TCP.

31. Client U Server S - Client hello - Server hello- Cert. del Server- Rich. Cert. Client- Server hello done - Pre-master secret- Cert. del Client- Finished Handshake - Finished - Scambio sicuro dati - Scambio sicuro dati Record

32. Client hello • U manda a S un msg richiedendo una connessione SSL. • U specifica le “prestazioni” di sicurezza desiderate. • Versione del protocollo SSL supportato. • Lista di algoritmi di compressione supportati. • Cipher Suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA: scambio chiavi di sessione 3DES_EDE_CBC: cifratura simmetrica SHA: funzione hash one-way per MAC • U allega una sequenza di byte casuali.

33. Server hello • S riceve il msg (client hello) da U • S selezione un algoritmo di compressione tra quelli elencati da U. • S seleziona dalla cipher suite inviata da U una cipher suite comune (tra U e S). • S invia a U un msg (server hello) contenente gli elementi selezionati e una nuova sequenza di byte casuali. • Se U non riceve il msg server hello interrompe la comunicazione.

34. Scambio di Certificati • S si autentica con U inviandogli il proprio certificato digitale (sequenza di certificati emessi da diverse CA). • Se i servizi offerti da S devono essere protetti negli accessi, S può richiedere a U di inviargli il suo certificato (autenticazione di U con S).

35. Server hello done • S invia il msg server hello done a U. • server hello done sancisce la fine della fase in cui ci si accorda sulla cipher suite e sui parametri crittografici.

36. Autenticazione di S con U • U controlla la validità della data del certificato ricevuto da S. • U controlla che la CA che ha firmato il certificato sia tra quelle di cui si fida e che la firma sia autentica. • Se S spedisce una lista di certificati si controlla l’intera lista.

37. Invio del pre-master secretCostruzione del master secret • U costruisce un pre-master secret P (nuova sequenza di byte casuali codificati con il cifrario a chiave pubblica concordato con S. Nell’esempio U usa RSA e la chiave pubblica di S contenuta nel certificato) • U spedisce P a S dopo averlo cifrato con la chiave pubblica di S contenuta nel certificato e l’algoritmo concordato. • U combina P con alcune stringhe note + byte casuali contenuti in client hello e server hello e codifica il tutto con SHA e MD5 ottenendo il master secret M.

38. Ricezione di P e costruzione di M • S decifra il msg di U e ottiene P. • S calcola M nello stesso modo con cui U aveva calcolato M a partire da P. • Nota: S può farlo perché dispone delle stesse informazioni di cui dispone U.

39. Invio del certificato di U (opzionale) • Quando richiesto da S, U gli invia il suo certificato. • Se non lo possiede si interrompe il protocollo. • Insieme al certificato U allega, e firma con la sua chiave privata, la SSL-history. • S controlla il certificato e in caso di anomalie interrompe il protocollo.

40. U: Finished • U invia a S il msg finished protetto utilizzando M. • Costruzione di finished: FU = M + tutti msg di handshake scambiati finora + identità di U • U codificando FU con SHA e MD5 e lo invia a S.

41. S: Finished • S verifica il msg finished di Uricalcolando il tutto. • S invia a U il suo msg finished protetto utilizzando M. • Costruzione di finished: FS = M + tutti msg di handshake scambiati finora (incluso il msg finished di U) +identità di S. • S codifica FS con SHA e MD5 e lo invia a U. • U verifica il msg finished ricevuo da S.

42. A cosa serve M ? • S e U utilizzano M per generare le chiavi (sia per il cifrario simmetrico sia per le funzioni MAC) e per altri scopi... • Nota: Le chiavi utilizzate da S e U sono diverse ma note ad entrambi. Ciò rende il protocollo ancora più sicuro.

43. SSL record • I dati vengono frammentati in parti di lunghezza opportuna. • Ogni blocco viene numerato, compresso, autenticato con MAC, cifrato con chiave segreta e trasmesso usando il protocollo di trasporto sottostante (esempio: TCP). • Il destinatario opera in modo inverso al mittente e restituisce il messaggio all’applicazione sovrastante (esempio: HTTP).

44. Client Hello e Server Hello • In questa fase U e S si scambiano byte casuali (diversi ogni volta). • M è funzione di queste sequenze di byte casuali. • L’intruso non può riutilizzare i msg di handshake di sessioni precedenti per impersonare S in una successiva sessione con U (attacco di reply).

45. MAC in SSL record • Ogni blocco viene numerato e autenticato con MAC. • MAC= H(blocco, numero, K, stringhe note) • numero = 64 bit. No ripetizioni all’interno della stessa sessione !!! • Si previene così facendo l’uso fraudolento e iterato dello stesso blocco nella stessa sessione • Se un blocco viene perduto i blocchi successivi vanno ricreati e rispediti. • MAC sono cifrati insieme al messaggio con chiave simmetrica.

46. Autenticazione di S • S si autentica con uso di certificato. No men in-the-middle attack. • Il pre-master secret viaggia da U a S in modo sicuro in quanto U usa la chiave pubblica di S contenuta nel certificato.

47. Possibile autenticazione di U • Se richiesto U può autenticarsi mediante invio del suo certificato. • In pratica: Il sistema dispone di certificati mentre gli utenti di solito no. • Quando richiesto per autenticare U si procede con login e password.

48. Messaggi Finished • Questi messaggi vengono costruiti in base al master secret e contengono tutte le informazioni che i due partner si sono scambiati durante la fase di handshake. • Permettono a U e S di effettuare un controllo ulteriore sulle comunicazioni avvenute e di accertarsi di possedere lo stesso master secret. • Permettono a U e S di accertarsi che non ci sia stato un attacco di tipo man in-the -middle.

49. Generazioni Sequenze Casuali • Sono contenute in client hello, server hello e pre-master secret. • Da loro dipendono fortemente il master secret e quindi le chiavi segrete di sessione. • La sequenza contenuta nel pre-master secret è inviata da U a S in modo cifrato e la sua impredicibilità è cruciale per la sicurezza del canale SSL. • Se il generatore di sequenze pseudo-casuali non è di qualità l’intero protocollo si indebolisce.

50. Conclusioni • SSL è sicuro quanto la più debole cipher suite da esso supportata. • Sarebbe meglio disabilitare nel proprio browser tutti i protocolli con chiavi troppo corte (esempio: cifrari simmetrici con chiavi a 40 bit e asimmetrici con chiavi fino a 512 bit) • Non effettuare connessioni con sistemi anonimi perché si rischia che la propria password venga estorta !!!