Patrizio ANGELINI Alessio BROZZI Giulia MASSIMI Roberto TURCHETTI Sicurezza in rete SSL Elementi di...

Patrizio ANGELINI

Alessio BROZZI

Giulia MASSIMI

Roberto TURCHETTI

Sicurezza in reteSSL

Elementi di Crittografia AA 2004/2005

2

Sommario

Introduzione Modelli e meccanismi di sicurezza SSL (Secure Socket Layer)

– Generalità– Architettura– Protocolli

Handshake Alert Change Cipher Spec Record

Conclusioni

3

Alessio Brozzi

Introduzione Modelli e meccanismi di

sicurezza SSL – Generalità,

obiettivi e funzionalità– Certificati e PKI– Commercio elettronico

9 giugno 2005 Sicurezza in rete – SSL (Angelini, Brozzi, Massimi, Turchetti) 4

Intro GM&M SSL EndA P

IntroduzioneSicurezza in rete

• Sicurezza a livello applicativo– concepita ad hoc per le applicazioni– richiede l’utilizzo di più meccanismi

• Sicurezza a livello trasporto– fornisce interfacce comuni a tutti i servizi applicativi– richiede piccole modifiche alle applicazioni

• Sicurezza a livello rete– funziona con applicazioni che non si curano affatto della sicurezza– consente di attraversare in modo sicuro domini non sicuri– può richiedere modifiche a livello Sistema Operativo

Intro



Modelli di sicurezzaCi sono due modi per fornire un trasporto sicuro (cioè non intercettabile da orecchie maliziose durante la trasmissione):

• usare un'infrastruttura di trasporto sicura− il protocollo non cambia, ma ogni pacchetto trasmesso nello

scambio di informazioni viene gestito in maniera sicura dal protocollo di trasporto

• usare un protocollo sicuro a livello applicazione− si usa un protocollo anche diverso, che si occupa di gestire la

trasmissione delle informazioni

M&M



Meccanismi di sicurezza• Livello applicazione

– PGP– S/MIME– Kerberos– HTTPS/SHTTP– SET

• Livello trasporto– SSL (Secure Socket Layer)

• Livello rete– IPSec

IP/IPSECIP/IPSEC

TCPTCP

HTTPHTTP FTPFTP SMTPSMTP

IPIP

TCPTCP

SSLSSL

HTTPHTTP FTPFTP SMTPSMTP

IPIP

TCPTCPUDP

KerberosKerberos SMTPSMTP HTTPHTTP

S/MIMES/MIME

PGPPGP

SETSET

HTTPSHTTPS

M&M



• PGP (Pretty Good Privacy)

– uno dei software dedicati alla sicurezza dei documenti e dei messaggi di posta elettronica, sviluppato da Zimmermann nel 1991

– PGPkey: è il portachiavi che mantiene la coppia di chiavi privata e pubblica e tutte le chiavi pubbliche dei vari contatti

– PGPmail: è la barra degli strumenti di PGP per criptare, decriptare, firmare, verificare e cancellare in modo sicuro

– PGPdisk: realizza un disco virtuale nel quale tenere tutti i documenti privati senza bisogno di criptarli singolarmente. Questo disco, finché non è montato, non è accessibile all’utente

– standard de facto per la cifratura di email

Meccanismi di sicurezzalivello applicazione (1)

M&M



• S/MIME (Secure/Multipurpose Internet Mail Extension) – estensione di MIME* che implementa funzionalità di sicurezza

introducendo nuovi tipi di contenuto per i messaggi di posta elettronica da utilizzarsi per inserire firme, certificati e blocchi di dati cifrati

– l’autenticazione si basa sui certificati X.509

• Kerberos– protocollo di autenticazione dei servizi di rete creato dal MIT– utilizza la crittografia a chiave segreta, evitando così la necessità di

inviare password attraverso la rete– consente di proteggere la rete dagli attacchi più comuni ma può risultare

complesso da implementare– il server mantiene tutte le chiavi segrete e dopo aver autenticato l’utente

distribuisce le session key– se il server è compromesso si perde l’integrità dell’intero sistema


* MIME è il formato standard dei comuni messaggi di posta elettronica

M&M



• HTTPS (RFC 2818)– introdotto da Netscape, trasmette i dati in HTTP semplice su un protocollo di

trasporto che si occupa di crittografare tutti i pacchetti (SSL) – la porta di ascolto del server e lo schema di URI (Uniform Resource

Identifier) utilizzati sono diversi da quelli del consueto HTTP

• S-HTTP (RFC 2660)– poco diffuso, incapsula richieste e risposte HTTP in un messaggio

crittografato secondo o un formato MIME apposito (MIME Object Security Services, MOSS), oppure un formato CMS (Cryptographic Message Syntax)

