Crittografia e sicurezza delle reti

Crittografia e sicurezza delle reti IPSEC Scambio di chiavi (Diffie Hellman) SSL/TLS SET

Architettura di sicurezza Applicaz. (SHTTP) SSL/TLS TCP IPSEC IP applicazioni sicure (ad es. PGP, SHTTP, SFTP, ecc.) oppure si introducono protocolli sicuri a livelli più bassi (SSL, IPSEC)

Protezione a livello di link? Proteggere ogni hop Vantaggi si codifica tutto il traffico - inclusi header IP Svantaggi: richiede cooperazione fra i router grande sovraccarico (codifica/decodifica ad ogni hop) fornisce attaccante informazioni su codifiche di pacchetti simili (stesso pacchetto, header diverso)

IPSEC vs SSL SSL sopra TCP: IDEA: si vuole fornire sicurezza senza modificare il sistema operativo (TCP non partecipa alla crittografia) si richiede una modifca (minima) delle applicazioni SSL fornisce codifica sicura, autenticazione, generazione di chiavi ecc. IPSEC sopra IP: IDEA: sicurezza nel sistema operativo: fornisce sicurezza automaticamente a tutte le applicazioni IPSEC fornisce codifica sicura, autenticazione i pacchetti corretti vengono passati a TCP

IPSEC vs SSL Nessuna soluzione è perfetta SSL sopra TCP: TCP non partecipa alla crittografia. Supponi attaccante duplica un pacchetto e inserisce dati maliziosi nella copia. TCP accetta pacchetto con dati errati (se passa checksum TCP) che è rifiutato da SSL. Però TCP rifiuta pacchetto con i dati originali e NON li passa a SSL Soluzione: SSL chiude connessione

IPSEC vs SSL Nessuna soluzione è perfetta IPSEC sotto TCP: IPSEC effettua autenticazione utenti con comuni impementazioni API IP dice a TCP ( e all applicazione) indirizzo IP del mittente MA NON la sua identità (cosa necessaria in molte applicazioni) non partecipa alla crittografia. Soluzione: modifiche alle applicazioni sono comunque utili

Scambio pubblico di chiavi In IPSEC e SSL (e altri protocolli) è definita la possibilità di definire una chiave segreta su un canale non sicuro Metodo di Diffie Hellman Alice e Bob non condividono informazioni segrete e vogliono eseguire un protocollo per stabilire una chiave da condividere Trudy ascolta ma non riesce ad ottenere informazioni sulla chiave (a meno che abbia tempo e risorse di calcolo illimitate)

Logaritmo Discreto Sia G un gruppo e g un generatore di G. Sia y=g x e x il più piccolo intero che soddisfa l equazione. x è il logaritmo discreto di y in base g. Es.: y=g x mod p, p primo nel gruppo moltiplicativo di Z p

