D10 Autenticazione Crittografica Protocolli e Insidie

Autenticazione Crittografica Protocolli e Insidie

Luca Grilli

Premessa

• Le comunicazioni sicure quasi sempre richiedono una “stretta di mano” (handshake) preliminare per autenticare le parti comunicanti – spesso è necessario anche proteggere integrità e/o

confidenzialità delle informazioni trasmesse

• L’autenticazione richiede lo scambio di particolari messaggi tra le parti,

• e la conoscenza di particolari informazioni, alcune delle quali devono essere segrete

• Tutti questi aspetti vengono definiti nel protocollo

Protocolli di autenticazione crittografici

• Progettare protocolli di autenticazione (crittografici) sicuri nasconde molte insidie

– variazioni minime ad un protocollo sicuro possono introdurre delle falle molto pericolose

• per questo molti protocolli in uso presentano delle falle di sicurezza

• è cruciale comprendere a fondo le possibili falle di sicurezza di un protocollo

– attenzione alle modifiche a protocolli esistenti

– attenzione all’ambiente in cui il protocollo viene usato

Proprietà di un protocollo

• Oltre alla sicurezza sono importanti anche le prestazioni, ovvero l’efficienza del protocollo

• L’efficienza è data da

– numero di messaggi

– compattezza dei messaggi

– costo computazionale

– risorse di calcolo richieste

Protocolli di autenticazione crittografici

• Non esiste il protocollo migliore in senso assoluto – alcune minacce sono più frequenti e/o pericolose

in un dato contesto; in un altro possono anche non esistere

– è necessario tener conto delle risorse disponibili • CPU, memoria, hardware specializzato, spese per i

diritti di utilizzo di brevetti, ecc.

– dei vincoli progettuali relativi all’ambiente di uso

– e se gli utenti sono disposti a seguire le politiche di sicurezza

Iter progettuale di un protocollo

• Si parte da un primo protocollo – contenente sicuramente delle falle di sicurezza

• Si controllano tutte le debolezze immaginabili – relative al contesto d’impiego di quel protocollo

• Si rimuovono le debolezze una alla volta – attenzione, rimuovere una falla può introdurne altre non

presenti prima

• Rimossa una falla, si ricomincia daccapo e ci si arresta quando non ci sono più falle (tra quelle note!)

• conoscere le possibili falle è cruciale sia per progettare protocolli sicuri, sia per comprendere protocolli noti

Protocolli basati su password (in chiaro)

– molti protocolli di autenticazione esistenti furono progettati per ambienti in cui

• le intercettazioni non erano un problema, ed

• eventuali utenti malevoli erano considerati poco esperti

– ad esempio i protocolli basati su password che non includono alcun meccanismo di cifratura

• Alice (l’iniziatore) invia a Bob il suo nome e la password in chiaro attraverso la rete

• Bob verifica nome utente e password,

• in caso affermativo la comunicazione prosegue,

• senza alcuna ulteriore attenzione alla sicurezza (nessuna cifratura, nessun controllo di integrità crittografico)

Protocolli crittografici challenge/response

• Un miglioramento significativo della sicurezza si è avuto sostituendo – la trasmissione della password in chiaro

– con il meccanismo a sfida/risposta crittografico (cryptographic challenge/response)

• nelle prossime slide, si esamineranno

– protocolli crittografici a sfida e risposta basati sulla conoscenza di un segreto condiviso • usando sia algoritmi di cifratura a chiave segreta sia algoritmi

di digest

– successivamente, si discuteranno protocolli simili utilizzando la tecnologia a chiave pubblica

PROTOCOLLI A SFIDA E RISPOSTA UNIDIREZIONALI (“LOGIN ONLY”)

Autenticazione Crittografica – Protocolli e Insidie

Segreto condiviso – Notazione

R: sfida; numero casuale e non prevedibile

KAlice-Bob{R}: cifratura di R con un algoritmo a chiave segreta (DES, AES); KAlice-Bob è la chiave di cifratura

h(KAlice-Bob, R): hash di R dipendente dal segreto KAlice-Bob ad esempio la sfida R viene concatenata con KAlice-Bob

f(KAlice-Bob, R): quantità ottenuta applicando ad R una trasformazione crittografica dipendente dal segreto cioè f(KAlice-Bob, R) può essere sia KAlice-Bob{R} sia h(KAlice-Bob, R)

Prot. 1 – Chiave segreta unidirezionale

– si consideri il seguente protocollo di tipo “login only” • rappresenta un notevole passo in avanti rispetto a spedire la

password in chiaro

• uno spione non può impersonare Alice “ascoltando” lo scambio perché la sfida R cambia di volta in volta in modo non prevedibile

I’m Alice

f(KAlice-Bob, R)

a challenge R

Alic

e

Bo

b

Bob autentica Alice sfruttando un segreto condiviso KAlice-Bob

Prot. 1 – Debolezze

• Non c’è mutua autenticazione

– Bob autentica Alice, ma non il viceversa

• se Trudy può ricevere i pacchetti inviati all’indirizzo di rete di Bob, e rispondere con l’indirizzo di rete di Bob (o attraverso altri mezzi convince Alice che il suo indirizzo è quello di Bob)

• Alice sarà ingannata è crederà che Trudy è Bob

• Trudy non ha bisogno di conoscere il segreto condiviso KAlice-Bob per impersonare Bob

• deve solo limitarsi ad inviare ad Alice una qualsiasi vecchia sfida R e ignorare la sua risposta


• Se questo è l’intero protocollo

– cioè se non è prevista una protezione della confidenzialità del resto della conversazione

• allora Trudy può dirottare la conversazione dopo lo scambio iniziale,

• assumendo che sia in grado di generare pacchetti aventi per source address l’indirizzo di Alice (IP spoofing)

• potrebbe anche essere utile, ma non essenziale, per Trudy, poter ricevere pacchetti indirizzati ad Alice


• Se il segreto condiviso KAlice-Bob fosse derivato da una password,

– allora conoscendo R, f(KAlice-Bob, R) e l’algoritmo per ottenere la chiave dalla password,

– un intercettatore potrebbe sferrare un attacco off-line sulla password

• sceglie una parola w, quale password candidata

• calcola la relativa chiave segreta Kw

• e verifica se f(Kw, R) = f(KAlice-Bob, R)

• in caso negativo ritenta


• Qualcuno che accede (in lettura) al server Bob potrebbe ottenere KAlice-Bob – ciò è particolarmente rischioso se KAlice-Bob è

derivata da una password, e

– le password sono memorizzate in un database di Bob • proteggere il database implica proteggere tutti i suoi