– più efficiente ma più complesso

• SET (Secure Electronic Transaction)– protocollo e infrastruttura per pagamenti con carte di credito– sviluppato in origine da Visa International e MasterCard International– limitato a messaggi inerenti transazioni commerciali– coinvolge (e certifica) acquirente, venditore e banca del venditore


M&M



Meccanismi di sicurezzalivello trasporto

• SSL (Secure Socket Layer)– privatezza della comunicazione

cifratura a chiave simmetrica

– autenticazione Serverutilizzo di certificati digitali per scambio

di chiavi

– autenticazione Client– integrità dei dati

M&M



Meccanismi di sicurezzalivello rete

• IPsec (IP security)– metodo robusto e facilmente espandibile a garanzia

della sicurezza del protocollo IP e dei protocolli di livello superiore

– protegge i pacchetti tra due host, tra due security gateway (router o firewall) oppure tra un sistema host ed un security gateway

– può essere implementato più semplicemente in HW rispetto ad SSL, il quale necessita di TCP

– non richiede alcuna modifica alle applicazioni o ai livelli superiori

– necessario modificare i sistemi operativi

M&M



SSL - Un bit di storia..

• Sviluppato ed introdotto da Netscape Communications Corporation– 1994 versione 1: diversi problemi, mai utilizzata– 1994 versione 2: implementata in Navigator 1– 1996 versione 3: implementata in Navigator 3– 1999 TLS (Transport Layer Security) RFC 2246

versione di SSLv3 standardizzata dall’IETF

SSL Gen



SSL – Obiettivi (1)

• Sicurezza del collegamento: stabilire un collegamento sicuro tra due sistemi– l’intento è quello di fornire un canale di comunicazione sicuro

autenticato con chiavi effimere, basandosi su credenziali crittografiche asimmetriche di lunga durata: certificati X.509

• Interoperabilità: programmatori di diverse organizzazioni dovrebbero essere in grado di sviluppare applicazioni utilizzando SSL, accordandosi sui parametri utilizzati dagli algoritmi di crittografia senza necessità di conoscere il codice l'uno dell'altro

SSL Gen



SSL – Obiettivi (2)• Ampliamento: fornire una struttura dentro la quale i

futuri metodi di crittografia a chiave pubblica e chiave simmetrica possano essere incorporati senza dover per questo creare un nuovo protocollo

• Efficienza: ridurre il numero di collegamenti che hanno bisogno di essere stabiliti ex-novo, soprattutto per non sovraccaricare la rete

SSL Gen



SSL - Funzionalità• Privatezza del collegamento: i dati vengono protetti

utilizzando algoritmi di crittografia a chiave simmetrica (ad es. DES, RC4, ecc.)

• Autenticazione: usando la crittografia a chiave pubblica i client sono sicuri di comunicare con il server corretto, prevenendo eventuali interposizioni.

È prevista la certificazione sia del server che del client

• Affidabilità: il livello di trasporto include un controllo sull'integrità del messaggio basato su un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure come SHA, MD5

SSL Gen



Una ( - certificati digitali e PKIUn certificato digitale:

• attesta la relazione tra un soggetto (individuo o altra entità) identificato tramite un insieme appropriato di dati (nome,cognome, etc..) e una chiave pubblica

• è un oggetto pubblico, accessibile da chiunque • è emesso da un’autorità di certificazione (CA)

che lo firma con la propria chiave privata• è conforme allo standard X.509

L’infrastruttura di gestione dei certificati prende il nome di Public Key Infrastructure (PKI)

SSL Gen



Certificati X.509

• Un certificato X.509 contiene varie informazioni, tra cui:– numero seriale– nome della CA che lo ha emesso– periodo di validità– nome del soggetto– chiave pubblica del soggetto– firma della CA

SSL Gen



Certificati X.509: utilizzo• I certificati consentono ai Web server ed ai client

l’autenticazione, per mezzo delle chiavi pubbliche, prima di stabilire una connessione

• Con un certificato si ha la garanzia che una data chiave pubblica appartenga ad un dato utente– tale garanzia è fornita dall’autorità di certificazione

• Per controllare l’autenticità del certificato dell’utente è necessario avere la chiave pubblica (quindi il certificato) della CA– i certificati della CA sono autofirmati (tanta fiducia… )– è necessario ottenerli con un meccanismo ad hoc (ad esempio

preinstallati nel sistema operativo o nell’applicazione)

SSL Gen



Certificati X.509:Gestione Browser

SSL Gen



Struttura della PKI (1)

• Certification Authority:

– l’Autorità che emette i certificati e le liste di sospensione e revoca

– dispone di un certificato con il quale sono firmati tutti i certificati emessi agli utenti

– è possibile costruire gerarchie di CAuna CA “root” genera e firma il certificato delle sotto-CA il processo può essere ripetuto per un numero infinito di livelli

– deve essere installata su di una macchina sicura

SSL Gen



• Registration Authority:– gli utenti vi si rivolgono per richiedere la certificazione

delle chiavi– richiede l’identificazione dell’utente tramite chiave

pubblica e indirizzo e-mail

• Certificate Server:– servizio di directory accessibile mediante un

“operational protocol”, tipicamente LDAP– lista di pubblicazione dei certificati e delle liste di

certificati revocati e sospesi

Struttura della PKI (2)

SSL Gen



Applicazioni pratiche

• Commercio elettronico– ordinazioni: le form con cui si ordina un prodotto

vengono inviate usando SSL– pagamenti: quando viene inserito un numero di carta di credito,

l’invio dei dati avviene usando SSL

• Accesso ad informazioni sicure– consultazione di informazioni accessibili solo

da utenti “qualificati”– invio di password o altri dati riservati

SSL Gen



Commercio elettronico – esempio (1)

Def: Siano dati• a ∈ A : A = { acquirenti con accesso a Internet }• b ∈ V : V = { venditori con catalogo elettronico su

Internet }.

Si definisce esempio di commercio elettronico tra a e b la sequenza di azioni:

1) a consulta il catalogo di b, sceglie la merce da acquistare e attiva la transazione

