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

Lautenticazione 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 allambiente in cui il protocollo viene usato

Propriet di un protocollo
Oltre alla sicurezza sono importanti anche le prestazioni, ovvero lefficienza del protocollo Lefficienza 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 allambiente 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 dimpiego 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 (liniziatore) 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

Autenticazione Crittografica Protocolli e Insidie

PROTOCOLLI A SFIDA E RISPOSTA UNIDIREZIONALI (LOGIN ONLY)

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

Im Alice Alice Bob

a challenge R
f(KAlice-Bob, R)

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 allindirizzo di rete di Bob, e rispondere con lindirizzo 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

Prot. 1 Debolezze
Se questo lintero 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 lindirizzo di Alice (IP spoofing) potrebbe anche essere utile, ma non essenziale, per Trudy, poter ricevere pacchetti indirizzati ad Alice

Prot. 1 Debolezze
Se il segreto condiviso KAlice-Bob fosse derivato da una password,
allora conoscendo R, f(KAlice-Bob, R) e lalgoritmo per ottenere la chiave dalla password, un intercettatore potrebbe sferrare un attacco offline 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

Prot. 1 Debolezze
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 laccesso 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 unalternativa 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 Im Alice Alice Bob

KAlice-Bob{R}
R

Bob autentica Alice sfruttando una chiave segreta condiviso KAlice-Bob

Prot. 2 vs Prot. 1
Prot. 2 richiede luso 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 unaltra variante del protocollo 1
utilizzando un timestamp invece di una sfida random R sufficiente un solo messaggio per lhandshake Alice cifra listante 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

Alice

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

Bob

Im Alice, KAlice-Bob{timestamp}

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 lHTTP) ottenendo unautenticazione 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 unaltra 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 allorologio di sistema del server Bob

timestamp scaduti possono essere riusati

se la sicurezza dipende dallora la configurazione dellora richieder un handshake sicuro

un handshake basato sullistante corrente potrebbe fallire se i due orologi non sono sincronizzati necessaria unautenticazione 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 lhash h(R||KAlice-Bob)

ci continua a valere nel caso del prot. 3, ma con piccole complicazioni aggiuntive se si usa lhash
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
Alice
Im Alice, timestamp, hash(KAlice-Bob, timestamp)

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

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
Im Alice Alice Bob

R
[R]Alice

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
Im Alice Alice Bob

{R}Alice
R

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 lindirizzo 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 allattaccante

Prot. 5 e 6 Un serio problema

similmente, il protocollo 6 permette ad un attaccante di decifrare un messaggio cifrato con PUAlice
se un attaccante vuole decifrare {msg}Alice impersonando lindirizzo 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

Prot. 5 e 6 Un serio problema

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 allaltro 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

Autenticazione Crittografica Protocolli e Insidie

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
Im Alice
R1

Alice

R2 f(KAlice-Bob, R2)

Mutua autenticazione basata su un segreto condiviso KAlice-Bob

Bob

f(KAlice-Bob, R1)

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
Im Alice, R2 Alice Bob

R1, f(KAlice-Bob, R2)

f(KAlice-Bob, R1) 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
Im Alice, R2 R1, f(KAlice-Bob, R2) Inizio dellattacco reflection (sessione 1) Bob

Trudy

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
Im Alice, R1 R3, f(KAlice-Bob, R1) Seconda sessione nellattacco reflection Bob

Trudy

Attacco di tipo reflection

Trudy (sessione 1) Bob

Trudy (sessione 2)

Sullattacco 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

Lidea 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 dallaltra: KABB = -KAAB oppure KABB = KAAB + 1 oppure KABB = KAAB F0F0F0F0F0F0F0F016

Protezioni per attacchi di tipo reflection