backup

• impedendone l’accesso fisico o

• cifrando il contenuto e proteggendo in qualche modo la chiave di cifratura

Prot. 1 – Impiego

• Nonostante i precedenti svantaggi,

• se le risorse per aumentare la sicurezza sono molto limitate,

• il protocollo 1 costituisce un’alternativa molto più sicura rispetto ad inviare password in chiaro

– anche se KAlice-Bob viene derivata dalla password

Prot. 2 – Variante del Prot. 1

– Una piccola variante del prot. 1 è la seguente

• Bob sceglie una sfida random R, la cifra, e trasmette il risultato

• Alice decifra la quantità ricevuta, usando KAlice-Bob per ottenere R, ed invia R a Bob

I’m Alice

R

KAlice-Bob{R}

Alic

e

Bo

b

Bob autentica Alice sfruttando una chiave segreta condiviso KAlice-Bob

Prot. 2 vs Prot. 1

– Prot. 2 richiede l’uso di operazioni crittografiche invertibili • Prot. 1 può implementarsi usando solo algoritmi di hash; in

genere gli algoritmi di hash offrono migliori prestazioni e maggior portabilità

– Se KAlice-Bob è derivata da una password ed è pertanto vulnerabile ad attacchi dictionary • se inoltre R è una quantità riconoscibile, ad es. 32 bit

random + 32 bit nulli di padding Trudy può eseguire un attacco dictionary senza dover essere in grado di intercettare i messaggi (cosa non sempre facile)

• ovviamente, se può intercettare i messaggi scambiati tra le parti può eseguire un attacco dictionary in entrambi i protocolli

Prot. 2 vs Prot. 1

– Se R è una quantità riconoscibile con tempo di vita limitato; ad esempio R = random||timestamp

– anche Alice può autenticare Bob (autenticazione mutua)

• infatti, soltanto chi conosce KAlice-Bob può generare

KAlice-Bob{R} = KAlice-Bob{random||timestamp}

– è essenziale che R abbia una durata temporale molto limitata per evitare che KAlice-Bob{R} possa essere “riciclato” da un falso Bob

Prot. 3 – altra variante del Prot. 1

– la seguente è un’altra variante del protocollo 1 • utilizzando un timestamp invece di una sfida random R

• è sufficiente un solo messaggio per l’handshake

• Alice cifra l’istante temporale corrente,

• Bob decifra il risultato e si assicura che sia un istante temporale circa uguale a quello fornito dal suo orologio

• è necessario che gli orologi di Alice e Bob siano “ragionevolmente” ben sincronizzati

I’m Alice, KAlice-Bob{timestamp}

Alic

e

Bo

b

Bob autentica Alice sfruttando la sincronizzazione degli orologi e un segreto condiviso KAlice-Bob

Prot. 3 vs Prot. 1

– il prot. 3 può facilmente rimpiazzare un protocollo non crittografico in cui la password è inviata in chiaro

• non è necessario aggiungere lo scambio di ulteriori messaggi

– il prot. 3 è più efficiente del prot. 1

• oltre a risparmiare due messaggi, il server Bob non deve mantenere alcuno stato volatile (ad esempio R) riguardo Alice (assumendosi qualche rischio)

• inoltre può aggiungersi ad un qualsiasi protocollo di tipo request/response (come l’HTTP) ottenendo un’autenticazione mutua; basta che Bob invii ad Alice una risposta dipendente in modo opportuno dal suo timestamp originario (si vedrà in seguito)

Prot. 3 vs Prot. 1

– qualcuno potrebbe impersonare Alice intercettando e riusando KAlice-Bob{timestamp}

• tale attacco va però eseguito subito dopo aver intercettato KAlice-Bob{timestamp}; il timestamp generato dal server Bob non deve essere troppo diverso da quello di Alice

• un modo per sventare tale minaccia è memorizzare nel server Bob tutti i timestamp ricevuti e non ancora scaduti

– si ha un’altra potenziale debolezza se Alice usa lo stesso segreto KAlice-Bob con più server distinti

• un intercettatore che opera in modo veloce può ottenere la quantità KAlice-Bob{timestamp} trasmessa ad un server per impersonare Alice con un altro server

Prot. 3 vs Prot. 1

• tuttavia, tale minaccia è sventabile concatenando il nome del server con il timestamp

• anziché KAlice-Bob{timestamp} va inviato • KAlice-Bob{“Bob”||timestamp}

– il prot. 3 è vulnerabile ad eventuali modifiche all’orologio di sistema del server Bob • timestamp scaduti possono essere riusati

– se la sicurezza dipende dall’ora la configurazione dell’ora richiederà un handshake sicuro • un handshake basato sull’istante corrente potrebbe fallire se

i due orologi non sono sincronizzati • necessaria un’autenticazione basata su un handshake di

tipo challenge/response per la sincronizzazione degli orologi

Prot. 3 vs Prot. 1

– nel prot. 1, calcolare f(KAlice-Bob, R) voleva dire

• calcolare KAlice-Bob{R} oppure

• calcolare l’hash h(R||KAlice-Bob)

– ciò continua a valere nel caso del prot. 3, ma con piccole complicazioni aggiuntive se si usa l’hash

• Bob deve eseguire un certo numero di tentativi per verificare che h(timestamp||KAlice-Bob) sia stato generato da Alice,

• se si accettano 10 minuti di differenza tra i due orologi

• e il timestamp è espresso in minuti

• allora 20 tentativi sono sufficienti

• ma per timestamp in microsecondi sono necessari più di un miliardo di tentativi!

Protocollo 4

– assumendo che si voglia utilizzare un timestamp in microsecondi e

– una funzione di hash anziché una funzione crittografica invertibile

– una possibile soluzione è che Alice trasmetta anche il timestamp non cifrato

I’m Alice, timestamp, hash(KAlice-Bob, timestamp)

Alic

e

Bo

b

Bob autentica Alice calcolando l’hash di un timestamp ad alta risoluzione e sfruttando un segreto condiviso KAlice-Bob

Prot. 5 – Chiave pubblica unidirezionale

– Tutti i precedenti protocolli, a chiave segreta, consentono a Trudy di impersonare Alice se può leggere il database del server

– Utilizzando la tecnologia a chiave pubblica questa vulnerabilità può essere evitata

I’m Alice

[R]Alice

R

Alic

e

Bo

b

Bob autentica Alice verificando la sua firma digitale

Protocollo 5

– [R]Alice: R firmato da Alice; cioè cifrato con la sua chiave privata PRAlice

• Bob verifica la firma [R]Alice usando la chiave pubblica di Alice PUAlice