2) b fornisce ad a la propria chiave pubblica

SSL Gen



3) Il PC di a “automagicamente”:– prepara l’ordine elettronico m– genera una chiave k con cui codifica m m*– codifica k con la chiave pubblica di b k*– invia m* e k* a b

4) Il PC di b “automagicamente” :– decodifica k* con la chiave privata di b– con k decodifica m* e ottiene l’ordine

5) La merce viene spedita da b

Oss: come effettuare il pagamento?


SSL Gen



Def: Siano dati

• a ∈ A : A = { acquirenti con accesso a Internet }• b ∈ V : V = { venditori con catalogo elettronico

su Internet }• cc ∈ C : C = { società di carte di credito }.

Si definisce esempio di pagamento con carta di credito tra a e b tramite cc la sequenza di azioni:

• a consulta il catalogo di b, sceglie la merce da acquistare, fornisce i dati della propria carta di credito e attiva la transazione

SSL Gen




2) Il PC di a compie “automagicamente” due operazioni:– prepara l’ordine elettronico senza i dati della carta di credito e lo

invia a b– prepara la nota di debito con i dati della carta di credito e con

riferimento a b; codifica questa nota con un sistema di doppia codifica e la invia a cc

3) cc decodifica la nota di debito, effettua i controlli rituali, contabilizza l’addebito su a e l’accredito su b, comunica a b il buon esito contabile dell’operazione

4) b riceve il messaggio da cc ed evade l’ordine

TEO: il sistema è sicuro ma informaticamente complesso!

La dimostrazione è lasciata per esercizio al lettore…(sugg.: 2 collegamenti indipendenti…)

I Teorema del pagamento...(schema teorico)

SSL Gen



II Teorema del pagamento...(1)(schema reale)

TEO: assunte vere le ipotesi del I Teorema del pagamento esiste sempre un’alternativa semplice per risolvere il problema utilizzando SSL (Secure Socket Layer)

• il messaggio m contiene sia i codici della merce sia le coordinate della carta di credito

• m viene cifrato da a con un sistema a doppia codifica• m viene inviato a b• l’inoltro delle coordinate della carta di credito

a cc è a cura del venditore b

SSL Gen



II Teorema del pagamento...(2)(schema reale)

Vantaggi

• la chiave k viene generata presso il mittente a, cambia ad ogni transazione e non esce dal PC di a

• b è sicuro di ricevere tramite cc il corrispettivo della merce spedita

Svantaggi

• b viene a conoscere le coordinate della carta di credito di a: la sicurezza del sistema pertanto è anche in funzione dell’etica di b, non valutabile a priori

SSL Gen



II Teorema del pagamento...(3)(una variante)

SSL Gen

• il messaggio m contiene sia i codici della merce sia le coordinate della carta di credito

• m viene cifrato da a con un sistema a doppia codifica• m stavolta viene inviato a cc• l’inoltro dell’ordine al venditore b è a cura di cc

Tale schema presenta gli stessi vantaggi del precedente senza la necessità di basarsi sull’etica di b

30

Roberto Turchetti

Browser & SSL– Esempio

Architettura SSL Protocollo Handshake

– Fasi del protocollo– Esempio



Browser & SSL

SSL Gen


Modalità standard per accedere ai siti web con connessioni non sicure

Il simbolo del lucchetto aperto significa che non

c’è sicurezza né criptazione

