Protocolli di sicurezza - CNRSSL e TLS • SSL e’ stato creato da Netscape (SSL 2.0, SSL 3.0) •...

Protocolli di sicurezza

Fabio Martinelli(IIT-CNR)

[email protected]

C Consiglio Nazionale delle Ricerche - PisaIit Istituto di Informatica e Telematica

Outline• Protocolli

– per confidenzialita’ ed autenticazione• SSL

– Protocolli di scambio chiavi• Diffie-Hellman, ….

– Protocolli di autenticazione• Needham-schroeder, Kerberos …

• Cenni di analisi automatici di protocolli di sicurezza(se possibile)– Esempio di analisi di OpenCA


Transport Level Security

• Il focus e’ nella sicurezza Host-to-Host – SSL (Secure Socket Layer)– TLS (Transport Layer Security)

• Protocolli per connessioni Web sicure– Canali confidenziali

• Autenticazione lato server• Autenticazione lato client (opzionale)

– Uso dei certificati X.509 a chiave pubblica


Sicurezza nello stack TCP/IP


SSL e TLS

• SSL e’ stato creato da Netscape (SSL 2.0, SSL 3.0)

• TLS, la sua naturale estensione da un working group IETF

• TLS puo’ essere visto come SSLv3.1


Architettura SSL


SSL records


Protocollo Secure Socket Layer

• Garantisce la sicurezza delle comunicazioni suInternet– Riservatezza dei dati ottenuta con cifratura

simmetrica– Autenticazione delle identità delle connessioni

ottenuta tramite presentazione di certificati digitali– Chiave segreta scambiata con l’applicazione di

algoritmi di cifratura asimmetrici


Struttura

• SSL è un protocollo a due strati• Si colloca logicamente fra strato di trasporto ed applicazioni

Http

Applicazioni

Telnet Ftp

SSL HandShake ProtocolSSL Record Protocol

Protocollo di trasporto TCP / IPC Consiglio Nazionale delle Ricerche - PisaIit Istituto di Informatica e Telematica

SSL Handshake Protocol

• Scambio preliminare di informazioni tra le due parti comunicanti

• Versione del protocollo (v3 / v2)• Set di algoritmi crittografici da utilizzare nella

successiva fase di Record• Scambio dei certificati digitali• Generazione della chiave segreta


SSL Handshake Protocol

CLIENT SERVER

“Ciao! Voglio parlare con te. Comprendo DES, RC4, IDEA, etc.…”

“Ciao, mi piace DES.Questo e’ il mio certificato, controlla la validita’.

“Ok ho generato una chiave DES e la mando cifratacon la tua chiave pubblica.”

(Il Server decifra il messaggio ed ottiene la chiave DES…)Ok, iniziamo a scambiare messaggi.

.

.

.

Canale cifrato con la chiave DES


Piu’ precisamente,

• C → S : nomeC ,VerC , Crypto_setC• S → C : VerS , Crypto_setS ,

• {nomeS, Pk(S)} Pr(CA)

• C → S : {shared_secretc}Pk(S)

Cosa garantisce?


Cosa non garantisce …

Possibile attacco al passo tre:C → X(S) : {shared_secretC} Pk(S)

X(C) → S : {shared_secretX} Pk(S)

E’ grave questo attacco?


Autenticazione del client

• C → S : nomeC ,VerC , Crypto_setC• S → C : VerS , Crypto_setS , {nomeS, P_KeyS} Pr(CA)

• C → S : {nomeC, P_KeyC} Pr(CA) , {shared_secretc} Pk(S),{Hash{shared_secretc} }Pr(C)


Transport Layer Security

• Definito nel RFC 2246.• Simile a SSLv3.• Alcune differenze:

– Numero di versione– MAC (message authentication code)– Funzione per la generazione dei numeri pseudo casuale– Messaggi di allarme– Algoritmi di cifratura– Certifcati lato client– Procedure di verifica dei certificati

– ....


Sicurezza a livelloapplicazione

• Obiettivo e’ la sicurezza End-to-End– Non si assume che il livello sottostante offra dei meccanismi

di sicurezza• Protocolli di autenticazione complessi e scambio