Logaritmo Discreto Sia G un gruppo e g un generatore di G. Si consideri l equazione y=g x il più piccolo intero x che soddisfa l equazione è il logaritmo discreto di y in base g (log discreto è l inverso di esponenziazione) Il logaritmo discreto è considerato un problema computazionalmente difficile x g x è facile (computazionalmente veloce). g x x si crede sia difficile (non possibile in tempo polinomiale, potrebbe essere un esempio di one way function.

Scambio di chiavi di Diffie-Hellman Parametri pubblici: un primo p, e un elemento g (possibilmente un generatore del gruppo moltiplicativo Z p * ) Alice sceglie a caso a in Bob. [1..p-2] e manda g a mod p a Bob sceglie a caso b in [1..p-2] e manda g b mod p a Alice. Alice e Bob calcolano g ab mod p : (Bob conosce b e g a, calcola (g a ) b = g ab. Alice conosce a e g b, calcola (g b ) a = g ab.

DH - Requisiti di Sicurezza Requisito di sicurezza: la chiave segreta è una funzione one way dell informazione pubblica e della informazione trasmessa. Meccanismo costruttivo : la chiave segreta deve utilizzare sia informazioni pubbliche che segrete in modo opportuno. DH è almeno tanto difficile quanto il DL in Z p. L equivalenza formale non è nota anche se ci sono indicazioni parziali. Veloce anche con p di 512-1024 bit O(log 3 p). Per avere chiave DES uso primi 56 bit della chiave Dopo 25 anni di attacchi è ancora considerato sicuro.

DH - Requisiti di Sicurezza Attacco Man-in-the-middle: Trudy si intromette tra A e B e effettua uno scambio di DH con Alice e Bob Alice ------------- Trudy -------------- Bob Alice definisce una chiave con Trudy (pensando di farlo con Bob) Bob definisce una chiave con Trudy (pensando di farlo con Alice) Trudy ha due chiavi per colloquiare con A e B!! L attacco è letale Lo scambio di chiavi di DH Key è effettivo solo in presenza di un attaccante passivo.

DH - Requisiti di Sicurezza Soluzione: autentica dei messaggi es. firma/autentica messaggio scambio; codifica segreta dello scambio serve che A e B condividano una chiave segreta oppure si utilizza chiave pubblica Chiavi Diffie Hellman pubbliche: stesso g e p per tutti gli utenti; ogni utente sceglie a una volta per tutte e lo usa sempre serve un meccanismo analogo a autorita certificazione delle informazioni pubbliche

Station To Station Protocol Si autenticano i messaggi di DH con chiave pubblica (si assume che siano note con certezza); A e B si mettono d accordo su primo p e generatore g di Z p * (informazioni pubbliche) Alice sceglie a e manda g a mod p a Bob. Bob sceglie a caso b; applica DH e calcola chiave k usando g a e b; firma (g a,g b ), codifica la firma con k e invia il tutto a Alice insieme a g b Alice calcola k; decodifica con k e verifica la firma di Bob; firma (g a,g b ) e codifica la firma con k Sono possibili altri metodi per autenticare

IPSEC - IP Security Lo studio di applicazioni sicure soddisfa l utente (es. S/MIME, PGP, Kerberos, SSL/HTTPS) E opportuno disporre di un meccanismo per garantire la sicurezza a tutte le applicazioni: si trattano problemi di sicurezza che coinvolgono diversi livelli protocollari IPSEC non è un singolo protocollo ma un insieme di protocolli & include lo schema di interazione per stabilire collegamento sicuro

IPSec Fornisce autenticazione riservatezza gestione delle chiavi Meccanismo generale: applicabile in LANs, WAN sia pubbliche che private, Internet La specifica completa è molto complessa (vedi RFC 2401/2402/2406/2408...) Obbligatorio in IPv6, opzionale in IPv4

Benefici di IPSec Un firewall fornisce sicurezza a tutto il traffico che attraversa il perimetro della rete Sotto lo strato di trasporto - quindi è trasparente alle applicazioni Può essere reso trasparente agli utenti finali Fornisce sicurezza a singoli utenti o a tutta la LAN Permette di realizzare VPN

IPSec - Servizi Servizi Controllo degli Accessi Integrità delle Connessioni Autenticazione dell origine del dato Rifiuto di pacchetti replicati Riservatezza crittografica dei messaggi Limitata segretezza del flusso di traffico 2 modalità trasporto: il pacchetto aggiunge IPSEC dati a pacchetto da spedire (header rimane immutato) tunnel: pacchetto viene incapsulato e trasportato in un altro pacchetto (con nuov header e dati IPSEC)

Schema IPSec

Security Associations Una relazione one-way tra mittente e ricevente che fornisce sicurezza del flusso di dati: parametri principali Security Parameters Index (SPI) IP Indirizzo di Destinazione Identificatore del Protocollo di Sicurezza altri parametri: n. di seq.- finestra anti-replay, info. sugli algoritmi usati, tempo di vita ecc. Si mantiene un database delle Security Associations

Authentication Header (AH) Fornisce supporto per l integrità dei dati e l autenticazione dei pacchetti IP end system/router can authenticate user/app utilizzano numeri di sequenza per prevenire attacchi che usano spoofing di indirizzi Utilizza un MAC (message Authentication Code) HMAC-MD5-96 o HMAC-SHA-1-96 Gli utenti devono condividere una chiave segreta

Authentication Header

Autenticazione end-to-end vs. Autenticazione end-to-intermediate

Modalità di Trasporto (autenticazione AH) Perchè non si autentica tutto l header?

Modalità di Tunnel (autenticazione AH)

Encapsulating Security Payload (ESP) Fornisce riservatezza dei messaggi & limitata segretezza del flusso di traffico Può fornire gli stessi servizi di autenticazione di AH (opzionale; discutibile perché c è AH: motivi storici leggera differenza) Ampia scelta di codici (chiave segreta) e modalità di funzionamento DES, Triple-DES, RC5, IDEA, CAST ecc. CBC più usato

Encapsulating Security Payload

ESP - Modalità Trasporto vs Modalità Tunnel Modalità trasporto si usa per crittografare e (opzionalm.) per autenticare i pacchetti IP i dati sono protetti ma header è in chiaro utile in connessioni host to host Modalità tunnel codifica tutto il pacchetto si aggiunge un nuovo header adatto per Virtual Private Networks (sicurezza da gateway a gateway)

ESP - Codifica e autenticazione Modalità Trasporto

ESP - Codifica e autenticazione Modalità Tunnel

Utilizzo di più Security Associations Una SA può realizzare o AH o ESP Per implementarle entrambe si usano più SA

Utilizzo di più SA -1

Gestione delle chiavi IPSEC permette di generare e distribuire le chiavi Si usano due coppie di chiavi una per ciascuna direzione per AH & ESP Gestione delle chiavi manuale - amministratore di sistema automatica - gestione di chiavi su richiesta usa ISAKMP/IKE

ISAKMP/IKE Molti protoccoli sono stati proposti per la gestione delle chiavi: (Photuris, Skip, Oakley, Skeme) basati su metodo di scambio delle chiavi proposto da Diffie- Hellman Tra le varie proposte IETF ha scelto come standard IKE (Internet Key Exchange Prot.) IKE comprende tre pezzi: IKE, ISAKMP (Internet Security Association and Key Management Protocol) e DOI (Domain of interpretation) La differenza fra ISAKMP e IKE è poco chiara La scelta di ISAKMP/IKE è discutibile: complicata, oscura

ISAKMP/IKE ISAKMP/IKE fornisce metodi di autenticazione: Firma, chiave pubblica, chiave segreta Definisce procedure e formati dei pacchetti per stabilire, negoziare, modificare, e cancellare SA Aggiunge altre caratteristiche migliorative: cookies, definizione di gruppi (per codifica), nonces, scambio di chiavi con autenticazione E indipendente dai protocolli di scambio delle chiavi, di codifica e di autenticazione DOI (Domain of Interpretation) definisce un particolare uso di ISAKMP

ISAKMP/IKE ISAKMP/IKE fase 1: autentica e definizione chiave sessione Autentica fra Alice ebob (semplificata): A a B: codifiche che supporto B a A: codifiche scelte da me A a B: g a mod p, B a A: g b mod p A e B calcolano K= g ab mod p A a B: K(Alice, prova che sono Alice) B a A: K(Bob, prova che sono Bob) prova : certificato chaive pubblica, chiave segreta predefinita)

ISAKMP/IKE Autentica: Chiave pubblica (KPA e KPB chiavi pubbliche) A a B: codifiche che supporto B a A: codifiche scelte da me A a B: g a mod p, KPB(nonce_A), KPB(Alice) B a A: g b mod p, KPA(nonce_B),KPA(Bob) A e B calcolano K= f(g ab mod p, nonce_a,nonce_b) (la chiave K dipende da DH e dai nonce) A a B: K( prova che sono Alice) B a A: K( prova che sono Bob) A e B conoscono la chiave perché codificano i nonce Nonce: con gli stessi parametri di DH si definiscono chiavi diverse Con chiave segreta preliminare: analogo

ISAKMP/IKE

Sicurezza nel Web Secure Socket Layer (SSL) e Transport Layer Security (TLS) SSL proposto da Netscape TLS working group nato in IETF La prima versione di TLS può essere considerata come SSLv3.1 Secure Electronic Transaction (SET)

SSL - Architettura

SSL - Servizi Riservatezza: il protocollo di handshake definisce una chiave segreta con cui codificare i dati del pacchetti SSL Integrità dei Messaggi: il protocollo di handshake definisce una chiave segreta usata per l autentica dei messaggi (MAC)

SSL - Record Protocol Perché prima si comprime e poi si codifica?

Calcolo MAC Hash(MAC_secret_key pad2 hash(mac_secret_key pad1 seqnum SSLcompressed.type SSLcompressed.length SSLcompressed.fragment)) pad1=0x36 ripetuto 48 volte (MD5); 40 voltesha-1 pad2=0x5c ripetuto SSLcompressed.type = il protocollo di alto livello usato per processare il frammento Simile a HMAC (SSL usa concatenazione invece di EXOR)

Metodi di codifica Frammenti 2 14 = 16384 bytes Non esiste metodo di compressione specificato in SSLv3: Compressione deve essere senza perdita e non deve incrementare la lungh. più di 1024 default: nessuna compressione Metodi di codifica IDEA (128) RC2-40, DES-40, DES (56), 3DES (168), Stream Cipher: RC4-40, RC4-128 Smart card: Fortezza

SSL - Formato record

SSL - Payload

Protocolli Change Cipher Spec e Alert Protocollo Change Cipher Spec un messaggio di un byte (1); aggiorna lo stato Protocollo Alert comunica situazioni di allarme; 2 byte Livello allarme 1=warning, 2=fatal Tipo allarme Unexpected message Bad-record_mac Decompression failure Handshake failure Illegal_parameter

Protocollo di Handshake La parte più complessa di SSL. Permette a client e server di Autenticarsi reciprocamente Negoziare metodi di codifica, alg. MAC e chiavi crittografiche Usato prima di scambiare dati. Ogni Messaggio ha tre campi Tipo (8) Lunghezza (24) Contenuto (>= 1 byte) parametri associati (diversi a seconda del tipo di messaggio)

Protocollo di Handshake Fasi 1. Hello: determina funzionalità sicurezza 2. Server invia il certificato, richiede certificato e propone scambio chiave di sessione 3. Client invia il certificato e continua scambio di chiavi 4. Cambia il pacchetto di cifratura e finisce il protocollo di handshake NB: alcune richieste sono opzionali

Handshake Prot. -Tipi di Messaggi Message type 1. Hello-request null Parametri 2. Client-hello version,nonce(32b),sessionid, cipher suite, metodo compress. 3. Server_hello <come sopra> 4. Certificate catena di certificati X.509v3 5. Server_key_exchange parametri, firma 6. Certificate_request tipo, autorità 7. Server_done null 8. Certificate_verify firma 9. Client_key_exchange parametri, firma 10.Finished valore hash

Handshake Protocol - Fasi

Handshake Protocol - Fase 1 Si attivano le funzionalità Client_hello Ë Versione = + alta vers. SSL utilizzabile dal client 32 bit time stamp + 28 bytes casuali (si usa un generatore pseudo casuale sicuro) sessionid: 0Ë stabilisce nuova connessione, non zero aggiorna parametri sessione esistente Metodi di codifica: sequenza di algoritmi in ordine decrescente di preferenza Metodi di compressione: lista di metodi proposti Server_hello Á torna indietro conferma tutto quanto sopra richiesto

Handshake Protocol - Fase 1 Metodi per lo scambio di chiavi (varianti introdotte per tenere conto di restrizioni nelle regole di esportazione USA) 1. RSA : si codifica la chiave con la chiave pubblica del destinatario 2. Diffie-Hellman (diverse versioni) 3. Fortezza Metodi per la codifica crittografica 1. Algoritmo di cifratura 2. Algoritmo MAC 3. Tipo di cifratura (blocco o stream) 4. Dimensione Hash (byte): 0, 16 - MD5, 20 - SHA-1 5. Key material sequenza di byte usati per generare ke chiavi di scrittura 6. dimensioni del vettore inizializzazine per CBC

Handshake Protocol - Fase 2 Autenticazione Server e scambio di chiavi Server invia 1. Certificato: catena certificati X.509 (non sempre richiesto con Diffie-Hellman) 2. Server_key_exchange (non usato con DH fisso) Hash(Client_hello.random ServerHello.random ServerP arms) 3. Certificate_request: richiesta di certif. (e autorità) 4. Server_hello_done: Ho finito e aspetto le risposte

Handshake Protocol - Fase 3 Autentica Client e scambio di chiavi Client verifica il certificato del server e i parametri del server Client invia 1. Certificato: (se richiesto) 2. Messaggio per lo scambio di chiavi (Client_key_exchange) 3. Informazioni per verificare il suo certificato (Certificate_verify message)

Handshake Protocol Phase 4 Fine: si passa alla fase successi cipher_spec 1. Client invia 1. messaggio Change_cipher_spec 2. Finished message under new algorithms, keys (new cipher_spec) 2. Server sends back 1. messaggio Change_cipher_spec 2. Finished message under new algorithms, keys (new cipher_spec)

Transport Layer Security -TLS Simile a SSLv3 Standard definito in RFC 2246. Differenze: version number message authentication code pseudorandom function alert codes cipher suites client certificate types certificate_verify and finished message cryptographic computations padding

SSL - Generazione chiavi In fase iniziale si determina Master Key si genera pre-master PMK, 48 byte RSA (chiave generata dal client e inviata crittata al server) Dif.-Hell. master key: concatenazione di 3 hash (Cl_N e S_N sono i nonce scambiati in handshake) MD5(PreMasterKey,SHA( A,PMK,Cl_N,S_N)) MD5(PreMasterKey,SHA( BB ),PMK, Cl_N,S_N)) MD5(PreMasterKey,SHA( CCC ),PMK, Cl_N,S_N)) denota concatenazione