Esempio (1)

SSL Gen



Messaggio che dimostra l’assenza

di certificato

Esempio (2)

SSL Gen



Si sta procedendo con pagamento mediante

carta di credito quindi la sessione diventa protetta

Esempio (3)

SSL Gen



Il certificato è stato rilasciato a www.itn.net

Esempio (4)

SSL Gen



Quindi i dati della carta di credito NON andranno a United

ma a Travelocity.com !!

Esempio (5)

SSL Gen



SSL a grandi linee

• SSL prevede una fase iniziale, detta di handshake, in cui viene usata una connessione TCP/IP non sicura

• Il risultato di tale fase, in cui avviene la contrattazione da parte di client e server del livello e degli algoritmi di sicurezza da usare, è l'avvio di una nuova sessione

• SSL procede con la cifratura (e/o con la messa in chiaro) della sequenza di byte del protocollo applicazione usato (dati, url, username e password…)

SSL Gen



Sessione SSL

• La sessione SSL è un’associazione logica tra client e server– definisce un insieme di parametri crittografici che possono

essere condivisi da varie connessioni

• La sessione evita la costosa rinegoziazione dei parametri di sicurezza per ciascuna connessione

SSL Gen



SSL - Architettura generale

SSL Arch



Architettura generalecomponenti di SSL (1)

• Protocollo SSL Handshake– permette al server ed al client di autenticarsi a

vicenda e di negoziare un algoritmo di crittografia e le relative chiavi prima che il livello di applicazione trasmetta o riceva il suo primo byte

• Protocollo Change Cipher Spec– rende operativo l’insieme di protocolli di cifratura

appena negoziati

SSL Arch



• Protocollo Alert– notifica situazioni anomale o segnala

eventuali problemi • Protocollo SSL Record

– è interfacciato su di un protocollo di trasporto affidabile come il TCP

– è usato per l'incapsulamento dei dati provenienti dai protocolli superiori. Si occupa della compressione, del MAC e della cifratura

Architettura generalecomponenti di SSL (2)

SSL Arch



Protocollo Handshake (1)

È responsabile della negoziazione di una sessione, che è costituita dai seguenti parametri:

– session identifer: identificatore della sessione scelto dal server– peer certificate: certificato X.509 dell'interlocutore (opzionale)– compression method: algoritmo di compressione– cipher spec: algoritmi di cifratura, autenticazione e relativi

parametri crittografici– master secret– is resumable: flag che indica se la sessione può essere utilizzata

per iniziare nuove connessioni

SSL HS



• autenticazione server– il client cifra dei dati segreti con la chiave pubblica del server

• autenticazione client– il client cifra alcuni dati tramite la sua chiave privata, creando in

pratica una firma


L'handshake consente a client e server di autenticarsi a vicenda usando un meccanismo a chiave pubblica:

SSL HS



La richiesta di una nuova connessione sicura può avvenire o da parte del client o da parte del server.

Client e server cooperano per:• la creazione di chiavi simmetriche usate per una

veloce cifratura/decifratura • la scelta della suite di cifratura (algoritmi e metodi di

compressione)


SSL HS



Handshake - Fasi

* opzionale

SSL HS



HS – dettagli (1)

Step1: Client Hello

Il client invia un messaggio “Client Hello” al Server per informarlo che vuole iniziare, o eventualmente rinegoziare, una sessione.

Il messaggio contiene i campi:

– protocol version: due byte utilizzati per indicare la versione di SSL in uso

– random byte: byte casuali generati dal client

– session identifier: 32 byte contenenti l'identificativo di una precedente sessione che potrebbe essere riesumata. Se sono tutti zero indicano che si tratta di una nuova sessione

– lista delle CipherSuite: lista contenente le combinazioni di algoritmi di crittografia supportati dal client, ordinata secondo le sue preferenze

– lista di compression method: lista di algoritmi di compressione, in ordine di preferenza, supportati dal client

SSL HS



Step2: Server Hello

La risposta del server può essere:• messaggio “Server Hello”, nel quale comunica la suite di

crittografia e l’algoritmo di compressione scelti e invia altri dati sulla sessione

• alert, nel caso di fallimento dell’handshake• failure, se il server non supporta gli algoritmi del client

Il messaggio contiene i campi:– protocol version: 2 byte che rappresentano la versione del protocollo

scelto. Questo valore corrisponde al minimo tra la versione del protocollo proposta dal client e la massima supportata dal server

– random byte: byte casuali generati dal server

…continua

HS – dettagli (2)

SSL HS



– session identifier: identifica la sessione che deve essere avviata. Se l'identificativo di sessione inviato dal client è diverso da zero la vecchia sessione verrà riesumata, nel caso in cui sia pari a zero il server setterà un nuovo identificativo per la sessione da avviare