chiavi– Diffie Hellman, Kerberos, Needham-Schroeder, …

• Sicurezza delle E-mail– PGP = Pretty Good Privacy– SMIME

• Sicurezza delle procedure delle certificaitonauthorities– OpenCA etc..


Protocolli per scambio chiavi

• Ne abbiamo gia’ visto uno: SSL!– Si crea una chiave di sessione (per crittografia

simmetrica) e si distribuisce in maniera sicurausando la crittografia asimmetrica

– Semplice, effettivo, ma richiede l’uso dei certificati.• Un altro e’ Diffie-Hellman

– Permette di creare un segreto tra due principals– Poi uno dei due o entrambi, sul canale cifrato che

si instaura, puo’ eseguire un protocollo diautenticazione



Diffie-Hellman: Un protocolloper scambio chiavi

• Un protocollo per generare un segreto S condiviso solo fra Alice e Bob

• Dipende nella difficolta’ del discrete logarithm problemCalcolare z = g^w mod p e’ facile

z = 2^4 mod 11 … z = 5Il problema inverso, ovvero trovare w dati z, g, p e’

difficile3 = 2^ w mod 11 … w = ?

Diffie-Hellman details1. inizio: determinare un numero primo grande p, ed un

generatore g, 1 < g < p.Possono essere valori pubblici.

2. Alice: sceglie x, spedisce A = g^x mod p a Bobx e’ segreto

3. Bob: sceglie y, spedisce B = g^y mod p ad Alicey e’ segreto

4. Entrambi: calcolano S = g ^ (x*y) mod pAlice: S=B^x mod p. Bob: S=A^y mod p.Il punto e’ che

(g^(x) mod p)^y mod p= (g^(y) mod p)^x mod p

• Eve, potendo solo ascoltare i messaggi p,g,A,B, non puo’ trovare S


Problemi di autenticazione (richiamo)

• I principals provano quello che sono (autenticazionedi identita’)

• Per quanto riguarda le chiavi ci sono problemi disegretezza/confidenzialità e di freschezza

• Per fornire la confidenzialita’ usualmente si cifrano le informazioni di identita’ e le chiavi di sessione– Richiede algoritmi sicuri di distribuzione chiavi (chiavi

condivise) o crittografia asimmetrica• La freschezza e’ utile per eliminare i replay attacks

– Vi ricordate l’esempio della banca?– Garantita usando numeri di sequenza (da ricordare), marche

temporali (timestamps) o meccanismi di challenge/response


Needham-Schroeder (NSPK)


Il protocollo a chiave pubblicadi NSPK

1977- Pubblicato (7 passi).1981- Un attacco e’ stato trovato nei primi 4 passi1990- Una prova formale della correttezza del

protocollo e’ stata data

1995 – Un attacco e’ stato trovato negli ultimi 3 passi[Lowe-95] ?!?

1996- Una prova della correttezza degli ultimi 3 passie’ stata data ?!?!?

1996- L’attacco del 1995 e’ stato trovato con meccanismidi analisi automatica [Lowe-96]


Ultimi tre passi1) A-> B : {A,Na}PK(B) 2)B-> A : {Na ,Nb}PK(A) 3) A-> B : {Nb}PK(B)

• Obiettivo del protocollo e’ garantire che A e B sono vivi (alive) e che entrambi conoscono Na e Nb (e nessun altro)

• Vediamo ciascun passo:– Dopo il primo passo cosa possiamo dire?– Dopo il secondo passo cosa possiamo dire?– E dopo il terzo?


L’attacco di Lowe (1995)1) A-> B : {A,Na}PK(B) 2)B-> A : {Na ,Nb}PK(A) 3) A-> B : {Nb}PK(B)

L’attacco:

A X B--{A,Na}PK(x) -->--{A,Na }PK(B) ->

<-{Na ,Nb}PK(A)--<-{Na ,Nb}PK(A)----{Nb}PK(X) -->

--{Nb}PK(B) -->


Per ripararlo il secondo passo diviene B-> A : {Na ,Nb, , B}PK(A)

Kerberos

• Protocollo di autenticazione distribuita (RFC 1510)

• Nella mitologia greca, un cane con tre teste, gurdiano dell’ingresso agli inferi


