Distribuzione delle chiavi pubbliche. Gestione delle chiavi. Distribuzione delle chiavi pubbliche

Transcript

1 Gestione delle chiavi Distribuzione delle chiavi pubbliche Distribuzione delle chiavi pubbliche Uso dei protocolli a chiave pubblica per distribuire chiavi segrete Annuncio pubblico Elenco pubblico Autorità di distribuzione Certificati Annuncio pubblico K pub A 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 Utente A Utente B K pub A K pub A K pub B K pub B K pub B Ad esempio: la chiave pubblica viene messa in allegato ai messaggi di posta elettronica

2 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! 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 Elenco pubblico Utente A K pub A Elenco chiavi pubbliche K pub B Utente B 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)

3 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 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) K Aut (K puba,req,t 2 ) Autorità di distribuzione 5 Autorità di distribuzione 2 req,t 2 Vantaggi req,t 1 1 A 3 7 K Aut (K pubb,req,t 1 ) K PubB (ID A,N 1 ) K PubA (N 1,N 2 ) K PubB (N 2 ) 6 4 B 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

4 Certificati Autorità di certificazione K pubb L autenticità delle chiavi è certificata da una Autorità Pubblicazione chiavi: K PubA C A =K Aut (t 1,ID A, K puba ) C A =K Aut (t 2,ID B, K pubb ) L interessato riceve la certificazione della propria chiave pubblica tramite una 1 comunicazione autenticata con l Authority A B C A C B 2 Certificati Distribuzione delle chiavi segrete 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 Crittografia a chiave pubblica relativamente lenta Una volta distribuite le chiavi pubbliche le uso per distribuire le chiavi segrete

5 Un primo protocollo Un primo protocollo 1. A genera (K puba, K priva ) A B: K puba,id A B genera Ks B A: K puba (K s ) Si scartano (K puba, K priva ) Garantisce riservatezza ma non autenticazione Es.: Man in the middle attack 1. A E: K puba,id A 2. E B: K pube,id A 3. B E: K pube (K s ) 4. E A: K puba (K s ) Un secondo protocollo: chiavi pubbliche già distribuite. Le chiavi pubbliche sono già state distribuite Per autenticazione: 1. A B: K pubb (ID A,N 1 ) 2. B A: K puba (N 1,N 2 ) 3. A B: K pubb (N 2 ) Un secondo protocollo: chiavi pubbliche già distribuite. A genera K s e la spedisce a B: A B: K pubb (K priva (K s )) Vantaggi Garantisce riservatezza ed autenticazione Svantaggi Computazionalmente pesante

6 Uno schema ibrido 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 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 Lunghezza delle chiavi Pesantezza dei protocolli dipende dalla lunghezza della chiave Chiave serve lunga per contrastare brute force attack SSL Secure Socket Layer Attenzione a non spedire con K pub messaggi troppo corti!

7 SSL: applicazioni telematiche SSL E-commerce Trading on-line Internet banking... Protocollo proposto dalla Netscape Communications Corporation Garantisce confidenzialità e affidabilità delle comunicazioni su Internet Protegge da intrusioni, modifiche o falsificazioni. SSL Confidenzialità + Autenticazione. Utente U: Client Sistema S: Server Sistema ibrido. Ibrido: Cifrari Simmetici + Cifrari Asimmetrici + Cerificati + MAC HTTP SSL HTTPS HTTP SSL TCP/IP TCP/IP

8 SSL Handshake SSL SSL Record SSL Handshake crea un canale sicuro, affidabile e autenticato tra U e S entro il quale SSL record fa viaggiare i messaggi incapsulandoli in blocchi cifrati e autenticati. 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. Client U - Client hello - Pre-master secret - Cert. del Client - Finished Server S - Server hello - Cert. del Server - Rich. Cert. Client - Server hello done - Finished - Scambio sicuro dati - Scambio sicuro dati Record Handshake 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.

9 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. 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). Server hello done Autenticazione di S con U 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. 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.

10 Invio del pre-master secret Costruzione 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. 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. 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. U: Finished U invia a S il msg finished protetto utilizzando M. Costruzione di finished: F U = M + tutti msg di handshake scambiati finora + identità di U U codificando F U con SHA e MD5 e lo invia a S.

11 S: Finished S verifica il msg finished di U ricalcolando il tutto. S invia a U il suo msg finished protetto utilizzando M. Costruzione di finished: F S = M + tutti msg di handshake scambiati finora (incluso il msg finished di U) +identità di S. S codifica F S con SHA e MD5 e lo invia a U. U verifica il msg finished ricevuo da S. 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. SSL record Client Hello e Server Hello 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). 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).

12 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. 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. Possibile autenticazione di U Messaggi Finished 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. 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.

13 Generazioni Sequenze Casuali Conclusioni Sono contenute il client hello, server hello e premaster 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. 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!!!