SSL - Generazione chiavi Le chiavi di sessione sono generate a partire dalla Master Key - MK- con un metodo simile concatenazione di hash fino a quando si generano byte a sufficienza MD5(MasterKey,SHA( A,MK,Cl_N,S_N)) MD5(MasterKey,SHA( BB ),MK, Cl_N,S_N)) MD5(MasterKey,SHA( CCC ),MK, Cl_N,S_N))... MD5(MasetrKey, C) = impronta calcolata con MD5 e chiave MasterKey di C Confronta con i metodi di generazione dei numeri casuali

TLS Generazione di chiavi Si parte da un seme S e da un valore segreto K iniziali (HMAC(K,C) denota HMAC con chiave K di C) K(S,MK) = HMAC(K,A(1) S) A(0) = S A(i) = HMAC(K,A(i-1)) quindi K(S,MK) = HMAC(K,A(2) S) HMAC(K,A(3) S)... HMAC(K,HMAC(K,S) S) HMAC(K,HMAC (K, HMAC(K,S) ) S) HMAC(K,HMAC (K, HMAC(K, HMAC(K,S) ) ) S)...

Pagamenti con SSL Si usa SSL per trasferire il numero di carta di credito (decisione del negoziante) semplice non richiede software specialistico non richiede modifiche del sistema di pagamento delle carte di credito il metodo più usato oggi