Kerberos• Kerberos è un meccanismo per l’autenticazione in

sistemi distribuiti. • Utilizzabile quando:

– Le risorse sono di tipo eterogeneo (sistemi,servizi server, applicazioni DBMS)

– I sistemi sono di tipo diverso ( *nix, Windows ecc…)– I sistemi sono logicamente e fisicamente separati

• Kerberos permette di amministrare centralmente l’autenticazione mediante uno o più AuthenticationServices/Servers

– La sicurezza diventa un servizio standardizzato applicabile allo stesso modo su sistemi eterogenei


Kerberos

• Utilizzo di OneTimePasswd (OTP) per l’accesso ai servizi

• Gestione centralizzata della procedura di autenticazione

• Un solo sistema adibito alla gestione degli account

• Le chiavi di accesso non viaggiano in chiaro• Rilascia agli utenti un biglietto (ticket)con il

quale accedere ai vari servizi


L’authentication server

• È l’unica entità che gestisce la procedura di autenticazione-autorizzazione in un “realm”

– Deve essere chiusa qualunque back door per entrare nel sistema senza passare dall’AS

• Una volta autenticato un utente, gli fornisce una serie di ticket per accedere alle risorse del sistema

• Il ticket è costruito in modo tale che anche se rubato o duplicato, non può essere utilizzato se non dall’utente autorizzato


Kerberos: come funziona

• L’utente che vuole accedere ad un servizio si presenta all’AS, dichiarando la propria identità e il nome del servizio stesso

• L’AS restituisce un ticket crittografato il cui contenuto è accessibile solo all’utente e al servizio

• L’utente “spende” il ticket per accedere al servizio• NB :

– accesso a n servizi = n ticket di accesso– n accessi in tempi diversi allo stesso servizio = n ticket di

accesso


Richiesta di accesso (1)

• L’utente non deve necessariamente autenticarsi verso l’AS

• L’utente dichiara all’AS la propria identità e il servizio al quale desidera accedere

• L’AS conosce la password dell’utente, con la quale cifra il ticket di risposta


Ticket

• È composto da due componenti:• Box1: un messaggio cifrato con la password

dell’utente, in un formato prestabilito, contenente il nome del servizio richiesto e una chiave di sessione “random” PWD generata dinamicamente

• Box2: un messaggio cifrato con la password del servizio richiesto, in un formato prestabilito, contenente il nome dell’utente e la medesima chiave di sessione “random” PWD contenuta nel Box1– Dalla versione 4 il Box2 può essere contenuto nel Box1



• L’utente riceve i due Box• Decifra Box1 con la sua password, dal quale estrae la

session key– Nel caso in cui Box2 è inserito all’interno di Box1 lo estrae

decifrandolo con la sua password

• L’utente non può accedere al Box2, ma ne crea un altro (Box3) nel quale inserisce la data e ora corrente, e lo cifra con la session key

• Finalmente, per accedere al servizio, l’utente gli invia Box2 e Box3



• Il servizio riceve Box2 e Box3:– Decifra Box2 dal quale estrae la Session Key– Con la session key, decifra il Box3, e verifica che

la data inserita corrisponda al tempo di macchina corrente ( + o - 5 minuti)

– Se la decifrazione e il tempo contenuto nel Box 3 hanno avuto successo, l’utente potrà accedere al servizio


Autenticazione e autorizzazione

• Il ticket (Box2) contiene il nome utente e quindi permette di identificarlo in modo sicuro

• L’Authenticator (Box3) permette di verificare che l’utente il cui username è contenuto nel Box2 sia stato capace di estrarre la session key, e che il ticket non sia stato “sniffato” e successivamente proposto di nuovo al servizio da parte di un attacker

• Mutua autenticazione: il server può a sua volta generare un authenticator da inviare al client per comprovare la sua identità


Kerberos Versione 4• C = Client• AS = authentication server• V = server/verifier• IDc = identifier of user on C• IDv = identifier of V• Kc = secret encryption key shared by AS an C• ADc = network address of C• Kv = secret encryption key shared by AS an V• TS = timestamp


Autenticazione semplice

(1)C --> AS: IDc, IDv(2) AS --> C: Box1C, Box2V