– CipherSuite: una coppia di byte che rappresenta la famiglia di algoritmi scelta dal server tra quelli proposti dal client

– compression method: rappresenta il metodo di compressione scelto dal server tra quelli proposti dal client

…continua Server Hello

HS – dettagli (3)

SSL HS



• Step3: Server Certificate (opzionale)

Il server manda un messaggio di “Server Certificate” per la sua autenticazione. Se il server non ha un certificato, manda un “Server Key Exchange” che contiene i parametri per Diffie-Hellman o per RSA. La scelta dipende dalla CipherSuite selezionata.

Inoltre il server può richiedere al client un certificato (“Client Certificate Request”).

HS – dettagli (4)

SSL HS



• Step4: Server Hello DoneIl messaggio di “Server Hello Done” è inviato al client per indicare che la fase di Hello è completata. Dopo l'invio del messaggio il server si mette in attesa di una risposta

• Step5: Client CertificateIl messaggio “Client Certificate” viene inviato solo se il server ha richiesto un certificato. Se questo non è disponibile, il client lo segnalerà per mezzo di un messaggio di alert, al quale il server potrebbe rispondere con un errore fatale se l'autenticazione è necessaria

HS – dettagli (5)

SSL HS



• Step6: Client Key ExchangeIl messaggio “Client Key Exchange” deve essere inviato obbligatoriamente dal client al fine di fissare il pre-master secret (numero scelto casualmente), che viene utilizzato per calcolare il master secret, cioè un valore condiviso da client e server necessario alla generazione dell’insieme di chiavi utilizzate

• Step7: Certificate VerifySe il client in precedenza ha inviato un certificato, ora col messaggio “Certificate Verify” invierà l’hash dei messaggi di handshake scambiati fino a questo punto e del master secret, in modo che il server possa verificarne l’autenticità

HS – dettagli (6)

SSL HS



• Step8: Change Cipher Spec & Finished

Il messaggio “Change Cipher Spec” ha lo scopo di segnalare i cambiamenti delle strategie di cifratura. Inviato sia dal client che dal server per comunicare alla parte ricevente che i dati successivi saranno protetti dalle chiavi appena negoziate.

Il messaggio “Finished” viene inviato da entrambi per verificare che scambio di chiavi e autenticazione abbiano avuto successo. Questo è il primo messaggio protetto con l'algoritmo negoziato.

A questo punto la fase di handshake è completata ed il client ed il server possono cominciare a scambiare i dati del livello applicazione.

HS – dettagli (7)

SSL HS



Quando non hai capito…

SSL HS

54

Giulia Massimi

Generazione delle chiavi– MAC– CBC– Master secret– Key block

Protocollo Alert



Message Authentication CodeUn valore (detto anche checksum) ottenuto tramite una chiave privata per l’autenticazione di un messaggio. A differenza delle firme digitali, i MAC sono generati e verificati con la stessa chiave (simmetrica).

MAC

Messaggio M

Chiave segreta K

MAC(M,K)

Fornisce• Autenticità del messaggio M• Integrità del messaggio M

HASH(es: MD5)

Impronta (digest)

SSL …



Due parole sul CBC (1)

• L’algoritmo di autenticazione MAC può essere basato su Cipher Block Chaining – CBC

Il messaggio viene suddiviso in blocchi da 64 bit: M=M1M2…Mn

Ogni blocco di testo in chiaro viene cifrato utilizzando le informazioni del blocco di testo in chiaro precedente

Per evitare che messaggi identici vengano sempre cifrati allo stesso modo si usa un vettore inizializzato casualmente

SSL …



Due parole sul CBC (2)

Vettore di inizializzazione del processo (IV)

• applica CBC al messaggio M usando la chiave segreta k• scarta i primi n-1 blocchi C1,C2,…, Cn-1 e usa Cn

• invia M1,M2,…,Mn e il tag di autenticazione MACk(M) = Cn

SSL …



Il master secret pre master secret client_hello.random server_hello.random

master secret

client_write_MAC_secret

client_write_MAC_ secretclient_write_key

server_write_key

server_write_IV

client_write_IV

SSL …



Il master secret viene calcolato tramite una funzione

fPMS(Rclient, Rserver)

ovvero una funzione MAC basata sul pre-master secret abbastanza complicata e derivata dalla combinazione di SHA1 e MD5.

Generazione del master secret

SSL …



Le chiaviIl master secret è necessario alla generazione del key_block:

• Chiavi MAC:– server_write_MAC_secret: chiave segreta utilizzata per calcolare il MAC sui

blocchi generati nel livello inferiore del protocollo e inviati dal server– client_write_MAC_secret: chiave segreta utilizzata per calcolare il MAC sui