Usare sfide strutturalmente differenti, garantire che la sfida delliniziatore abbia una struttura diversa da quella di chi risponde
ad esempio, liniziatore (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 uninformazione 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, liniziatore 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
Im Alice

Alice

R1
f(KAlice-Bob, R1), R2 f(KAlice-Bob, R2)

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

Bob

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 lindirizzo 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 dellaltro Utilizzando la tecnologia a chiave pubblica, possono autenticarsi reciprocamente scambiandosi tre messaggi
Im Alice, {R2}Bob Alice Bob

R2, {R1}Alice
R1 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

Im Alice, R2 Alice Bob

R1, [R2]Bob
[R1]Alice 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, questultima 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

Prot. 9 e 10 Alcuni problemi

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

Prot. 9 e 10 Alcuni problemi

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

Prot. 9 e 10 Alcuni problemi

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 Im Alice, f(KAlice-Bob, timestamp) f(KAlice-Bob, timestamp + 1) Bob

Alice

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

Prot. 11 Mutua autent. con timestamp

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 delliniziatore e del risponditore non interscambiabili

Prot. 11 Mutua autent. con timestamp

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

lidea 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 dalliniziatore o dal risponditore
Alice Im Alice, f(KAlice-Bob, S||timestamp) f(KAlice-Bob, R||timestamp) Bob

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

Autenticazione Crittografica Protocolli e Insidie

CIFRATURA/INTEGRIT DEI DATI

Cifratura/Integrit dei dati

Al fine di fornire protezione dellintegrit 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 Lesecuzione 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

Cifratura/Integrit dei dati

Tipicamente, una chiave di sessione viene stabilita modificando lo scambio di autenticazione in modo tale che terminato lhandshake 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 dellaltro e chiaramente la propria chiave privata Chiave pubblica unidirezionale: soltanto una parte ha una coppia PU, PR; lautenticazione unidirezionale

Cifratura/Integrit dei dati

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
Im Alice

Alice

KAlice-Bob{R}

Autenticazione con chiave segreta KAlice-Bob

Bob

Autenticazione a chiave segreta

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}

Im Alice

Alice

KAlice-Bob{R}

Autenticazione con chiave segreta KAlice-Bob

Bob

Autenticazione a chiave segreta

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 dellhandshake!

Autenticazione a chiave segreta

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 lintera conversazione, cifrata con Ks = KAlice-Bob{R+1}

Autenticazione a chiave segreta

in seguito, Trudy potrebbe impersonare lindirizzo 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
Trudy as Bob Im Alice

Alice

R+1 KAlice-Bob{R+1}

Trudy impersona Bob

Autenticazione a chiave segreta

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 dellaltro

per definire una chiave (segreta) di sessione condivisa Ks esistono varie possibilit
Im Alice, {R2}Bob

Alice

R1, {R}Bob

Ks = R

Bob

R2, {R1}Alice

(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 lindirizzo 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
Im Alice, {R2}Bob

Alice

R1, [{R}Bob]Alice

Ks = R

Bob

R2, {R1}Alice

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

lattacco 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))

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

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

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

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
Im Alice, {R2}Bob

Alice

Bob

R2, {R1}Alice, {P}Alice R1, {R}Bob

genera P

genera R

Ks = R 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

Im Alice, {R2}Bob R2, {R1}Alice, {P}Alice R1, {R}Bob

Alice

Bob

genera P

genera R

Ks = R 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 DiffieHellman autenticato (gi esaminato) dove ognuno firma la quantit da inviare allaltro si supponga che le quantit g e p siano pubbliche

Alice

[TB]Bob

Ks = KAB = TBsA mod p = TAsB mod p = KBA

Bob

genera sA TA = gsA mod p

Im Alice, [TA]Alice

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, lautenticazione crittografica unidirezionale il protocollo assicura il client (Alice) che sta contattando il server Bob giusto, ma terminato la scambio di autenticazione, che permette tra laltro 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

Alice

RA

Ks = R

Bob

Im Alice, {RA}Bob, {R}Bob

