Crittografia e sicurezzadelle reti

• IPSEC• Scambio di chiavi (Diffie Hellman)• SSL/TLS• SET

Architettura di sicurezza

IP

TCP

SSL/TLS

Applicaz. (SHTTP)

IPSEC

applicazioni sicure(ad es. PGP, SHTTP,SFTP, ecc.)

oppure

si introduconoprotocolli sicuri alivelli 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 - IP Security• Lo studio di applicazioni sicure soddisfa

l’utente (es. S/MIME, PGP, Kerberos,SSL/HTTPS)

• E’ opportuno disporre di un meccanismo pergarantire la sicurezza a tutte le applicazioni:si trattano problemi di sicurezza checoinvolgono diversi livelli protocollari

• IPSEC non è un singolo protocollo ma uninsieme di protocolli include lo schema diinterazione 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 (vediRFC 2401/2402/2406/2408...)

• Obbligatorio in IPv6, opzionale in IPv4

IPSec

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

• 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

IPSec Schema

Security Associations• Una relazione one-way tra mittente e

ricevente che fornisce sicurezza del flusso didati

• Definita da tre 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 chiavesegreta

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 & limitatasegretezza del flusso di traffico

• Può fornire gli stessi servizi di autenticazionedi AH (opzionale)

• Ampia scelta di codici (chiave segreta) emodalità di funzionamento– DES, Triple-DES, RC5, IDEA, CAST ecc.– CBC più usato

Encapsulating Security Payload

ESP - Modalità Trasporto vsModalità 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 autenticazioneModalità Trasporto

ESP - Codifica e autenticazioneModalità 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

Utilizzo di più SA -2

Utilizzo di più SA -3

Utilizzo di più SA -4

Gestione delle chiavi

• IPSEC permette di generare edistribuire 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 Oakley & ISAKMP

Oakley• Protocollo di creazione di chiavi

– Utilizza metodo di scambio delle chiavi proposto daDiffie-Hellman

• Aggiunge altre caratteristiche migliorative– cookies, definizione di gruppi (per codifica),

nonces, scambio di chiavi con autenticazione– diverse implementazioni (aritmetica dei campi finiti

è la proposta originaria di DH)• Fornisce metodi di autenticazione:

– Firma, chiave pubblica, chiave segreta

ISAKMPInternet Security Association and Key

Management Protocol• Fornisce gli strumenti per la gestione delle

chiavi• Definisce procedure e formati dei pacchetti

per– stabilire, negoziare, modificare, e cancellare SA

• E’ indipendente dai protocolli di scambio dellechiavi, di codifica e di autenticazione

ISAKMP

Scambio pubblico di chiaviDiffie Hellman• Alice e Bob non condividono informazioni

segrete e vogliono eseguire un protocollo perstabilire una chiave da condividere

• Trudy ascolta ma non riesce ad ottenereinformazioni sulla chiave (a meno che abbiatempo e risorse di calcolo illimitate)

Logaritmo Discreto

• Sia G un gruppo e g un generatore di G.• Sia y=gx e x il più piccolo intero che

soddisfa l’equazione.• x è il logaritmo discreto di y in base g.

Es.: y=gx mod p, p primo nel gruppomoltiplicativo di Zp

Dis. Log. e One Way Function

Sia y=gx mod p nel gruppo moltiplicativo di Zp

Esponenziazione è polinomiale (veloce) O(log3p)Il logaritmo discreto è considerato un problema

computazionalmente difficile• x gx è facile (computazionalmente veloce).• gx x si crede sia difficile (computionally non

possibile).• x gx è un esempio di one way function.

Scambio di chiavi di Diffie-HellmanParametri pubblici: un primo p, e un elemento g

(possibilmente un generatore del gruppomoltiplicativo Zp* )

• Alice sceglie a caso a in [1..p-2] e manda ga modp a Bob.

• Bob sceglie a caso b in [1..p-2] e manda gb mod pa Alice.

• Alice e Bob calcolano gab mod p : Bob ha b, calcola (ga)b= gab. Alice ha a, calcola (gb)a= gab.

DH - Requisiti di Sicurezza• Requisito di sicurezza: la chiave segreta è una

funzione one way dell’informazione pubblica e dellainformazione trasmessa.

• Meccanismo “costruttivo”: la chiave segreta deveutilizzare sia informazioni pubbliche che segrete inmodo opportuno.

• DH è almeno tanto difficile quanto il DL in Zp.L’equivalenza formale non è nota anche se ci sonoindicazioni parziali.

• Veloce anche con p di 512-1024 bit O(log3p).• Per avere chiave DES uso primi 56 bit della chiave

DH - Requisiti di Sicurezza• Dopo 25 anni di attacchi è ancora considerato

sicuro.• Lo scambio di chiavi di DH Key è effettivo

solo in presenza di un attaccante passivo.L’attacco Man-in-the-middle è letale.Risposta: autentica dei messaggi

Station To Station ProtocolSi autenticano i messaggi con chiave pubblica (si

assume che siano note con certezza); A e B simettono d’accordo su primo p e generatore g diZp* (pubblico)

• Alice sceglie a e manda ga mod p a Bob.• Bob sceglie a caso b; applica DH e calcola

chiave k usando ga e b; firma (ga,gb), codifica lafirma con k e invia il tutto a Alice insieme a gb

