Crittografia: Seconda parte

Distribuzione delle
chiavi pubbliche
Gestione delle chiavi
• Distribuzione delle chiavi pubbliche
• Uso dei protocolli a chiave pubblica
per distribuire chiavi segrete
•
•
•
•
Annuncio pubblico
Elenco pubblico
Autorità di distribuzione
Certificati
Annuncio pubblico
• L’utente rende di pubblico dominio la
propria chiave pubblica
Kp
Utente A
ub
A
K pub A
Kp
ub
A
• Pubblicazione chiavi:
– Tutti possono pubblicare la propria chiave
Kp
• Accesso:
– Tutti possono accedere alle chiavi degli
altri
Utente B
ub
B
K pub B
Kp
ub
B
Ad esempio:
la chiave pubblica viene
messa in allegato ai
messaggi di posta
elettronica
Elenco pubblico
(directory)
Annuncio pubblico
• Directory mantenuta da un’entità fidata
(authority)
• 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 !
• 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
Elenco
chiavi
pubbliche
u
Kp
Utente A
bA
• Accesso:
Kp
ub
B
Utente B
– 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)
Elenco pubblico
Autorità di distribuzione
• 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
• 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)
KAut(KpubA,req,t2)
Autorità di
distribuzione
2
Autorità di distribuzione
5
req,t2
• Vantaggi
– Garantisce l’identità dei partecipanti e
l’attualità delle chiavi
KAut(KpubB,req,t1)
req,t1
• Svantaggi
KPubB(IDA,N1)
1
4
3
6
A
KPubA(N1,N2)
7
KPubB(N2)
B
– Necessita di un’entità fidata super-partes
che va interpellata per ogni nuovo
partecipante
– La Directory può essere violata
KpubB
Autorità di
certificazione
Certificati
CA=KAut(t2,IDB, KpubB)
• L’autenticità delle chiavi è certificata da
una Autorità
CA=KAut(t1,IDA, KpubA)
KPubA
• Pubblicazione chiavi:
– L’interessato riceve la certificazione della
propria chiave pubblica tramite una
comunicazione autenticata con l’Authority
CA
A
1
2
B
CB
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
Distribuzione delle
chiavi segrete
• Crittografia a chiave pubblica
relativamente lenta
• Una volta distribuite le chiavi
pubbliche le uso per distribuire
le chiavi segrete
Un primo protocollo
Un primo protocollo
•
1.
•
•
•
•
A genera (KpubA, KprivA)
A B:
KpubA ,IDA
B genera Ks
B A:
KpubA(Ks)
Si scartano (KpubA, KprivA)
Un secondo protocollo:
chiavi pubbliche già distribuite.
•
•
•
Garantisce riservatezza ma
non autenticazione
Es.: Man in the middle attack
1.
2.
3.
4.
A E:
E B:
B E:
E A:
KpubA,IDA
KpubE ,IDA
KpubE(Ks)
KpubA(Ks)
Un secondo protocollo:
chiavi pubbliche già distribuite.
Le chiavi pubbliche sono già state
distribuite
• A genera Ks e la spedisce a B:
Per autenticazione:
• Vantaggi
1. A B:
2. B A:
3. A B:
KpubB(IDA,N1)
KpubA(N1,N2)
KpubB(N2)
A B: KpubB(KprivA(Ks))
– Garantisce riservatezza ed autenticazione
• Svantaggi
– Computazionalmente pesante
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
• Attenzione a non spedire con Kpub
messaggi troppo corti!
SSL
Secure Socket Layer
SSL: applicazioni telematiche
•
•
•
•
E-commerce
Trading on-line
Internet banking
......
SSL
• Protocollo proposto dalla Netscape
Communications Corporation
• Garantisce confidenzialità e affidabilità
delle comunicazioni su Internet
• Protegge da intrusioni, modifiche o
falsificazioni.
SSL
• Confidenzialità + Autenticazione.
• Sistema ibrido.
• Ibrido: Cifrari Simmetici + Cifrari
Asimmetrici + Cerificati + MAC
Utente U: Client
Sistema S: Server
HTTP
HTTP
HTTPS
SSL
SSL
TCP/IP
TCP/IP
SSL Handshake crea un canale sicuro,
affidabile e autenticato tra U e S
entro il quale ...
SSL Handshake
SSL
SSL Record
... SSL record fa viaggiare i messaggi
incapsulandoli in blocchi cifrati
e autenticati.
Client U
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.
Server S
Client hello
- Client hello
- Pre-master secret
- Cert. del Client
- Finished
- Finished
Handshake
- Server hello
- Cert. del Server
- Rich. Cert. Client
- Server hello done
• 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
- Scambio sicuro dati
Record
- Scambio sicuro dati
3DES_EDE_CBC: cifratura simmetrica
SHA: funzione hash one-way per MAC
• U allega una sequenza di byte casuali.
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.
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.
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).
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.
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.
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.
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.
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.
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:
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.
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).
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.
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).
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.
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.
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.
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.
Generazioni Sequenze Casuali
• 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.
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 !!!