Pagamenti con SSL -2 Problemi negozianti fraudolenti hanno informazioni su clienti clienti possono rifiutare i pagamenti (in assenza di firma) percentuale molto alta (20%- 60%!) di dispute pertanto il sistema è molto costoso per il negoziante

Pagamenti con SSL - 3 Esperienza mostra che la gran parte delle contestazioni è dovuta a pochi cattivi commercianti Quindi si fa pagare caro le dispute (per espellere i cattivi commercianti) Però Si penalizzano i commercianti onesti I commercianti possono scomparire Non si elimina il problema delle frodi dei clienti

Secure Electronic Transactions -SET SET non è parte del programma 2005-2006. I lucidi sono inseriti per completezza

Secure Electronic Transactions -SET Protezione transazioni carte di credito in Internet. Società coinvolte: MasterCard, Visa, IBM, Microsoft, Netscape, RSA, Terisa and Verisign Non è un sistema di pagamento. Include diversi protocolli e formati Fornisce un canale di comnicazione sicuro in una transazione Fornisce autentica con uso dei certificati X.509v3 Garanatisce la privatezza

SET Aspetti essenziali di SET: Riservatezza informazioni Integrità dei dati Autenticazione possessore carta di credito Autenticazione negoziante Molto complesso: non è chiaro suo effettivo utilizzo pratico