(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

Alice

Bob

genera sA TA = gsA mod p

Im Alice, TA [TB]Bob

genera sB TB = gsB mod p

Ks = KAB = TBsA mod p = TAsB mod p = KBA

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 lintera 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

Confidenzialit e Integrit(Autenticit)
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 lintegrit

ii) derivare una chiave dallaltra, 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

Confidenzialit e Integrit(Autenticit)
iv) includere un checksum debole per lintegrit allinterno 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 allintegrit
manca un controllo sullordine dei messaggi scambiati; sono possibili pertanto attacchi allintegrit 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

Attacchi allintegrit
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)

unaltra forma di attacco allintegrit e la reflection

un attaccante registra un messaggio avente una data direzione (da Bob a Alice) ed effettua il replay nellaltro senso (da Alice a Bob) se lo stesso numero di sequenza valido in entrambe le direzioni tale attacco allintegrit non viene rilevato

Attacchi allintegrit
lattacco allintegrit 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 lalgoritmo 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 questultimi possano assumere valori enormi
Si noti che, il riuso di precedenti numeri di sequenza, espone (almeno teoricamente) ad attacchi allintegrit 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 allaltra 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 laltro, di scegliere la vecchia chiave per lintegrit e la nuova per la confidenzialit

Autenticazione Crittografica Protocolli e Insidie

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 lutente 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

Alice

KDC

KAlice{use KAB for Bob}

invents key KAB KBob{use KAB for Alice}

Operazioni svolte dal KDC (in linea di principio)

Bob

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

Mediazione del KDC in pratica

inoltre, il fatto che un utente qualsiasi, senza autenticarsi presso il KDC, possa indurre questultimo 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, linformazione 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 allaltro di conoscere realmente KAB Alice wants Bob

KDC

Alice

Im Alice, ticket to Bob = KBob{use KAB for Alice}

Operazioni svolte dal KDC (nella pratica)

Bob

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

invents key KAB

Mediazione del KDC in pratica

rimangono comunque delle vulnerabilit molto sottili che hanno giustificato lintroduzione 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 KBob
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 KBob

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

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

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

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

segue sotto il Prot. 12.1 ottenuto rimuovendo la vulnerabilit appena illustrata
N1, Alice wants Bob

KDC

Alice

Im Alice, ticket to Bob

Protocollo 12.1

Bob

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

invents key KAB

Prot. 12 Prot. N-S 2^a vuln.

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

Prot. 12 Prot. N-S 2^a vuln.

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 dellutente che ha effettuato la richiesta tra le informazioni che costituiscono il ticket per Bob
il motivo di tale scelta sar chiaro pi tardi

Prot. 12 Prot. N-S 2^a vuln.

implementando le precedenti modifiche si ottiene il Prot. 12.2
N1, Alice wants Bob

KDC

Alice

Im Alice, ticket to Bob

Protocollo 12.2

Bob

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

invents key KAB

Prot. 12 Prot. N-S 3^a vuln.

Il Prot. 12.2 analogamente ai precedenti non include uno scambio che permetta di autenticare reciprocamente Alice e Bob per lautenticazione reciproca ciascuno deve provare allaltro 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)

Prot. 12 Prot. N-S 3^a vuln.

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}

Prot. 12 Prot. N-S 3^a vuln.

Il Prot. 12.3 include anche lo scambio per autenticare reciprocamente Alice e Bob
KDC
N1, Alice wants Bob KAlice{N1, Bob, KAB} ticket to Bob = KBob{KAB, Alice}

invents key KAB

Bob

Alice

Im Alice ticket to Bob, KAB{N2} KAB{N2 1, N3} KAB{N3 1}

Protocollo 12.3

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
KDC
m1

N1, Alice wants Bob KAlice{N1, Bob, KAB, ticket to Bob} m 2 where ticket to Bob = KBob{KAB, Alice}

invents key KAB

Bob
m4

Alice

m3

ticket, KAB{N2} KAB{N2 1, N3} KAB{N3 1}

m5

Needham-Schroeder

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