• ed accetta il login se il risultato è R

– il vantaggio di questo protocollo è che il database di Bob non è più vulnerabile agli accessi in lettura non autorizzati

– tuttavia, il database di Bob va comunque protetto da modifiche non autorizzate, ma non da accessi non autorizzati in lettura

• qualcuno potrebbe modificare la chiave pubblica di Alice!

Prot. 6 – Variante di Prot. 5

– Bob sceglie R e la cifra con PUAlice

– Alice dimostra di conoscere PRAlice decifrando {R}Alice e recuperando R

– un problema di questa variante è che molte tecnologie a chiave pubblica (si pensi a DSS) permettono solo di firmare e non di decifrare

I’m Alice

R

{R}Alice

Alic

e

Bo

b

Bob autentica Alice se lei può decifrare un messaggio cifrato con la sua chiave pubblica

Prot. 5 e 6 – Un serio problema

• In entrambi i protocolli 5 e 6 c’è un potenziale serio problema – il protocollo 5 permette di ingannare qualcuno a

firmare qualcosa • si supponga di avere una quantità Q che si desidera

venga firmata da Alice

• se si è in grado di impersonare l’indirizzo di rete di Bob

• si può attendere che Alice effettui il login

• e fornirle la quantità Q quale sfida da firmare

• Alice firmerà la sfida fornendo [Q]Alice all’attaccante


– similmente, il protocollo 6 permette ad un attaccante di decifrare un messaggio cifrato con PUAlice

• se un attaccante vuole decifrare {msg}Alice

• impersonando l’indirizzo di rete di Bob

• può attendere che Alice effettui il login

• e fornirle la quantità {msg}Alice quale sfida cifrata da decifrare

• così facendo, otterrà da Alice msg


• Come è possibile evitare tali attacchi?

• La regola generale è evitare di usare la stessa chiave per due scopi diversi

– a meno che i vari protocolli non siano coordinati in modo tale che un attaccante non possa mai usarne uno per violarne un altro

– un esempio di coordinamento è vincolare la struttura di R in base al tipo di applicazione

Sfide R strutturate

– ad esempio la struttura di R dovrebbe prevedere un campo type, da concatenare con il messaggio vero e proprio, che dipende dal tipo di protocollo/applicazione

• in questo modo il protocollo è incorporato nella firma

• quindi non è possibile “passare da un protocollo all’altro” senza violare il contenuto nel campo type

– nel caso di RSA, tali aspetti sono definiti nello standard PKCS

Osservazioni

• si noti pertanto che valgono le seguenti considerazioni

– è possibile progettare singoli protocolli sicuri,

– che complessivamente introducono delle vulnerabilità (prima assenti)

– è possibile progettare un nuovo protocollo sicuro il cui dispiegamento potrebbe compromettere la sicurezza degli schemi esistenti

PROTOCOLLI A SFIDA E RISPOSTA MUTUA AUTENTICAZIONE


Prot. 7 – Mutua autent. a chiave segreta

• Se si desidera autenticare reciprocamente ambo le parti • è sufficiente eseguire uno scambio di autenticazione in

entrambe le direzioni

f(KAlice-Bob, R1)

f(KAlice-Bob, R2)

R2

Alic

e

Bo

b

Mutua autenticazione basata su un segreto condiviso KAlice-Bob

R1

I’m Alice

Prot. 8 – Mutua autent. a chiave segreta

• Il protocollo 7 richiede lo scambio di cinque messaggi complessivi (poco efficiente)

• Sembra immediato poter ridurre a tre il numero di messaggi caricando in ogni messaggio più informazioni

I’m Alice, R2

f(KAlice-Bob, R1)

R1, f(KAlice-Bob, R2)

Alic

e

Bo

b

Mutua autenticazione ottimizzata basata su un segreto condiviso KAlice-Bob

Prot. 8 – Reflection Attack

• Il protocollo 8, più compatto del 7, è ora vulnerabile ad un attacco di tipo reflection – si supponga che Trudy voglia impersonare Alice

– Trudy inizia il protocollo 8,

– ma quando riceve la sfida di Bob non può proseguire; non potendo cifrare R1

I’m Alice, R2

R1, f(KAlice-Bob, R2) Tru

dy

Bo

b

Inizio dell’attacco reflection (sessione 1)

Prot. 8 – Reflection Attack

– tuttavia, Trudy può interrompere temporaneamente le sessione corrente

– e può iniziarne una nuova usando R1 quale sfida per Bob

– Trudy non può completare la seconda sessione; non può cifrare R3

– ma ora conosce f(KAlice-Bob, R1) e può completare la prima sessione rimasta appesa

I’m Alice, R1

R3, f(KAlice-Bob, R1) Tru

dy

Bo

b

Seconda sessione nell’attacco reflection

Attacco di tipo reflection

Trudy (sessione 1) Bob

Trudy (sessione 2)

Sull’attacco di tipo reflection

• Un attacco di tipo reflection è facile da sferrare se – è possibile aprire simultaneamente più connessioni con lo

stesso server – ci sono più server che condividono uno stesso segreto con

Alice

• Tale attacco può essere sventato con un po’ di attenzione e comprendendo bene la debolezza che sfrutta

• ovvero che Alice e Bob sono perfettamente interscambiabili – la risposta ad una stessa sfida è identica

Protezioni per attacchi di tipo reflection

• L’idea è quella di differenziare, in qualche modo, la risposta di Alice e quella di Bob ad una stessa sfida; seguono alcune possibili soluzioni

– Usare chiavi differenti

• una possibilità è che Alice e Bob condividano due chiavi completamente differenti KAAB e KABB; Alice cifra con KAAB, mentre Bob cifra con KABB

• in alternativa, una delle chiavi può essere derivata dall’altra:

• KABB = -KAAB oppure KABB = KAAB + 1 oppure

• KABB = KAAB F0F0F0F0F0F0F0F016

Protezioni per attacchi di tipo reflection

– Usare sfide strutturalmente differenti, garantire che la sfida dell’iniziatore abbia una struttura diversa da quella di chi risponde

• ad esempio, l’iniziatore (Alice) potrebbe usare un numero dispari mentre il risponditore un numero pari

– Usare risposte dipendenti dal risponditore la risposta non consiste nella cifratura della sola sfida, ma viene aggiunta un’informazione associata in modo univoco al risponditore

• ad esempio, la risposta ad una sfida R non è semplicemente f(K, R) ma f(K, R||”nome-id-risponditore”)

Domanda

• Il protocollo 7 è vulnerabile ad un attacco di tipo reflection? Per quale ragione?