SET - Scenario

SET - Transazione 1. Il cliente apre un conto 2. Il cliente riceve un certificato 3. Negoziante ha il proprio certificato 4. Il cliente fa un ordine 5. Il negoziante viene verificato 6. Il cliente invia l ordine di pagamento 7. Il negoziante richiede l autorizzazione al pagamento 8. Il negoziante conferma l ordine al cliente 9. Il negoziante fornisce quanto richiesto e chiede il pagamento

Istruzioni di acquisto e di pagamento OI: informazioni sull acquisto privato da non comunicare alla banca firmato dal negoziante PI: istruzioni di pagamento prezzo, conto corrente, info su carta di credito da non rivelare al negoziante Come far firmare al cliente l ordine e le istruzioni di pagamento?

Firma duale Firma duale: Cliente firma hash(ordine acquisto ordine di pagamento) fornisce al negoziante info. per negoz.: firma duale, ordine, informazioni per verificare la firma duale, il suo certificato (per verifica della firma) info. per banca: istruzioni di pagamento, informazioni per verificare correttezza ordine di pagamento (codificate con chiave di sessione scelta da cliente)

Firma Duale: Sig_C(H(H(PI) H(OI))

Esecuzione pagamento Acquirente invia ordine acquisto Per banca: chiave di sessione codificata con ch.pubb. banca codifica co ch. sessione di PI, firma duale hash(oi) per negoz.: OI,firma duale, certificato cliente hash(pi) [usato per verificare firma duale]

Esecuzione pagamento Negoziante verifica l ordine del cliente negoziante verifica firma duale calcola hash OI, usa hash di PI per verificare firma (verifica certificato cl)