blocchi generati nel livello inferiore del protocollo e inviati dal client

• Chiavi simmetriche:– server_write_key: chiave simmetrica di sessione per i dati cifrati dal server e

messi in chiaro dal client– client_write_key: chiave simmetrica di sessione per i dati cifrati dal client e

messi in chiaro dal server

• Vettori di inizializzazione:– server_write_IV: sequenza di byte utilizzata per le cifrature in modalità CBC del

server– client_write_IV: sequenza di byte utilizzata per le cifrature in modalità CBC del

client

SSL …



Generazione delle chiavi (1)Il key_block viene calcolato tramite una funzione

fMS(Rclient, Rserver)

ovvero una funzione MAC basata sul master secret abbastanza complicata e derivata dalla combinazione di SHA1 e MD5.

SSL …



Generazione delle chiavi (2)• Il calcolo va effettuato finché non viene generato

un numero sufficiente di byte necessari alla formazione di tutte le chiavi

• Infine il key_block viene partizionato:

• La parte restante di key_block che non viene utilizzata da nessuna chiave verrà scartata

SSL …



Riassumendo

Pre-Master secretPre-Master secret

write_MAC_secretwrite_keywrite_IV

write_MAC_secretwrite_keywrite_IV

Client RandomServer RandomClient RandomServer Random

Master secretMaster secret

SSL …



Considerazioni (1)A seconda degli algoritmi crittografici scelti per la fase di autenticazione esistono diversi modi per generare il pre-master secret:

• RSA– il client genera un numero casuale (48 byte) e lo invia al server cifrato con

la chiave pubblica del server (presa dal suo certificato digitale) • Diffie-Hellman

– i parametri pubblici DH del server vengono estratti dal suo certificato; se il client ne ha uno anche i suoi DH vengono estratti da questo, altrimenti vengono generati al momento

• Diffie-Hellman Ephemeral– indipendentemente dai certificati, sia server che client generano al

momento i parametri di Diffie-Hellman per ogni sessione

Negli ultimi due casi il pre-master secret viene calcolato a partire dai parametri di Diffie-Hellman

SSL …



Considerazioni (2)

• RSA– pre-master secret è scelto unicamente dal client senza

consultare il server– intercettazione facile di tutto il traffico in caso di key-escrow

(furto o cessione obbligata, per motivi legali, della chiave privata del server)

• Diffie-Hellman– key-escrow: con i parametri segreti DH e l’intercettazione dei

dati scambiati si può risalire al master secret

• Diffie-Hellman Ephemeral– maggior impiego delle risorse di calcolo poiché ad ogni sessione

si devono rigenerare i parametri DH

SSL …



Protocollo di Alert (1)

• I messaggi di alert sono utilizzati per notificare eccezioni che possono avvenire nella comunicazione– contengono il livello di severità e una descrizione

dell'evento occorso– come gli altri messaggi anche quelli

di alert sono cifrati e compressi

SSL Alert



• Ogni messaggio è composto da due byte:

– il primo assume il valore (relativo alla gravità dell’allarme) warning (1) o fatal (2).

fatal determina l’abbattimento della connessione corrente

– il secondo contiene il codice che denota lo specifico allarme

Protocollo di Alert (2)

Fatal Warningunexpected_message close_notifybad_record_mac no_certificatedecompression_failure bad_certificatehandshake_failure unsupported_certificateillegal_parameter certificate_revoked

certificate_expiredcertificate_unknow

SSL Alert



• I messaggi di alert:

– close_notify: notifica al ricevente che il mittente non trasmetterà più su quella connessione

– unexpected_message: un messaggio inappropriato è stato ricevuto. Questo tipo di alert è sempre fatale

– bad_record_mac: questa allerta è spedita quando un record è ricevuto con un errato MAC

– decompression_failure: la funzione di decompressione ha ricevuto un errato input, ad esempio dati che si espandono oltre la lunghezza loro assegnata

– handshake_failure: indica che il mittente è incapace di negoziare un set accettabile di parametri di sicurezza tra quelli possibili

Protocollo di Alert - tipi messaggi (1)

SSL Alert



– no_certificate: può essere mandato in risposta ad un certificate request se non è disponibile una certificazione appropriata

– bad_certificate: in caso di certificazione errata (ad esempio se contiene una firma che non è verificata correttamente)

– unsupported_certicate: se una certificazione è di un tipo non supportato

– certificate_expired: una certificazione è scaduta o attualmente non valida

– certificate_unknown: qualche altro non specificato problema è sorto nel processare la certificazione

– illegal_parameter: un campo del handshake è di dimensione errata o inconsistente con altri campi

Protocollo di Alert - tipi messaggi (2)

SSL Alert

70

Patrizio Angelini

Protocollo Change Cipher Spec & Finished