• La risposta è NO

– tale protocollo segue infatti un altro importante principi generale:

– idealmente, l’iniziatore dovrebbe essere il primo a provare la sua identità

Altra vulnerabilità del Prot. 8

• assumendo che il segreto condiviso KAlice-Bob sia derivato da una password

– Trudy può eseguire un attacco off-line sulla password senza dover intercettare alcuna comunicazione tra Alice e Bob (tale vulnerabilità non esiste nel protocollo 7)

• Trudy deve solo inviare un messaggio a Bob affermando di essere Alice e includere un numero R da cifrare (attacco di tipo testo in chiaro selezionato)

• ottenendo pertanto la coppia R, f(KAlice-Bob, R) che può essere utilizzata per indovinare la password

Prot. 9

– aggiungendo un messaggio al protocollo 8 è possibile renderlo molto più robusto ad attacchi off-line sulla password

• il nuovo protocollo è chiaramente meno efficiente

I’m Alice

f(KAlice-Bob, R2)

f(KAlice-Bob, R1), R2 Alic

e

Bo

b

Mutua autenticazione parzialmente ottimizzata basata su un segreto condiviso KAlice-Bob

R1

Prot. 9

• ora Trudy non può più effettuare un attacco off-line sulla password semplicemente spacciandosi per Alice, senza dover intercettare i messaggi

– tuttavia, impersonando l’indirizzo di Bob può tentare di ingannare Alice facendogli stabilire una connessione con lei

– tale vulnerabilità non va ignorata, ma è comunque molto più difficile da sfruttare per un attaccante

Prot. 10 – Mutua autent. a chiave pubblica

• Assumendo che Alice e Bob conoscano ognuno la chiave pubblica dell’altro

• Utilizzando la tecnologia a chiave pubblica, possono autenticarsi reciprocamente scambiandosi tre messaggi

I’m Alice, {R2}Bob

R1

R2, {R1}Alice

Alic

e

Bo

b

Mutua autenticazione a chiave pubblica (basata sulla cifratura/decifratura)

Prot. 11 – Mutua autent. a chiave pubblica

• Una variante del protocollo 10 e che fa uso della firma digitale è la seguente

I’m Alice, R2

[R1]Alice

R1, [R2]Bob

Alic

e

Bo

b

Mutua autenticazione a chiave pubblica (basata sulla firma digitale)

Prot. 9 e 10 – Alcuni problemi

• supponendo che Alice sia una persona (o una workstation)

– Alice non può ricordare la chiave pubblica di Bob PUBob

• (nel caso della workstation, quest’ultima potrebbe non avere in memoria PUBob )

– (a) Come fa Alice ad ottenere PUBob?

• una possibilità è che Bob stesso invii PUBob ad Alice

• ciò non sarebbe però sicuro se Bob venisse impersonato da Trudy


• si assuma che Alice sia un utente umano collegato ad una workstation

– (b) un altro problema è il recupero della chiave privata di Alice PRAlice considerando che Alice può, al massimo, ricordare una password • convertire una password in una chiave segreta è fattibile in

modo efficiente

• convertire invece una password in una coppia PU, PR non è altrettanto semplice

– la soluzione generalmente adottata per il problema b) consiste nel recuperare PRAlice da un servizio di directory o, in alcuni casi, da Bob stesso


– ovviamente, PRAlice non è memorizzata in chiaro, ma è cifrata con una chiave segreta derivata dalla password di Alice

– a questo punto, anche il problema a) può risolversi allo stesso modo

• memorizzando PUBob in un servizio di directory oppure presso Bob stesso

– a tale scopo esistono due possibili modi

• 1) memorizzare PUBob cifrato con la chiave segreta di Alice derivata dalla sua password


• per ingannare Alice, un impostore, impersonando Bob, dovrebbe saper cifrare una chiave pubblica falsa (di cui conosce la chiave privata) con la chiave segreta di Alice

• 2) memorizzare un certificato per la chiave pubblica di Bob firmato con la chiave privata di Alice

• una volta che la workstation recupera PRAlice, può verificare la validità del certificato per PUBob

Prot. 11 – Mutua autent. con timestamp

– Utilizzando dei timestamp, anziché sfide random, è possibile ottenere un protocollo di mutua autenticazione di due soli messaggi • tale soluzione è molto utile, può essere facilmente

aggiunta ai protocolli a richiesta/risposta (HTTP)

• senza dover aggiungere un ulteriore messaggio

I’m Alice, f(KAlice-Bob, timestamp)

f(KAlice-Bob, timestamp + 1) Alic

e

Bo

b

Mutua autenticazione basata sulla sincronizzazione degli orologi e su un segreto condiviso KAlice-Bob


– per evitare che Trudy possa impersonare Bob riusando f(KAlice-Bob, timestamp) • copia la quantità crittografica di Alice e gliela

restituisce!

– nella risposta viene richiesto un timestamp diverso, cioè timestamp + 1

– ovviamente, sono possibili altre soluzioni • usare chiavi diverse per cifrare il timestamp

• concatenare il proprio nome al timestamp prima di applicare f( )

• o in generale, rendere la risposta dell’iniziatore e del risponditore non interscambiabili


• chiaramente, tutte le questioni viste nel caso unidirezionale e riguardanti gli orologi continuano ad essere valide

– l’idea di usare timestamp + 1 è stata introdotta nel protocollo Needham-Schroeder e ripresa in Kerberos V4

– non si tratta però della scelta migliore

• Trudy intercettando la risposta di Bob potrebbe riusarla per impersonare subito dopo Alice

• Bob potrebbe mantenere in cache tutte le coppie timestamp, timestamp + 1 incontrate, ma tale soluzione non è elegante

Prot. 11’ – Mutua autent. con timestamp

• se esistono più repliche di Bob aventi la stessa chiave, sarebbe necessario sincronizzare le loro cache oppure concatenare il timestamp con un identificatore univoco di ogni replica

• una scelta migliore potrebbe essere concatenare al timestamp un flag che specifica se il messaggio è inviato dall’iniziatore o dal risponditore

I’m Alice, f(KAlice-Bob, “S”||timestamp)

f(KAlice-Bob, “R”||timestamp) Alic

e

Bo

b

Mutua autenticazione basata sulla sincronizzazione degli orologi e su un segreto condiviso KAlice-Bob

CIFRATURA/INTEGRITÀ DEI DATI Autenticazione Crittografica – Protocolli e Insidie

Cifratura/Integrità dei dati

– Al fine di fornire protezione dell’integrità e della confidenzialità dei dati da trasmettere dopo lo scambio di autenticazione