• Alice calcola k; decodifica con k e verifica lafirma di Bob; firma (ga,gb) e codifica la firmacon k.

Altri metodiL’idea può essere applicata a qualunque gruppo algebrico

non solo a Zp

• Limitazione: si devono usare gruppi in cui il Log.discreto è computazionalmente difficile

Esempio: gruppo additivo di Zp

Utilizzati in pratica: gruppomoltiplicativo e sistemi dicurve ellittiche

Sicurezza nel Web

• Secure Socket Layer (SSL) e TransportLayer 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 handshakedefinisce una chiave segreta con cuicodificare i dati del pacchetti SSL

• Integrità dei Messaggi: il protocollo dihandshake definisce una chiave segretausata per l’autentica dei messaggi (MAC)

SSL - Record Protocol

Calcolo MACHash(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 214 = 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 a blocchi– 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 Specun messaggio di un byte (1); aggiorna lo stato

Protocollo Alertcomunica situazioni di allarme; 2 byteLivello allarme 1=warning, 2=fatalTipo allarme

Unexpected messageBad-record_macDecompression failureHandshake failureIllegal_parameter…

Protocollo di HandshakeLa 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 HandshakeFasi1. Hello: determina funzionalità sicurezza2. Server invia il certificato, richiede

certificato e propone scambio chiave disessione

3. Client invia il certificato e continua scambiodi chiavi

4. Cambia il pacchetto di cifratura e finisce ilprotocollo di handshakeNB: alcune richieste sono opzionali

Handshake Prot. -Tipi di MessaggiMessage type Parametri1. Hello-request null2. Client-hello version,nonce(32B),sessionID,

cipher suite, metodo compress.3. Server_hello <come sopra>4. Certificate catena di certificati X.509v35. Server_key_exchange parametri, firma6. Certificate_request tipo, autorità7. Server_done null8. Certificate_verify firma9. Client_key_exchange parametri, firma10.Finished valore hash

HandshakeProtocol -Fasi

Handshake Protocol - Fase 1Si 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 1Metodi per lo scambio di chiavi

1. RSA : si codifica la chiave con la chiave pubblica deldestinatario

2. Diffie-Hellman (diverse versioni)1. Fisso2. Effimero Ephemeral Diffie Hellman3. Anonimo

3. FortezzaMetodi per la codifica crittografica

1. Algoritmo di cifratura2. Algortimo MAC3. Tipodi cifratura (blocco o stream)4. Dimensione Hash (byte): 0, 16 - MD5, 20 - SHA-15. Key material – sequenza di byte usati per generare ke chiavi

di scrittura6. dimensioni del vettore inizializzazine per CBC

Handshake Protocol - Fase 2Autenticazione Server e scambio di chiaviServer invia

1. Certificato: catena certificati X.509 (nonrichiesto con Diffie-Hellman anonimo)

2. Server_key_exchange (non usato con DH fisso)• Hash(Client_hello.random||ServerHello.random||ServerP

arms)

3. Certificate_request: richiesta di certif. (eautorità)

4. Server_hello_done: “Ho finito e aspetto lerisposte”

Handshake Protocol - Fase 3Autentica 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 4Fine: si passa alla fase successi cipher_spec1. Client invia

1. messaggio Change_cipher_spec2. Finished message under new algorithms, keys

(new cipher_spec)2. Server sends back

1. messaggio Change_cipher_spec2. Finished message under new algorithms, keys

(new cipher_spec)

Transport Layer Security -TLSSimile 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 chiaviIn 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_Nsono i nonce scambiati in handshake)– MD5(PMK,SHA(‘A’,PMK,Cl_N,S_N))– MD5(PMK,SHA(‘BB’),PMK, Cl_N,S_N))– MD5(PMK,SHA(‘CCC’),PMK, Cl_N,S_N))

SSL - Generazione chiaviLe 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(MK,SHA(‘A’,MK,Cl_N,S_N))– MD5(MK,SHA(‘BB’),MK, Cl_N,S_N))– MD5(MK,SHA(‘CCC’),MK, Cl_N,S_N))– .....

TLS Generazione di chiaviSi parte da un seme S e da un valore segreto MK iniziali

K(S,MK) = HMAC_MK(A(1),S)HMAC_MK(A(2),S)HMAC_MK(A(3),S) ....

A(0) = SA(i) = HMAC(K,A(i-1))

Pagamenti con SSLSi 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 -2Problemi• 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 - 3Esperienza mostra che la gran parte delle

contestazioni è dovuta a pochi cattivicommercianti

Quindi si fa pagare caro le dispute (perespellere 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

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 unatransazione

– 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

SET - Scenario

SET - Transazione1. Il cliente apre un conto2. Il cliente riceve un certificato3. Negoziante ha il proprio certificato4. Il cliente fa un ordine5. Il negoziante viene verificato6. Il cliente invia l’ordine di pagamento7. Il negoziante richiede l’autorizzazione al pagamento8. Il negoziante conferma l’ordine al cliente9. Il negoziante fornisce quanto richiesto e chiede il

pagamento

Istruzioni di acquisto e dipagamento

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 leistruzioni di pagamento?

Firma duale

• Soluzione• Cliente firma hash di ordine acquisto e

ordine di pagamento

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

Esecuzione pagamentoAcquirente invia ordine acquisto

Esecuzione pagamentoNegoziante verifica l’ordine del cliente