Protocollo Record Conclusioni



Change cipher spec (1)

• Questo protocollo consiste di un solo messaggio composto da un singolo bit di valore 1, che è cifrato e compresso secondo la suite corrente di cifratura

• Questo messaggio ha lo scopo di far cominciare la comunicazione tra client e server rendendo effettive le proprietà appena concordate

• Un messaggio di change cipher spec inaspettato provoca un unexpected_message alert

SSL CCS



Change cipher spec (2)• Il client manda un messaggio di change cipher spec

subito dopo i messaggi di handshake key exchange and certificate verify

• Il server ne manda uno dopo aver processato con successo il messaggio di key exchange ricevuto dal client

SSL CCS



Change cipher spec (3)

• Quando si recupera una sessione si utilizzano le stesse chiavi negoziate precedentemente

• Il messaggio di change cipher spec è spedito subito dopo il messaggio di hello

SSL CCS



Finished message (1)• Il client invia al server il messaggio

finished protetto utilizzando il Master Secret M per verificare che lo scambio di chiavi sia avvenuto con successo

• Tale messaggio è composto da:

– FC = M + tutti msg di handshake scambiati finora + l’identità del client

• Il messaggio FC viene codificato con SHA e MD5 e

inviato al serverSSL CCS



Finished message (2)

• Il server verifica il messaggio finished FC del client ricalcolando il tutto

• Invia al client il suo messaggio finished utilizzando M

• Tale messaggio è composto da:– FS = M + tutti msg di handshake scambiati finora

(incluso il msg finished del client) + l’identità del client

• Anche FS viene codificato con SHA e MD5 e inviato al client

SSL CCS



Protocollo Record (1)

• Si occupa di trasportare dati utente, o messaggi protocollari SSL, da un peer all’altro, fornendo ai livelli superiori gli stessi servizi di TCP, con in più i servizi di sicurezza

• Riceve i dati dal livello superiore, li suddivide in blocchi, eventualmente li comprime, calcola il MAC, cifra il tutto e trasmette il risultato dell’elaborazione

SSL Record




SSL Record



• I dati applicativi vengono frammentati in blocchi di al più 214 (16.384) byte

• Compressione– opzionale– senza perdita– non deve far aumentare le dimensioni di un blocco di più di 1024 byte

• Calcolo del MAC– [Server|Client] write MAC key– sequence number– blocco compresso

• Cifratura– [Server|Client] write key– può essere a blocchi o a caratteri– non deve far aumentare le dimensioni di un blocco di più di 1024 byte


SSL Record



• Vettore di inizializzazione per CBC– per il primo record è quello derivato dal Master Secret– per ognuno dei successivi record è composto dagli ultimi byte di

quello precedente

• Header SSL– tipo di contenuto (Change cipher, alert, handshake, application)– versione principale (per sslv3 vale 3)– versione minore (per sslv3 vale 0)– lunghezza del record (max = 214 + 2048)


SSL Record



• Tipi di dati consegnati a questo protocollo– handshake protocol– alert protocol– change cipher spec protocol– application protocol

• Opera sempre all’interno di uno stato, che definisce gli algoritmi di compressione, cifratura e autenticazione e i parametri relativi (come le chiavi)– vengono mantenuti 4 stati: gli stati di lettura (per i record ricevuti)

e scrittura (per i record inviati) correnti e gli stati di lettura e scrittura pendenti


SSL Record



• Gli stati correnti devono essere aggiornati per ogni record elaborato e includono i seguenti elementi– stato della compressione: stato corrente dell'algoritmo di

compressione– stato della cifratura: comprende la chiave e altre informazioni

necessarie a definire lo stato dell'algoritmo, per esempio l'ultimo blocco nel caso di un cifrario a blocchi in modalità CBC

– MAC secret– numero di sequenza: valore incrementato dopo ogni record


SSL Record



I parametri di sicurezza definiti per uno stato sono settati fornendo i seguenti valori

– connection end: specifica se l’entità in questione è il client o il server

– bulk encryption algorithm: indica l’algoritmo di cifratura e i relativi parametri, come la lunghezza della chiave

– MAC algorithm: indica l’algoritmo di autenticazione ed i parametri relativi

– compression algorithm: indica l’algoritmo di compressione e i relativi parametri

– master secret: sequenza di 48 byte condivisa tra i due interlocutori

– client random: 32 byte casuali forniti dal client– server random: 32 byte casuali forniti dal server


SSL Record



MAC in SSL record

Il MAC di ogni blocco è così generato:

hash (MAC_write_secret + pad_2 + hash (MAC_write_secret + pad_1 + seq_num +length + content));

dove:

• " + " denota la concatenazione.• pad_1 è il carattere 0x36 ripetuto 48 volte per MD5 o 40 volte per