– Alice e Bob devono necessariamente usare la crittografia (a chiave segreta) per cifrare e/o aggiungere dei controlli di integrità crittografici

– L’esecuzione di tali operazioni richiede preliminarmente che le parti stabiliscano una chiave segreta di sessione (session key) • anche se già condividono dei segreti a lungo termine che

permetterebbero di cifrare o di eseguire dei controlli di integrità


– Tipicamente, una chiave di sessione viene stabilita modificando lo scambio di autenticazione in modo tale che terminato l’handshake le due parti condividano una chiave segreta

– Esamineremo come procedere in relazione ai seguenti scambi di autenticazione • Chiave segreta: Alice e Bob condividono una chiave segreta

KAlice-Bob (che non è la chiave di sessione)

• Chiave pubblica: Alice e Bob conoscono ciascuno la chiave pubblica dell’altro e chiaramente la propria chiave privata

• Chiave pubblica unidirezionale: soltanto una parte ha una coppia PU, PR; l’autenticazione è unidirezionale


– ovviamente, un intercettatore non deve essere in grado di ottenere la chiave di sessione

– una volta illustrato come ottenere una chiave di sessione

• per ciascuno degli scenari precedenti

– si illustrerà come utilizzarla per cifrare e/o aggiungere dei controlli di integrità crittografici

Autenticazione a chiave segreta

– KAlice-Bob: segreto a lungo termine condiviso tra Alice e Bob

– si consideri lo schema di autenticazione riportato sotto, anche se quanto detto potrà applicarsi al caso di • mutua autenticazione; anziché R ci saranno R1 e R2

• autenticazione mediante timestamp anziché sfide random R

– in ogni caso, c’è sufficiente informazione per stabilire una chiave di sessione condivisa

I’m Alice

KAlice-Bob{R}

R

Alic

e

Bo

b

Autenticazione con chiave segreta KAlice-Bob


– una possibile chiave di sessione è Ks = (KAlice-Bob + 1){R}

– in generale, una chiave di sessione può ottenersi

• modificando KAlice-Bob in qualche modo; Kmodified = f(KAlice-Bob)

• e cifrando la sfida R con la chiave modificata

– il risultato è la chiave di sessione Ks

Ks = Kmodified{R} = (f(KAlice-Bob)){R}

I’m Alice

KAlice-Bob{R}

R

Alic

e

Bo

b

Autenticazione con chiave segreta KAlice-Bob


• Domanda

– Perché è necessario modificare KAlice-Bob?

– Perché non è possibile usare KAlice-Bob{R} come chiave di sessione?

• Risposta

– KAlice-Bob{R} non può utilizzarsi perché è trasmessa da Alice nel terzo messaggio dell’handshake!


• Domanda

– KAlice-Bob{R+1} può andare bene?

• Risposta

– Tale chiave di sessione non è sicura per una ragione molto sottile

• si supponga che Alice e Bob abbiano iniziato una conversazione e Bob abbia inviato R come sfida

• Trudy potrebbe aver registrato l’intera conversazione, cifrata con Ks = KAlice-Bob{R+1}


• in seguito, Trudy potrebbe impersonare l’indirizzo di rete di Bob in una successiva comunicazione con Alice

• e dichiarandosi Bob, potrebbe inviare R+1 come sfida

• alla quale Alice risponderebbe con KAlice-Bob{R+1}

• Trudy sarebbe in grado di decifrare la precedente conversazione (registrata) tra Alice e Bob

I’m Alice

KAlice-Bob{R+1}

R+1

Alic

e

Tru

dy

as B

ob

Trudy impersona Bob


– in definitiva, Alice e Bob, dopo lo scambio di autenticazione, conoscono oltre KAlice-Bob anche R • molte combinazioni di tali quantità permettono di

ottenere una chiave di sessione sicura,

• ma ci sono anche combinazioni non accettabili

– si noti che una buona chiave di sessione deve • variare da sessione a sessione

• non essere indovinabile da un intercettatore

• e non deve ottenersi cifrando con KAlice-Bob una quantità X, dove X è un valore che può essere predetto o estratto da un intruso (come ad esempio X = R + 1)

Autent. a chiave pubblica bidirezionale

– nel caso di autenticazione a chiave pubblica bidirezionale • Alice e Bob conoscono la propria chiave privata e la chiave

pubblica dell’altro

– per definire una chiave (segreta) di sessione condivisa Ks esistono varie possibilità


R1, {R}Bob

R2, {R1}Alice

Alic

e

Bo

b

Ks = R

(1) Ks = R – Alice invia {R}Bob

– una parte, diciamo Alice,

• sceglie un numero random R; che sarebbe la chiave di sessione

• lo cifra con la chiave pubblica di Bob

• ed invia a Bob {R}Bob

– questo schema presenta la seguente vulnerabilità

• un intruso, Trudy, può dirottare la conversazione scegliendo un suo R, cifrandolo con la chiave pubblica di Bob

• e inviando il risultato a Bob al posto della chiave cifrata fornita da Alice

• contestualmente dovrebbe impersonare l’indirizzo di rete di Alice

(2) Ks = R – Alice invia [{R}Bob]Alice

– rispetto a prima Alice firma la quantità {R}Bob

– e invia a Bob [{R}Bob]Alice

– Bob verifica prima la firma di Alice usando PUAlice

– e poi decifra con la propria chiave privata {R}Bob riottenendo R


R1, [{R}Bob]Alice

R2, {R1}Alice

Alic

e

Bo

b

Ks = R


– l’attacco precedente di Trudy

• scegliere un proprio R, in luogo di quello di Alice, e inviarlo a Bob crittografato

– ora non può funzionare perché Trudy non è in grado di forgiare la firma di Alice

– tuttavia, se si vuole essere paranoici, c’è ancora una “piccola” vulnerabilità

• che può essere ridotta parzialmente (vedi caso (3)) o del tutto (vedi caso (4))


– la vulnerabilità è la seguente:

• si supponga che Trudy registri una intera conversazione tra Alice e Bob; inclusi i dati cifrati con la chiave di sessione

• si supponga inoltre che “successivamente” (dopo un minuto/giorno/mese) Trudy riesca a violare il server Bob e ad ottenere tutti i suoi segreti; quindi anche PRBob

• ottenendo PRBob Trudy può recuperare la chiave di sessione dalle informazioni trasmesse, in particolare da [{R}Bob]Alice può ottenere Ks = R


– quindi Trudy può decifrare la conversazione cifrata tra Alice e Bob, precedentemente registrata

– in altri termini la soluzione (2) permette di sferrare degli attacchi alla confidenzialità “retroattivi” se nel futuro un avversario riuscisse a violare Bob