(3) C --> V: {TS, IDc}K || Box2V

(4) V --> C: {TS+1}K

Box1c = {TS, K, IDv}KC

Box2v = {TS, K, IDv}Kv


Alcuni problemi..

• Richiede sincronizzazione tra i clock dei variserver

• Dato l’uso elevato degli accessi al AS richiede un uso frequente della chiave simmetrica condivisatra AS e client


In aggiunta …

• Per accedere a n servizi devo inserire n volte la password per effettuare le richieste all’AS

• Per risolvere il problema potrei mantenere la password in una cache sul sistema client(soluzione poco sicura)

• In alternativa, Kerberos prevede l’esistenza di un servizio aggiuntivo : il Ticket GrantingServer


TGS

• Logicamente distinto dall’AS• Può essere installato sul sistema dell’AS o su un altro

elaboratore• Per accedere ad un servizio, l’utente richiede un

ticket per accedere al TGS, come nella procedura precedentemente descritta fa per qualsiasi altro servizio

• Dopo aver ottenuto il ticket, l’utente lo utilizza per ottenere dal TGS un Ticket Granting Ticket (TGT)


Accesso ai servizi con TGT

• Ricevuto il TGT, ogni volta che l’utente desidera accedere ad unservizio, egli effettua una richiesta non all’AS, ma al TGS: la risposta è cifrata non con la password utente, ma con la sessionkey che l’AS ha rilasciato per la comunicazione con il TGS

• La risposta spedita dal TGS contiene la nuova session key per la comunicazione con il servizio richiesto

• La session Key utilizzata tra utente e TGS rimane valida per alcune ore (tipicamente 8) e quindi non è più necessario che l’utente inserisca la propria ogni volta che accede ad un servizio– In questo caso è possibile mantenere la session key in cache, certi

che dopo alcune ore non sarà più valida• Il TGT è inserito in una “credential cache”



Fonte: Microsoft

Versione 4 con TGS


Cross Realm Authentication

• L’autenticazione centralizzata può causare i seguenti problemi:– La sicurezza della rete dipende da un unico sistema: se il

sistema viene attaccato con successo la rete intera è vulnerabile

– Il sistema è esposto ad attacchi DoS– Il server centrale rischia di diventare il collo di bottiglia

dell’intera rete

• Il problema può essere in parte risolto suddividendo logicamente la rete e i servizi in più “realms”



• Qualora la rete sia suddivisa in più realm, è necessario prevedere forme di accesso attraverso più realms: cross realmauthentication

• Ogni Realm ha il proprio AS e il proprio TGS• Per accedere ad un realm diverso dal proprio,

è necessario che il realm di appartenenza registri un R(emote)TGS



• Per accedere ad un servizio che appartiene ad un altro realm, l’utente deve:– Accedere all’AS per richiedere l’utilizzo del TGS– Contattare il TGS per accedere al RTGS– Contattare il RTGS per accedere la servizio remoto

• In alcuni casi, l’uso di più di un realm può risultare inefficiente: in tal caso la soluzione ottimale è quella di stabilire gerarchie di realm, in modo tale che per accedere a più di uno, è sufficiente contattare uno ( o più) realm intermedio/i


N.B: Leggi TGS per KDC


Analisi automatica diprotocolli (a livello

concettuale)


Il problema …• Problema: Data una descrizione formale e rigorosa di un protocollo di sicurezza,

data una proprieta’ di sicurezza, stabilire in maniera automatica se il protocollosoddisfa tale proprieta’, e in caso contrario fornire la sequenza di un possibileattacco.

• Vari metodi sviluppati negli anni, particolare vi e’ stato un massiccio sviluppo dopola scoperta dell’attaco di Lowe, che e’ stato trovato nel 1996 con un tool per l’analisidi protocolli specificati con una process algebra chiamata CSP

• Un approccio sviluppato da noi

– Approccio di analisi: Analisi dei protocolli di sicurezza come sistemi aperti, ovvero sistemicon componenti non specificate (1998)

– PaMoChSA: Uno strumento software automatico per trovare attacchi nei protocolli disicurezza (1999)

– Un caso di studio: le procedure di enrollment di Open CA (2001)