SHA• pad_2 il carattere 0x5c ripetuto lo stesso numero di volte del

precedente• seq_num è il numero di sequenza del messaggio• hash è l'algoritmo hash definito nella CipherSpec• MAC_write_secret è la sequenza segreta usata come chiave per le

operazioni di MAC sui dati inviati

SSL Record



Conclusioni

• Tipi di autenticazione• Studi e attacchi a SSL• Considerazioni• Vantaggi e svantaggi

End



Tipi di autenticazione

• Connessione anonima– server e client non presentano certificati– scambi di chiavi con Diffie-Hellman– attacco man in the middle

• Server autenticato– autenticazione e scambi chiavi combinati con RSA

• Server e client autenticati– entrambi dimostrano di conoscere la chiave privata

corrispondente alla pubblica presente nel certificato

End



Studi e attacchi a SSL (1)

• 2001: viene dimostrato che calcolare il MAC e poi cifrare è meno sicuro rispetto a cifrare e poi calcolare il MAC

• 2002: viene presentato un attacco agli schemi di padding per i cifrari a blocchi in modalità CBC

End



• 2003: l’attacco agli schemi di padding per i cifrari a blocchi in modalità CBC viene esteso a SSL/TLS e richiede:– un’informazione ripetutamente cifrata (per esempio la

password della posta elettronica)– un cifrario a blocchi in modalità CBC– la possibilità di effettuare attacchi attivi

tra client e server– la possibilità di distinguere i tempi di

esecuzione su errori differenti


End



• SSL protegge efficacemente da molti attacchi, quali brute force, crittoanalisi e man in the middle

• SSL è progettato per garantire sicurezza sulla rete. Quindi i dati: – sono protetti durante il transito sulla rete

– non sono protetti quando vengono memorizzati sugli host la maggior parte dei furti di numeri di carta di credito avviene sugli host Carlos Salgado, nel 1997, fu in grado di mettere le mani su oltre 100.000

numeri di carte di credito sfruttando bug presenti su server web

• I siti "protetti da SSL" sono più difficili da monitorare da parte degli amministratori di sistema perché gli IDS (Intrusion Detection System) non sono in grado di rilevare traffico SSL– un hacker che effettua un attacco usando SSL può risultare invisibile ai

sistemi di sicurezza!


End



Considerazioni (1)• Il buon funzionamento di SSL dipende

anche dall’accortezza dell’utente (rara)– controllo del lucchetto– verifica dei certificati– possibilmente accesso alla rete direttamente con https

• L'uso dell'algoritmo RC4 con chiavi di 40 bits può portare problemi– un paio di gruppi indipendenti sono riusciti a forzarlo in circa 8

giorni– tuttavia la scelta di RC4 è obbligata dalla legge USA

sull'esportazione degli algoritmi di crittografia

End



Considerazioni (2)• Ci sono diversi punti di SSL che, pur non essendo critici, potrebbero

offrire ulteriore sicurezza

– nel protocollo Handshake alcuni dati spediti con il CLIENT HELLO potrebbero essere spediti in un secondo momento, crittografati

– nel protocollo Record, un errato MAC non dovrebbe far terminare la connessione ma causare una richiesta di ripetizione del messaggio

pochi attacchi traggono vantaggio dalla duplice spedizione di dati, mentre in questo modo si apre la strada agli attacchi basati sul servizio negato

– i numeri di sequenza dovrebbero essere casuali invece che ordinati

Tuttavia la struttura attuale è stata concepita per permettere facili aggiornamenti ed il supporto a nuovi algoritmi di crittografia senza stravolgere la struttura di SSL

End



Stavolta finiamo veramente…• Vantaggi

– non richiede alcuna modifica al SO poiché SSL può essere implementato all’interno di ogni singola applicazione

– indipendente dal protocollo di applicazione utilizzato

– compatibile con tutti i browser

• Svantaggi– richiede modifiche, seppur minime, alle applicazioni

End



Riferimenti bibliografici

• Corso di Reti di calcolatori 2 del Prof. Di Battista

• http://www.dia.unisa.it/professori/ads/corso-security/www/CORSO-9900/SSL/

• http://telemat.die.unifi.it/book/Internet/Security/elab3.htm

• Specifiche del protocollo SSLv3.0 in: ftp://ietf.cnri.reston.va.us/internet-drafts/draft-freier-ssl-version3-01.txt

End

Patrizio ANGELINI Alessio BROZZI Giulia MASSIMI Roberto TURCHETTI Sicurezza in rete SSL Elementi di...

Documents

Transcript of Patrizio ANGELINI Alessio BROZZI Giulia MASSIMI Roberto TURCHETTI Sicurezza in rete SSL Elementi di...