(3) Ks = R P – R e P non inviate in chiaro

• similmente a (2),

– Alice genera una quantità random R – e invia {R}Bob a Bob – Bob genera una quantità random P – e invia {P}Alice a Alice – terminata la conversazione Alice e Bob

dimenticheranno R e P


R1, {R}Bob

R2, {R1}Alice, {P}Alice

Alic

e

Bo

b

Ks = R P

genera R

genera P

(3) Ks = R P – R e P non inviate in chiaro

– definendo Ks = R P, per ottenere la chiave di sessione Trudy deve • registrare lo scambio tra Alice e Bob,

• violare Bob per ottenere PRBob e quindi R

• ma anche violare Alice per ottenere PRAlice e quindi P

– per ottenere Ks Trudy dovrebbe violare entrambi


R1, {R}Bob

R2, {R1}Alice, {P}Alice

Alic

e

Bo

b

Ks = R P

genera R

genera P

(3) vs (2)

• Domanda

– nel caso (2) Alice deve firmare la sua quantità (Alice invia [{R}Bob]Alice) invece di inviare direttamente {R}Bob

– Perché nel caso (3) ciò non è necessario?

(3) vs (2)

• Risposta – Alice e Bob non hanno bisogno di firmare le quantità

da loro inviate poiché,

– anche se Trudy riesce a sostituire {R}Bob con una quantità a lei nota {R’}Bob

– non sarebbe comunque in grado di ottenere la chiave di sessione che vedrebbe Bob, cioè Ks’ = R’ P • per ottenere P Trudy dovrebbe decifrare {P}Alice

– al massimo, Trudy può impedire che Alice e Bob dialoghino (attacco DoS), ma non può ottenere il testo in chiaro di una loro conversazione

(4) Usare Diffie-Hellman

– Alice e Bob possono effettuare uno scambio Diffie-Hellman autenticato (già esaminato)

– dove ognuno firma la quantità da inviare all’altro

– si supponga che le quantità g e p siano pubbliche

I’m Alice, [TA]Alice

[TB]Bob Alic

e

Bo

b

Ks = KAB = TBsA mod p = TA

sB mod p = KBA

genera sA

TA = gsA mod p genera sB

TB = gsB mod p

(4) Usare Diffie-Hellman

• Usando Diffie-Hellman autenticato,

• anche se Trudy riesce a violare sia Alice che Bob,

• non potrà comunque essere in grado di decifrare delle conversazioni registrate

• perché non è in grado di dedurre né SA né SB

Autent. a chiave pubblica unidirezionale

– In alcuni casi solo una delle parti ha una coppia chiave-pubblica, chiave-privata • spesso, come nel caso di SSL, si assume che i server abbiano

le chiavi pubbliche certificate, e i client non si preoccupano di ottenere chiavi e certificati

– pertanto, l’autenticazione crittografica è unidirezionale

– il protocollo assicura il client (Alice) che sta contattando il server Bob giusto,

– ma terminato la scambio di autenticazione, che permette tra l’altro di definire una chiave di sessione,

– il server non ha ancora autenticato il client

Autent. a chiave pubblica unidirezionale

– il client Alice si autentica dopo lo scambio di autenticazione

– inviando username e password, cifrati con la chiave di sessione Ks

– nelle slide successive sono illustrati due possibili, (a) e (b), modi per stabilire una chiave di sessione condivisa Ks

– durante lo scambio di autenticazione a chiave pubblica unidirezionale

(a) Ks = R – Alice invia {R}Bob

– Alice, sceglie un numero random R, lo cifra con la chiave pubblica di Bob ed invia {R}Bob

– tale schema presenta le debolezze viste nel caso (1)

• Trudy può registrare una intera conversazione e decifrarla se riesce in futuro a violare Bob

• Trudy può sostituire un suo {R}Bob e dirottare la conversazione seguente; tale debolezza è meno critica in un contesto dove non è necessaria una mutua autenticazione

I’m Alice, {RA}Bob, {R}Bob

RA Alic

e

Bo

b

Ks = R

(b) Usare Diffie-Hellman

– Bob e Alice possono effettuare uno scambio Diffie-Hellman

– dove Bob firma la sua quantità TB

• Alice non può firmare nulla non disponendo di una coppia PU, PR

– il caso (b) rispetto al caso (a) è un po’ più sicuro

– Trudy non può ottenere la chiave di sessione Ks usata in una precedente conversazione neanche violando Bob

• si assuma che Bob dimentichi Ks non appena la conversazione con Alice termina

I’m Alice, TA

[TB]Bob Alic

e

Bo

b

Ks = KAB = TBsA mod p = TA

sB mod p = KBA

genera sA

TA = gsA mod p genera sB

TB = gsB mod p

Bob non autentica Alice, ma …

• Si noti che nessuno degli schemi (a) e (b) assicura a Bob di comunicare con la vera Alice

• ma in entrambi i casi Bob è sicuro che l’intera conversazione è con una singola persona

Confidenzialità e Integrità(Autenticità)

– Tipicamente, la conversazione che segue lo scambio di autenticazione viene cifrata con la chiave di sessione per proteggere la confidenzialità

– inoltre viene applicato un controllo di integrità ai vari messaggi trasmessi (MIC o MAC) • ottenuto con tecniche crittografiche a chiave segreta oppure

sfruttando degli algoritmi di digest

– si è visto che non esiste un algoritmo standard per proteggere contemporaneamente confidenzialità e integrità

– disponendo di una sola chiave (la chiave di sessione Ks)

– ed effettuando una singola operazione crittografica


• pertanto si applicano alcune delle seguenti soluzioni che proteggono confidenzialità ed integrità in due fasi

– i) stabilire due chiavi di sessione nello scambio di autenticazione Ksc e Ksi

• Ksc: chiave di sessione per la confidenzialità

• Ksi: chiave i sessione per l’integrità

– ii) derivare una chiave dall’altra, cambiando alcuni bit in modo deterministico Ksi = f(Ksc)

– iii) una sola chiave Ks, ma algoritmi crittografici distinti

• ad esempio, confidenzialità tramite AES/CBC

• integrità tramite HMAC


– iv) includere un checksum debole per l’integrità all’interno di un algoritmo robusto per la protezione della confidenzialità

– una volta stabilità una (o più) chiave di sessione la conversazione, generalmente, consiste nello scambio di messaggi singolarmente cifrati e dei relativi MAC

– ogni volta che una parte riceve un messaggio lo decifra ed esegue il controllo di autenticità

– poi, eventualmente, può proseguire la conversazione