Abbiamo capito che:

• I protocolli distribuiti sono difficili da progettare:– Bisogna coordinare tra loro agenti che cooperano– Si devono gestire le problematiche relative agli errori di

comunicazione etc… (e quindi di coordinazione)– ……

• I protocolli crittografici sono anche piu’ difficili:– Dobbiamo considerare che ci sono degli agenti esterni al

protocollo (oppure agenti interni non fidati) che attivamenteagiscono contro gli altri partecipanti!


Trasferimenti bancari(ricordate?)

• Ricordate il protocollo (errato) per i trasferimentibancari?


Sistemi aperti

C

D

A B

Intruder

Intruder

Malicious component

Specification: A | B | C | D Specification: A | B | C | D | [ ] Specifica: A | B | [ ] | D | [ ]


Il metodo di analisi e’ il seguente

• Il protocollo e’ specificato ad un adeguato livellodi astrazione

• In pratica solo i passi di comunicazione tra i principals sonodescritti– Azioni di spedizione/ricezione

• Le proprieta’ algebriche delle funzioni di cifratura sonogestite tramite equazioni tra termini

• Le proprietà dei protocolli di sicurezza sono espresse tramite formule logiche (spesso temporali)


Quali proprieta’ di di sicurezzapossiamo verificare?

Sia proprieta’ di sistema che di rete

• Segretezza• Autenticazione• Non-repudiation&Fairness (protocolli per firma di contratti on-line)• Information flow

– Non-interference• Integrita’• Availability • …


PaMoChSAPartial Model Checking Security Analyzer

[Martinelli, Petrocchi, Vaccarelli-SFM’01]

• Input / Output

Descrizione del protcollo

Proprieta’

Conoscenza iniziale dell’intruder

No Attack Found! /

Attack Found!

Quali proprieta’ possiamo analizzare ??

•Segretezza, autenticazione, etc..


Un caso di studio: Open CA

• Abbiamo verificato l’architettura di OpenCA(software con cui e’ implementata un CA a regime nel nostro istituto) – Risultato:

• Open CA e’ sicura almeno a livello concettuale (nullapossiamo dire a livello implementativo)

• “Un sistema e’ sicuro tanto quanto la sua componentepiu’ debole”

– Open CA ha un server on line» Un attacco riuscito sul servr puo’ causare l’emissione di

certificati sbagliati. Questo non e’ del tutto intuitivo in quantola chiave privata della CA, quella usata per emettereeffettivamente i certificati risiede in un server off-line!


Autorita’ di certificazione• Queste sono delle terze parti fidate che

emettono certificati digitali:– Un certificato digitale consiste di almeno un

nome di un utente, diciamo A, e la sua chiavepubblica, diciamo pb(A).

– Certificati digitali sono firmati con la chiaveprivata della CA, ovvero pv(CA):• Per esempio, {A,pb(A)}pv(CA) e’ il certificato digitale per

l’utente A.

– Come sono emessi i certificati digitali, tramitequale procedura?


OpenCA procedura di enrolment

User Enrolment Server

Registration Server

CA

Operator

6

1

2

3

4

5 Off-line On-line

1. U->ES:{nameU, pkU, pinU, {pkU, nU}pv(U) } = msg1

2. U->Op:{{nameU}pv(Gov) , pinU,} = msg2 Op->RA: 3.1. {{nameU}pv(Gov) , pinU} = msg3 RA->Op:3.2. msg1Op->RA:3.3 {msg1}pv(Op)

4. RA->CA: msg1

5. CA->RA:{nameU,pkU}pv(CA) = msg4

6. ES->U: msg4


Risultati della analisi

OpenCA funziona:– Non emette certificati incorretti come p.es.:

• {A, pb(B)}pv(CA) , dove il nome di A e’ associato con la chiave pubblica di B, in tal caso potremmo avere due attacchi:

– Se A e’ il legittimo utente e B e’ un attaccante, allora potremmo avere il cosiddetto attacco di responsabilita’:

» B firma un contratto come A, mentre risulta che e’ A ad essere responsabile per quel contratto!

– Se B e’ il legittino utente e A e’ un attaccante, allora potremmo avere il cosiddetto attacco di credito:

» B firma un messaggio che contiene una nuova scoperta scientifica ma e’ A a prenderne il credito!


Ma …

• OpenCA puo’ avere alcune debolezze potenziali!– Il pinU e SPKAC degli utenti potrebbero non essere ben

protetti:• In effetti questi sono memorizzati in chiaro nel server della

Registration Authority (RA) che e’ on-line.

• Quindi, attraverso un semplice attacco sul RA server, noi possiamo ottenere l’emissione di certificati sbagliati!



1 attacco: pinU compromesso1. U->ES:

{nameU, pkU, pinU, {pkU, nU}pv(U) } = msg11. X->ES:

{nameU, pkX, pinU, {pkX, nX}pv(X) } = msg1x2. U->Op:

{{nameU}pv(Gov) , pinU,} = msg2 Op->RA: 3.1. {{nameU}pv(Gov) , pinU} = msg3 RA->Op:3.2. msg1x (instead of msg1!!)Op->RA:3.3 {msg1x}pv(Op)

4. RA->CA: msg1x

5. CA->RA:{nameU,pkX}pv(CA) = msg4x

6. ES->U: msg4x

X spedisce a ES, un messaggio in cui il pin e’ lo stesso dell’utente U!!

Op spedisce il pinU , ma RARisponde al messaggio di X

con lo stesso pin!

Alla fine, il nome di U e’ connesso alla chiavepubblica di X!!!!!


2 attack: {pkU, nU}pv(U) compromesso1. U->ES:

{nameU, pkU, pinU, {pkU, nU}pv(U) } = msg11. X->ES:

{nameX, pkU, pinX, {pkU, nU}pv(u) } = msg1x2. U->Op:

{{nameX}pv(Gov) , pinX,} = msg2x Op->RA: 3.1. {{nameX}pv(Gov) , pinX} = msg3x RA->Op:3.2. msg1x Op->RA:3.3 {msg1x}pv(Op)

4. RA->CA: msg1x

5. CA->RA:{nameX,pkU}pv(CA) = msg4x

6. ES->U: msg4x

X spedisce a ES un messaggio dove

{pkU, nU}pv(U) e’ lo stesso diU!!

Da qui in avanti si ha unanormale sessione tra

X, OP, RA and CA

Alla fine, la chiave pubblicadi U e’ connessa a quella di X!!!!

Concludendo

• L’analisi dei protocolli di sicurezza puo’ essere trattata come analisi di sistemi aperti.

• Abbiamo implementato un software che analizza a livelloconcettuale I protocolli di sicurezza usando il nostro approccio(PaMoChSA Tool).

• Siamo in grado di scoprire automaticamente attacchi rimastiignoti per decenni possono essere trovati in poochi millisecondi– L’uso del nostro tool, come di altri similari richiede un

minimo sforzo di apprendimento.• I protocolli sono spesso specificati usando il linguaggio che

abbiamo usato noi


Ci sono molte limitazioni

• Limitazioni:– Il nostro tool permette di analizzare protocolli con un

numero finito di sessioni (due/tre per ruolo).• Altri tools/approcci fanno meglio..

– Come tutti, non gestiamo implementazioni, troppi dettagli dagestire…..


Altri approcci

• Molte altre tecniche di analisi esistono:• Esplorazione esaustiva di tutti i possibili stati della computazione• Model checking• Theorem proving• Analisi composizionale• Tecniche simboliche/unificazione• Programmazione logica e con vincoli• Analisi del controllo del flusso dei dati (statica)• ...


Materiale

• PaMoChSA web site:

– http://www.iit.cnr.it/staff/fabio.martinelli

• Ringraziamenti sono dovuti e Luca Bechelli e Marinella Petrocchi


Fine del ciclo di seminari!

• Un consiglio per la progettazione di protocollidi sicurezza puo’ essere riassunto come:– nel molto ci sta il poco….


Protocolli di sicurezza - CNRSSL e TLS • SSL e’ stato creato da Netscape (SSL 2.0, SSL 3.0) •...

Documents

Transcript of Protocolli di sicurezza - CNRSSL e TLS • SSL e’ stato creato da Netscape (SSL 2.0, SSL 3.0) •...