Attacchi all’integrità

– manca un controllo sull’ordine dei messaggi scambiati; sono possibili pertanto attacchi all’integrità di tipo “replay”

• un attaccante potrebbe registrare un messaggio (e il relativo MAC) e poi effettuarne il replay in un secondo momento; ciò non sarebbe rilevabile

– ovviamente, ciò può evitarsi includendo in ogni messaggio un numero di sequenza

• tale soluzione è adottata in entrambe le versioni di Kerberos


– in alternativa, si può far dipendere il MIC (MAC) di un messaggio m, oltre che da m stesso, anche da tutti i precedenti messaggi scambiati • se mi = mj ciò non implica che MAC(mi) = MAC(mj)

– un’altra forma di attacco all’integrità e la reflection • un attaccante registra un messaggio avente una data

direzione (da Bob a Alice) ed

• effettua il replay nell’altro senso (da Alice a Bob)

• se lo stesso numero di sequenza è valido in entrambe le direzioni

• tale attacco all’integrità non viene rilevato


– l’attacco all’integrità di tipo reflection può evitarsi

• usando, per ciascuna direzione, dei range diversi per i numeri di sequenza

• oppure inserendo un flag che definisce la direzione

• o differenziando in modo minimo l’algoritmo per il calcolo dl MAC per le due direzioni

Numeri di sequenza e Key Rollover

– Una conversazione potrebbe esaurire tutti i numeri di sequenza; a meno che quest’ultimi possano assumere valori enormi

– Si noti che, il riuso di precedenti numeri di sequenza, espone (almeno teoricamente) ad attacchi all’integrità di tipo reply

– Una possibile soluzione è il key rollover, cioè la rinegoziazione della chiave di sessione • ciò ha anche il vantaggio di limitare il materiale che un

crittoanalista potrebbe raccogliere

Key Rollover

– Il modo più semplice per rinegoziare la chiave è il seguente • una della due parti sceglie una chiave random Ks’

• la cifra con la vecchia chiave Ks

• e invia all’altra parte Ks{Ks’}

– tale soluzione è un po’ debole; se un crittoanalista fosse riuscito ad ottenere Ks otterrebbe anche Ks’ • il vantaggio di cambiare chiave si attenua

– conviene pertanto o ripetere lo scambio di autenticazione

– oppure utilizzare Diffie-Hellman

– il rollover della chiave permette, tra l’altro, di scegliere la vecchia chiave per l’integrità e la nuova per la confidenzialità

AUTENTICAZIONE MEDIATA (CON KDC)


KDC – alcuni richiami

– Si è già visto che un KDC ha un database con le chiavi di tutti gli utenti a lui afferenti

– ogni utente Alice registrato presso il KDC può comunicare in modo sicuro con il KDC • Alice e il KDC possono autenticarsi reciprocamente e

• proteggere la confidenzialità di ogni loro conversazione

• poiché entrambi conoscono la chiave segreta di Alice KAlice

– il KDC entra in gioco quando un utente Alice, desidera ottenere una chiave segreta KAB da condividere con un altro utente Bob del KDC

– non potendo Alice e Bob comunicare direttamente il KDC funge da mediatore

Mediazione del KDC – idea base

– Lo scambio riportato sotto illustra in modo esemplificato il ruolo di mediazione del KDC • il KDC non sa se è realmente Alice l’utente che ha chiesto di

comunicare con Bob

• Trudy potrebbe spacciarsi per Alice, ma poi non riuscirebbe ad ottenere KAB; non è in grado di decifrare il messaggio KAlice{use KAB for Bob}

Alice wants Bob

KAlice{use KAB for Bob} Alic

e

Bo

b

KBob{use KAB for Alice} KD

C

invents key KAB

Operazioni svolte dal KDC (in linea di principio)

Mediazione del KDC – in pratica

• Trudy al massimo può indurre il KDC ad inviare ad Alice un messaggio da lei non richiesto

– le uniche parti che conoscono KAB dopo questo scambio sono Alice, Bob e il KDC

– pertanto, dopo lo scambio Alice e Bob possono autenticarsi reciprocamente utilizzando il segreto condiviso KAB

– il protocollo precedente però non è quello utilizzato nella pratica • se Alice invia immediatamente un messaggio a Bob

• per i ritardi nella rete, è possibile che questi arrivi prima del messaggio che il KDC ha inviato a Bob


• inoltre, il fatto che un utente qualsiasi, senza autenticarsi presso il KDC, possa indurre quest’ultimo ad aprire connessioni verso un suo qualsiasi utente comporta una serie di pericoli che dovrebbero essere gestiti

– siccome è Alice che desidera comunicare con Bob

– la cosa più ragionevole, è che il KDC fornisca ad Alice tutte le informazioni che egli avrebbe fornito a Bob per instaurare una connessione sicura con Alice

– nel protocollo Kerberos, l’informazione cifrata che il KDC invia ad Alice da passare a Bob è chiamata ticket

• il cosiddetto ticket per Bob

Prot. 12 Mediazione del KDC – in pratica

– nella pratica la mediazione del KDC avviene in modo simile a come illustrato sotto

– naturalmente, Alice e Bob devono poi autenticarsi reciprocamente con una delle tecniche esaminate prima • ciascuno deve dimostrare all’altro di conoscere realmente KAB

KAlice{use KAB for Bob} ticket to Bob = KBob{use KAB for Alice}

Alice wants Bob

Alic

e

Bo

b K

DC

invents key KAB

“I’m Alice”, ticket to Bob = KBob{use KAB for Alice}

Operazioni svolte dal KDC (nella pratica)


– rimangono comunque delle vulnerabilità molto sottili

– che hanno giustificato l’introduzione di molti protocolli

– alcuni dei quali si esamineremo nel seguito

– come il protocollo di Needham-Schroeder

Protocollo di Needham-Schroeder (N-S)

– Tale protocollo ha la stessa struttura portante di quello esaminato prima, ma in aggiunta

• aggiunge uno scambio per autenticare reciprocamente Alice e Bob e

• rimuove alcune sottili debolezze che ora saranno illustrate

– Il protocollo di Needham-Schroeder [NEED78] è importante perché è un classico protocollo di autenticazione mediata da un KDC e

– a lui si sono ispirati molti protocolli moderni, incluso Kerberos

– per una sua comprensione, al solito, è necessario analizzarlo in modo “viscerale”

Protocollo N-S – terminologia

– Il termine nonce sta per “number that is used only once” cioè numero che è usato soltanto una volta

– Un nounce potrebbe essere

• un numero di sequenza (ammesso che non vi sia perdita di stato durante i crash)

• un numero random molto grande (la probabilità di una ripetizione è prossima a zero)

– in teoria potrebbe essere anche un timestamp

• se gli orologi degli apparati hardware non vanno mai indietro

• si noti tuttavia che Needham e Schroeder vollero evitare in modo esplicito ogni tipo di dipendenza da timestamp

Prot. 12 Prot. N-S – 1^a vuln.

– Il Prot. 12 presenta la seguente vulnerabilità • anche se in pratica è improbabile che possa essere sfruttata da un

attaccante

– si supponga che Trudy abbia rubato una vecchia chiave di Bob K’Bob

• Bob scoprendolo potrebbe già aver provveduto a cambiarla

– e che abbia anche rubato un vecchio messaggio di risposta del KDC ad Alice • quando la chiave di Bob era ancora K’Bob

– Trudy attende che Alice richieda al KDC di parlare con Bob

– poi sostituisce la risposta del KDC con quella vecchia in suo possesso, che appare ad Alice come una risposta ordinaria


– Trudy può pertanto impersonare Bob

• riesce a decifrare il ticket e ad ottenere la chiave di sessione

– questa vulnerabilità, prevalentemente teorica, può essere rimossa non permettendo a Trudy di riusare (reply) vecchie risposte del KDC

– ad esempio aggiungendo un nounce N1 alla richiesta iniziale di Alice

– e chiedendo al KDC di cifrarlo insieme alla chiave KAB


– segue sotto il Prot. 12.1 ottenuto rimuovendo la vulnerabilità appena illustrata

KAlice{N1, KAB} ticket to Bob = KBob{KAB}

N1, Alice wants Bob

Alic

e

Bo

b K

DC

invents key KAB

“I’m Alice”, ticket to Bob

Protocollo 12.1


– Nel Prot. 12.1 sussiste ancora la seguente vulnerabilità

– si supponga che Trudy, utente del KDC, riesca a modificare la richiesta di Alice, sostituendo “Bob” con “Trudy”

– il KDC restituirebbe ad Alice una chiave condivisa con Trudy e non con Bob; cioè KAT e non KAB

– tuttavia, dalle informazioni ricevute Alice non può rendersi conto di tale attacco; cioè Alice è convinta di aver ricevuto KAB

– quindi Trudy potrebbe impersonare Bob senza che Alice se ne accorga


– il precedente attacco è sventabile aggiungendo alle informazioni che il KDC deve inviare ad Alice (cifrate con KAlice)

– il destinatario della richiesta di connessione che ha ricevuto il KDC

• in tal modo Alice può verificare se coincide con quello presente nella sua richiesta

– inoltre il KDC può aggiungere il nome dell’utente che ha effettuato la richiesta tra le informazioni che costituiscono il ticket per Bob

• il motivo di tale scelta sarà chiaro più tardi


– implementando le precedenti modifiche si ottiene il Prot. 12.2

KAlice{N1, “Bob”, KAB} ticket to Bob = KBob{KAB, “Alice”}

N1, Alice wants Bob

Alic

e

Bo

b K

DC

invents key KAB

“I’m Alice”, ticket to Bob

Protocollo 12.2


– Il Prot. 12.2 analogamente ai precedenti non include uno scambio che permetta di autenticare reciprocamente Alice e Bob

– per l’autenticazione reciproca ciascuno deve provare all’altro di conoscere KAB

• Alice sa che soltanto chi conosce KBob può decifrare il ticket per Bob e quindi riottenere KAB

• Bob decifrando il ticket, oltre a KAB, ottiene “Alice” e sa pertanto che il KDC è stato contattato da Alice e che solo lei, Alice e il KDC conoscono KAB

• (ciò spiega una delle modifiche inserite nel protocollo 12.2)


– Alice e Bob possono autenticarsi reciprocamente nel seguente modo

• Alice, insieme al ticket invia a Bob una sfida (N2) cifrata con la chiave KAB

• Bob decifra il ticket e ottiene KAB, quindi usa KAB per estrarre N2

• poi invia ad Alice KAB{N2 – 1, N3}, N2 – 1 serve a provare ad Alice che conosce KAB

• N3 è invece la sfida per Alice

• infine, Alice dimostra a Bob di conoscere KAB rispondendo alla sua sfida con KAB{N3}


– Il Prot. 12.3 include anche lo scambio per autenticare reciprocamente Alice e Bob

KAlice{N1, “Bob”, KAB} ticket to Bob = KBob{KAB, “Alice”}

N1, Alice wants Bob

Alic

e

Bo

b

KD

C

invents key KAB

“I’m Alice” ticket to Bob, KAB{N2}

Protocollo 12.3

KAB{N2 – 1, N3}

KAB{N3 – 1}

Protocollo di Needham-Schroeder

– Il protocollo di Needham-Schroeder in pratica concide con il Prot. 12.3

• tranne per il fatto che il KDC include il ticket per Bob tra le informazioni da cifrare con KAlice

• si osservi che ciò non migliora la sicurezza in quanto il ticket per Bob è qualcosa di indecifrabile per Alice

• tale ulteriore cifratura poteva pertanto omettersi

Protocollo di Needham-Schroeder

KAlice{N1, “Bob”, KAB, ticket to Bob} where ticket to Bob = KBob{KAB, “Alice”}

N1, Alice wants Bob

Alic

e

Bo

b

KD

C

invents key KAB

ticket, KAB{N2}

Needham-Schroeder

KAB{N2 – 1, N3}

KAB{N3 – 1}

m1

m3

m4

m5

m2

Bibliografia

• [DES81] DES Modes of Operation, FIPS PUB 81, National Bureau of Standards, U.S. Department of Commerce, 1981.

• [KPS02] C. Kaufman, R. Perlman, M. Speciner. Network Security – Private Communication in a Public World. Prentice Hall.

• [NEED78] R. M. Needham, M. D. Schroeder. Using Encryption for Authentication in Large Networks of Computers. Communications of the ACM, Vol. 21, December 1978, pp. 993-999.

• [PFL08] C. P. Pfleeger, S. L. Pfleeger. Sicurezza in Informatica. Pearson, Prentice Hall.

• [STA07] W. Stallings. Sicurezza delle reti. Pearson, Prentice Hall.

• [Wiki-it] http://it.wikipedia.org/wiki/

• [Wiki-en] http://en.wikipedia.org/wiki/

• [ISECOM] Institute for Security and Open Methodologies

D10 Autenticazione Crittografica Protocolli e Insidie

Documents

Transcript of D10 Autenticazione Crittografica Protocolli e Insidie