Protocolli di autenticazione

Un protocollo crittografico è un algoritmo distribuito che viene eseguito da $n$ soggetti, con $n\geq 2$, che indica quali azioni devono essere fatte per raggiungere un certo tipo di sicurezza. Il protocollo crittografico indica come usare un algoritmo crittografico, al fine di ottenere

• autenticazione;
• confidenzialità;
• protezione dell'integrità dei dati;
• ...

Autenticazione

L'autenticazione può essere orientata in due direzioni:

• autenticazione dei messaggi;
• autenticazione dei nodi.

L'autenticazione dei messaggi consiste nell'avere una prova dell'origine da cui arrivano i messaggi ed una prova dell'integrità dei messaggi stessi. Questo risultato può essere raggiunto attraverso una funzione di MAC, che si occupa di fare da MDC, ma con una chiave: l'MDC verifica la correttezza del messaggio ricevuto, la chiave verifica la sorgente del messaggio. A questa autenticazione si può aggiungere anche la proprietà di non ripudio, per la quale sono nate le firme digitali.

Una proprietà fondamentale di tutto questo è che non è necessario che l'autenticazione avvenga in real time, può anche essere rimandata per un tempo indefinito.

Al contrario, l'autenticazione dei nodi è quell'autenticazione che mira a far sì che un soggetto (un nodo) possa riconoscere un altro soggetto e verificarne l'identità. Nel primo caso, io verifico che il messaggio è giunto da una persona che possiede una chiave, nel secondo caso verifico che è effettivamente Bob la persona con cui io voglio comunicare. È fondamentale, in questo caso, che la verifica possa essere fatta in diretta. Noi ci occuperemo principalmente dell'autenticazione dei nodi, più che dei messaggi.

L'autenticazione è quel processo che permette ad Alice di verificare che la persona con cui sta comunicando sia effettivamente Bob, e non Trudy: serve una qualche forma di prova che faccia capire ad Alice che Bob è veramente Bob. L'autenticazione può essere mutua oppure no, dipende dalle situazioni. Un caso di autenticazione mutua è quando io voglio vedere la mia posta elettronica:

• il server si deve autenticare a me, dandomi una prova del fatto di essere veramente il server a cui io voglio collegarmi;
• io devo dare al server una prova di chi sono io, tipicamente attraverso un nome utente ed una password.

Un caso in cui non è necessaria autenticazione mutua, per esempio, è quando io voglio fruire di un contenuto come può essere un giornale on-line: devo essere sicuro che il giornale sia effettivamente quello che voglio leggere, mentre al server non interessa sapere chi sono io.

Una proprietà importante della prova di autenticazione è la non trasferibilità: Alice non dovrebbe essere in grado di usare la prova fornita da Bob, cioè Alice non dovrebbe essere in grado di andare da Charlie e convincerlo di essere Bob.

Lo stesso protocollo di autenticazione, infine, deve minimizzare la possibilità che qualcuno come Trudy possa impersonare qualcun altro. Questa proprietà deve rimanere valida anche quando

• Trudy può leggere gli scambi di dati tra Alice e Bob che si stanno autenticando;
• Trudy può fare un numero infinito di tentativi di autenticazione con Alice o con Bob, facendo finta di essere Bob o Alice;
• Alice e Bob stanno eseguendo più di un'autenticazione contemporaneamente.

Classificazione dei protocolli di autenticazione

I protocolli di autenticazione si distinguono tra loro in base alle funzionalità che possono offrire, come per esempio l'autenticazione mutua piuttosto che l'autenticazione del percorso, eccetera.

Un altro parametro importante è la complessità degli algoritmi che sono necessari per eseguire un'autenticazione, così come la quantità di dati che è necessario scambiarsi.

Infine, i protocolli si differenziano tra quelli che hanno bisogno di una figura terza per l'autenticazione (un garante super-partes), oltre che per il tipo di credenziali che sono necessarie, la dimensione di queste credenziali, per come queste credenziali devono essere usate e gestite.

Dimostrazioni d'identità

Perché Alice possa riconoscere Bob, quest'ultimo deve dimostrare di sapere o possedere qualcosa. Per esempio, Bob deve conoscere un PIN, una password, una chiave simmetrica oppure la versione privata di una coppia di chiavi asimmetriche. Nel caso invece di possesso, possiamo parlare di smart card, oppure di calcolatori crittografici, degli oggetti che forniscono una password utilizzabile una sola volta. Infine, per l'autenticazione si può ricorrere anche a caratteristiche biometriche di Bob (se è una persona), quali per esempio

• il timbro della voce;
• l'impronta digitale;
• il fondo dell'occhio;
• la forma dell'orecchio;
• le caratteristiche del viso;
• ...

Ci sono tre classi di protocolli di autenticazione:

• basati su password;
• basati su challenge-response;
• basati su una prova che non prevede alcuna conoscenza a priori, zero-knowledge proof.

Autenticazione tramite password

I protocolli basati sull'utilizzo di una password sono estremamente comuni, dal momento che la password è una prova molto semplice da ricordare e da usare. I protocolli che si basano su password sono insicuri quando

• la password non può essere cambiata, oppure non cambia con una frequenza sufficiente;
• le password usate sono passibili di attacco a dizionario, online o, peggio ancora, offline;
• la password viene trasmessa o salvata in chiaro.

Password Authentication Protocol

Il PAP è un protocollo usato esclusivamente dal protocollo PPP; si presume che il canale di trasmissione sia sicuro (una linea telefonica telecom, per esempio, viene considerata come non-intercettabile).

Alice manda al server di autenticazione AS (Bob) il suo nome utente e la sua password. Il server di autenticazione conosce

• il nome utente di Alice;
• una trasformazione $h$ della password;
• un numero casuale di bit, detto salt.

Quello che viene fatto dal server di autenticazione è andare a cercare, in una tabella, il nome utente di Alice. Se il nome utente viene trovato, si preleva il salt e lo si usa all'interno di una funzione di MDC $f(\cdot )$:

$h'=f(password|salt)$

Alla fine, viene fatto un confronto tra il risultato della funzione e la trasformazione in memoria e, se i numeri sono uguali, l'autenticazione ha successo.

Il salt è un numero casuale che ha lo scopo di rendere gli attacchi a dizionario più difficili, perché grazie al salt, anche se due utenti hanno la stessa password, difficilmente avranno lo stesso salt e quindi la stessa trasformazione $h$ della password. Il database viene conservato in questa forma per evitare che le password siano facilmente recuperabili dal disco del server nel caso di furto o manomissione.

Questo protocollo di autenticazione soffre di diversi problemi:

• attacco man-in-the-middle efficacissimo;
• il canale è considerato sicuro, ma lo è davvero?
• il server di autenticazione riceve nome utente e password in chiaro, quindi è in grado di fingersi Alice con un altro server: trasferibilità;
• le password del database sono sensibili ad un attacco a dizionario.

Quindi, concludendo, PAP non deve assolutamente essere usato, a meno che non venga usato per lo meno in un tunnel cifrato.

Challenge Handshake Authentication Protocol

Il CHAP è una variante del protocollo PAP, ed è usata in alcune implementazioni di PPP ed in Microsoft Windows.

Quello che accade con CHAP è che la funzione di trasformazione viene eseguita sia da Alice che dal server AS. Il server di autenticazione chiede ad Alice di usare, come salt, un numero casuale $c$: sarà poi Alice a mandare al server la trasformazione $r$. Il server, a sua volta, usa $c$ per calcolare la sua trasformazione $r'$ e soltanto se i risultati delle due trasformazioni saranno uguali, allora l'autenticazione andrà a buon fine.

L'implementazione standard di CHAP usa

$r=MD5(user|password|c)$

Problemi di CHAP sono:

• attacco a dizionario con $r$ (cioè, l'AS non è in realtà chi dice di essere);
• il database delle password deve essere salvato in chiaro;
• se $c$ non è un numero casuale, sono possibili i replay attack, cioè Trudy può riutilizzare l'$r$ registrato per autenticarsi a sua volta.

Ancora una volta, CHAP non deve essere usato a meno che i dati non vengano fatti transitare su un tunnel cifrato.

One-time password

Questo protocollo è stato pubblicato nel 1981 ad opera di Leslie Lamport. Funziona esattamente come il CHAP, soltanto che $c$ non è più un numero casuale, ma diventa un numero progressivo $n$.

Definiamo $f^{n}(\cdot )$ come la funzione MDC eseguita per $n$ volte:

$h^{n}=f^{n}(\cdot )=MCD(MDC(MDC(\cdots )))$ $n$ volte

Definiamo $y$ il numero residuo di volte in cui sarà possibile usare la password. Alice deve mandare al server di autenticazione il valore

$h^{y}=f^{y}(password)$

A tutto questo, di solito viene aggiunto un numero di salt per non dover salvare in chiaro il database delle password. Con questo protocollo, la trasferibilità delle credenziali viene limitata ad una sola autenticazione: Trudy può far finta di essere il server e rubare le credenziali corrette, ma queste saranno valide una volta soltanto.

Tutti i protocolli che abbiamo visto finora, inoltre, hanno un difetto sostanziale: non prevedono la possibilità di fare autenticazione mutua, una funzione molto spesso importante.

Encrypted Key Exchange

Il protocollo EKE si propone di estendere il protocollo Diffie-Hellman, introducendo l'autenticazione sulla chiave che si calcola.

Alice manda a Bob un numero $A$ che contiene la versione cifrata di $g^{Sa}\mod {p}$, dove la chiave di cifratura $w$ è la trasformazione MDC di una password condivisa.

$A=E_{w}(g^{Sa}\mod {p})$

Bob, che riceve il messaggio di Alice, sceglie a sua volta un numero $Sb$ con cui calcolare la grandezza

$g^{Sb}\mod {p}$

e sceglie anche un numero casuale $c_{1}$. Alice, grazie al messaggio di Bob, sarà in grado di calcolare la chiave effimera $K$, esattamente come Bob, con cui cifrare un altro messaggio di risposta che contiene il numero casuale scelto da Bob ed un altro numero casuale, scelto da Alice. Se Bob ha ricavato la chiave $K$ corretta, sarà in grado di decifrare il messaggio e di cifrarne uno nuovo, contenente soltanto il numero che ha scelto Alice.

In questa maniera, si è ottenuta autenticazione mutua ed il setup di chiavi effimere simmetriche, utilizzabili per cifrare i messaggi successivi. Questo algoritmo gode anche di resistenza ad attacchi off-line, perché anche decifrando i messaggi scambiati da Alice e Bob, non si ottengono che numeri casuali ed effimeri, già dimenticati dai due soggetti. L'unico problema è che sia Alice che Bob devono possedere la password e, se Bob è un server di autenticazione, avrà nella sua memoria le password in chiaro di tutti i suoi utenti.

Autenticazione tramite challenge

Una challenge è un numero scelto da uno dei due soggetti partecipanti all'autenticazione. Questo numero deve essere firmato dall'altro soggetto, Alice, attraverso un MAC. Bob autentica Alice non tanto sulla challenge, ma sul valore del MAC calcolato, che non può essere corretto se la chiave usata è sbagliata. La principale innovazione di questo tipo di protocolli è che Alice non deve svelare a nessuno, almeno durante l'autenticazione, il suo segreto $s$.

Il segreto di Alice può essere qualsiasi cosa: una password, per esempio, ma anche la versione privata di una coppia di chiavi asimmetriche, oppure una chiave simmetrica condivisa.

La challenge

La challenge è di primaria importanza; deve sempre essere fresca, non deve esser mai stata usata: se così non fosse, gli attacchi di tipo replay diventerebbero facilissimi. La challenge può essere:

• una nonce, cioè un numero casuale usato una sola volta;
• un numero di sequenza, cioè un contatore che continua ad aumentare ad ogni ciclo di autenticazione;
• un timestamp, un'informazione sul tempo.

Usare un numero di sequenza o il tempo permette di evitare che la challenge circoli nella rete e possa essere intercettata, però il protocollo diventa più difficile da implementare:

• nel caso dei numeri di sequenza, questi devono essere uguali per Alice e Bob, il che non è banale (se Alice usa computer diversi?);
• nel caso del tempo, il problema è che gli orologi di Alice e Bob devono essere sincronizzati, cosa se non altro costosa.

Il segreto $s$

Il segreto $s$ è un numero, protetto attraverso meccanismi crittografici, che viene condiviso tra Alice e Bob. Questo numero può essere statico oppure il risultato di algoritmi di cifratura o di MAC. Il problema principale sta nella gestione di questi segreti, che deve essere fatta in maniera sicura: servono algoritmi per generare questi segreti ed algoritmi di cifratura per mantenere questi segreti davvero segreti. Purtroppo, la non trasferibilità è ancora un risultato lontano, anche con questi algoritmi.

Una variante può essere quella di avere dei segreti che non vengono condivisi tra i soggetti che si vogliono autenticare, ma vengono condivisi con un soggetto terzo, un server di autenticazione $Z$ che autentica sia Alice che Bob e dà loro la garanzia di essere veramente chi dicono di essere.

RSA SecurID SID800

Per venire incontro al problema del segreto, RSA ha lanciato un prodotto commerciale discretamente utilizzato, chiamato SecurID: si tratta di un calcolatore, delle dimensioni di una chiave, che mostra un numero variabile nel tempo. Questo numero è sincronizzato con il server, ed è la nostra chiave di cifratura, anch'essa, a questo punto, effimera.

ISO/IEC 9798-2/4

Gli standard ISO/IEC 9798-2 e ISO/IEC 9798-4 indicano due metodi di autenticazione del tipo challenge-response, cioè un'autenticazione in cui il server chiede all'utente di firmare qualcosa, una challenge. Questi protocolli sono basati:

• sul tempo $t$;
• su numeri random o contatori.

Nel caso di protocolli basati sul tempo $t$, basta che Alice mandi un messaggio a Bob con i dati corretti perché venga accettata l'autenticazione; si tratta di un protocollo molto semplice e che permette l'utilizzo ottimale della rete: un solo piccolo messaggio per ottenere ciò che si vuole.

Alice manda in chiaro la sua login $A$, e manda le informazioni sul tempo e sull'identità di Bob, cifrate con una chiave condivisa $s$:

$R=E_{S}(t,B)$

Quello che deve fare Bob è controllare se il nome utente è corretto, decifrare il messaggio e verificare che l'istante di tempo sia compreso in un intorno accettabile

$t-x<t'<t+x$

Nel caso di protocolli basati su nonces, cioè su numeri casuali validi una volta sola, la complessità del protocollo cresce, ma è possibile anche fare autenticazione mutua.

Ad iniziare la comunicazione, questa volta, è Bob, che manda ad Alice un numero casuale $c_{1}$ e la sua identità. Alice risponde a questo messaggio con un nuovo messaggio in cui inserisce

• il suo nome utente
• il numero $R_{A}=E_{s}(c_{1},c_{2},B)$

dove $R_{A}$ contiene la nonce scelta da Bob, una nonce scelta da Alice e l'identità di Bob, tutto cifrato con una chiave condivisa $s$. A questo punto, Bob manderà ad Alice un messaggio di risposta con un numero

$R_{B}=E_{s}(c_{2},c_{1},A)$

in modo tale che Alice abbia la conferma che Bob ha ricevuto il suo messaggio e vuole davvero parlare con lei. In questa maniera, il protocollo permette mutua autenticazione e previene anche la possibilità di replay attacks, gli attacchi fatti mandando ad un utente i messaggi di login corrette registrate in passato.

Autenticazione con algoritmi asimmetrici

Vogliamo fare un ulteriore passo in avanti nella sicurezza, andando ad utilizzare le chiavi di cifratura asimmetrica come segreto per l'autenticazione. In questa maniera, il segreto di Alice non deve più essere condiviso con nessuno, basta che Bob o il server di autenticazione abbiano la chiave pubblica di Alice. Un passo in più può essere quello di adottare i certificati digitali. Questi altro non sono che dei documenti in cui un ente terzo, una Certification Authority CA, dichiara che la chiave pubblica di Alice è effettivamente associata alla persona Alice, con tutta una serie di informazioni sul suo conto.

I principali problemi che ci sono, nell'utilizzo di questo tipo di credenziali, sono

• l'autenticazione delle chiavi pubbliche (perché le Certification Authority fanno il loro lavoro, sì, ma a pagamento);
• complessità computazionale elevata.

Un esempio semplice di utilizzo delle chiavi asimmetriche. Alice manda la sua login al server di autenticazione Bob, il quale risponde mandando la sua identità, una challange cifrata con la chiave pubblica di Alice e l'MDC della stessa challange.

L'autenticazione andrà a buon fine solo se Alice sarà in grado di mandare la challange corretta al server di autenticazione, in una qualche maniera (in chiaro, oppure cifrata con la chiave pubblica del server).

Per la sicurezza della coppia di chiavi, è sempre bene assicurarsi che le implementazioni di autenticazione siano aderenti agli standard di sicurezza come il PKCS.

ISO/IEC 9798-3

Lo standard ISO/IEC 9798-3 definisce un protocollo di autenticazione basato sulla crittografia asimmetrica e sulle firme digitali. Può essere basato sul tempo oppure su nonce.

Nel caso in cui si voglia usare il tempo, si ha autenticazione singola e massima efficienza di banda, perché si manda un solo messaggio che contiene:

• la login di Alice;
• il tempo $t$;
• il destinatario del messaggio, Bob;
• la firma sul numero $(t,Bob)$

Nel caso di autenticazione con nonce, invece, si può ottenere autenticazione mutua. Si ha:

• Bob manda ad Alice un messaggio contenente la sua identità è la nonce che ha scelto lui, $c_{1}$;
• Alice risponde mandando la sua identità, quella di Bob, la sua nonce $c_{2}$ e la firma su $(c_{1},c_{2},B)$;
• Bob chiude il protocollo mandando l'identità di Alice e la sua firma sulla grandezza $(c_{2},c_{1},A)$.

il fatto che anche Alice possa scegliere la sua challenge è importante, perché impedisce che Alice debba firmare un numero casuale senza saperne il motivo: magari sta ponendo la sua firma sull'MD5 di un messaggio che non ha mai scritto, senza saperlo.

Zero-knowledge proof

L'idea che sta alla base di questo tipo di autenticazione è che Bob, dopo aver autenticato Alice, non avrà nessuna ulteriore informazione sul segreto di Alice. Alice non rivelerà a Bob nulla che lui non sapesse già su Alice. Per far questo, bisogna introdurre la nozione di autenticazione in probabilità: ad ogni scambio di messaggi, Bob ha una sicurezza sempre crescente sulla vera identità di Alice; ovviamente, la probabilità deve approssimarsi al 100% velocemente.

Protocollo Fiat-Shamir

Teorema:

Calcolare la radice quadrata di un numero $\mod {n}$ è tanto complesso quanto sarebbe fattorizzarlo.

Si parte dal presupposto che Bob, attraverso un canale sicuro, abbia alcune informazioni su Alice:

• la sua login;
• un numero $n$ grande;
• un altro numero $v=s^{2}\mod {n}$, dove $1<s<n$ è un numero casuale coprimo con $n$.

Per l'autenticazione, Alice manda a Bob un numero $x_{i}$ definito come:

$x_{i}=r_{i}^{2}\mod {n}$

dove $1<r<n$ è un numero casuale e coprimo con $n$. Bob risponde a questo messaggio con un numero $e_{i}=rand(\{0,1\})$, da cui Alice ricava e spedisce il numero

$y_{i}=r_{i}\cdot s^{e_{i}}\mod {n}$

L'identità viene confermata se:

• con $e_{i}=0$, il risultato è stato

$y_{i}^{2}=x_{i}\mod {n}$

• con $e_{i}=1$, il risultato è stato

$y_{i}^{2}=x_{i}\cdot v\mod {n}$

Con questo tipo di protocollo, Trudy è in grado di ingannare Bob soltanto dopo aver registrato una sessione di login e soltanto sotto l'ipotesi che Bob richieda la stessa identica sequenza di valori$e_{i}$: di conseguenza, Bob non deve mai chiedere più volte la stessa sequenza, altrimenti c'è il rischio che Trudy possa fare un replay attack. Se la sequenza di $e_{i}$ cambia, allora Trudy avrà ogni volta il 50% di probabilità di indovinare il risultato corretto; di conseguenza, la probabilità che Trudy possa riuscire a fare login è $2^{-i}$. In genere, un numero di ripetizioni $i$ considerato sufficiente è attorno alle 30, 40 volte, sia perché è difficile da registrare, sia perché si ha un numero di permutazioni della sequenza degli $e_{i}$ sufficiente a impedire replay attack, che avrebbero probabilità di successo 100%.

Classificazione degli attacchi

Registrazione, sniffing

È un attacco di tipo passivo, il più semplice di tutti ed il più probabile: Trudy si inserisce della linea di comunicazione tra Alice e Bob e registra tutto quello che viene trasmesso. È il primo attacco che verrà fatto, sempre. Bisogna quindi porre particolare attenzione quando si decide di usare un protocollo semplice come il PAP, perché bisogna partire dal presupposto che questo attacco è sempre possibile (lo è nella realtà, sempre): il server di autenticazione AS può essere corrotto, l'intruso attiva un servizio come tcpdump e registra tutte le credenziali che arrivano al server, senza nemmeno doversi preoccupare di andarle a cercare nel database, senza doversi immettere in nessuna connessione cifrata.

Come conseguenza di questo attacco, tutto quello che può fare Trudy è cercare di calcolare le credenziali di Alice e Bob, come le password o le chiavi private. Altrimenti, se Trudy diventa un attaccante attivo, può cercare di impostare un replay attack, immettendo nella rete i pacchetti che ha registrato e cercando di far credere a Bob di parlare con Alice o viceversa.

Per ovviare a questi problemi, bisognerebbe sempre inserire, all'interno del protocollo che si vuole creare, un legame tra le identità dei partecipanti ed il tempo, oppure usare delle challange casuali. È importante proteggere non solo se stessi, ma anche le credenziali di chi si dovrà poi collegare al nostro server.

Lettura del database

Un attacco solo poco più complicato dello sniffing, perché è necessario avere accesso al calcolatore di Alice o di Bob; questo può essere fatto attraverso dei malware informatici, oppure avendo accesso fisico, rubando o semplicemente consultando l'hard disk non solo di Alice, ma anche del server di autenticazione. Per questo, è fondamentale che le password e tutti i documenti come le chiavi private vengano cifrati, perché è l'unico modo per proteggerli da un attacco al database.

Falsa identità

Con questo tipo di attacco, Trudy è in grado di intercettare i messaggi tra Alice e Bob, ed ha il tempo per modificarli. Allora, Trudy chiederà ad Alice di fare le trasformazioni per conto suo. I protocolli che prevedono di firmare soltanto delle challange sono i più esposti a questo tipo di attacco.

Nel caso di credenziali simmetriche, Trudy potrebbe voler derivare le credenziali di Alice o di Bob, quindi potrebbe sottoporre loro delle challange apposite, pensate per ridurre al minimo lo sforzo (attacco di tipo chosen text). Se poi le credenziali sono asimmetriche, allora Trudy potrebbe cercare di derivare le chiavi private, oppure potrebbe sottoporre una challange che in realtà non è soltanto un semplice numero casuale: potrebbe essere il digest di un documento, al quale Alice appone la sua firma facendone il MAC. A questo punto, Trudy ha un documento firmato da Alice.

Alcune regole per evitare problemi di questo tipo sono:

• il protocollo deve prevedere un padding casuale scelto sia da Alice che da Bob: Alice non deve essere costretta a firmare tutto quello che le si chiede di firmare;
• usare protocolli che mettono in gioco anche il fattore tempo;
• usare sempre credenziali diverse per i diversi servizi: una chiave privata può essere usata sia per fare login su servizi che per firmare documenti, ma viene esposta a due rischi diversi.

Attacchi a specchio

Sono degli attacchi che prevedono l'inizializzazione di più sessioni in parallelo. Un esempio:

Il protocollo d'esempio prevede che Alice mandi a Bob una challange $c_{1}$, Bob firma la challange e chiede ad Alice di firmarne una a sua volta, $c_{2}$. Ma cosa succede se Iniziamo una seconda sessione?

Trudy inizia una sessione esattamente come farebbe Alice: Bob firma $c_{1}$ e chiede di firmare $c_{2}$. A questo punto, Trudy può iniziare una nuova sessione, chiedendo a Bob di firmare $c_{2}$ al posto di $c_{1}$: è una richiesta legittima, Bob risponderà con la firma di $c_{2}$ ed una nuova challange $c_{3}$. A questo punto, Trudy può portare a compimento la prima sessione di login, perché è entrata in possesso della firma corretta per $c_{2}$, senza conoscere la chiave $K$.

Attacchi di questo tipo sono evitabili:

• usando credenziali diverse nelle due direzioni, come la crittografia asimmetrica, oppure crittografia simmetrica ma con due chiavi per le due diverse direzioni (Alice cifra i messaggi per Bob con $k_{1}$ e Bob risponde ad Alice con $k_{2}$);
• imponendo che sia il server di autenticazione a fare la prima richiesta;
• eliminando le simmetrie nei messaggi, per esempio usando imponendo di fare il MAC di entrambi i nonce, anziché soltanto uno.

Attacco ad intermediario

Trudy può iniziare due autenticazioni, una con Alice ed una con Bob. Prendiamo un protocollo di esempio:

Trudy può attaccare il protocollo in questa maniera:

cioè, chiedendo ad Alice di firmare, nuovamente, i dati al posto di Bob. Se questa cosa può sembrare strana, si consideri la possibilità che sia Alice che Bob siano due server che comunicano in automatico, entrambi potrebbero voler aprire una connessione verso l'altro.

Questo attacco può essere evitato chiedendo di firmare sempre tutte le challange in successione, cioè imponendo, al posto di $MAC_{k}(c_{2},c_{4})$, che venga firmato $MAC_{k}(c_{2},c_{1})$.

Chiavi effimere ed autenticazione

Vogliamo derivare delle chiavi temporanee da usare per uno scambio di dati; queste chiavi temporanee devono essere autenticate esplicitamente, cioè ci deve essere la sicurezza assoluta che soltanto i soggetti che fanno parte del gruppo di lavoro, e che si sono autenticati, le conoscano davvero. Genericamente, i soggetti possono essere anche più di due.

L'autenticazione dei soggetti che hanno diritto a conoscere la chiave è strettamente legata all'autenticazione delle chiavi effimere che, generalmente, vengono derivate da tutti durante la fase di autenticazione. È quindi il protocollo di autenticazione dei soggetti a doversi occupare della derivazione delle chiavi effimere autenticate.

Le chiavi effimere, o temporanee, sono l'opposto delle chiavi master, o chiavi di lungo periodo. Se le chiavi effimere devono essere cambiate ad ogni autenticazione (o anche più spesso), le chiavi di lungo periodo sono quelle chiavi, tipicamente asimmetriche, che servono per autenticare i soggetti all'interno di una sessione cifrata.

L'utilizzo delle chiavi di lungo periodo in maniera intensiva, oltre ad essere computazionalmente più oneroso, espone le chiavi stesse, perché aumenta la quantità di dati che possono essere analizzati, da cui si può potenzialmente ricavare la chiave privata; al contrario, usare chiavi effimere permette di usare algoritmi di cifratura simmetrici, quindi meno computazionalmente onerosi, e permette che le chiavi siano cambiate molto più spesso, limitando quindi la quantità di testo cifrato che è possibile analizzare. Inoltre, se viene scoperta una chiave temporanea, saranno disponibili all'attaccante soltanto una quantità di dati limitata, mentre se si usasse la chiave di lungo periodo, una volta scoperta, esporrebbe tutti i dati alla decifratura, fatto sgradevole.

Un altro motivo per cui usare le chiavi effimere è che queste possono essere più di una, in sessioni diverse, anche contemporaneamente: Alice può parlare in segretezza con più persone, senza che ognuno di loro possa leggere i dati che Alice scambia con gli altri.

Perfect Forward Secrecy

La PFS è la sicurezza perfetta nel futuro, cioè la garanzia che, una volta cancellate le chiavi effimere, anche se qualcuno scopre la chiave di lungo periodo, non ha alcuna informazione aggiuntiva sulle chiavi temporanee e, quindi, non potrà comunque leggere le informazioni protette con chiavi temporanee. Un esempio di algoritmo che offre PFS è EKE, mentre qualsiasi protocollo che prevede di scambiarsi le chiavi cifrandole con la chiave master non offre alcuna garanzia di PFS, perché le chiavi saranno recuperabili dalla registrazione.

Ovviamente, la PFS offre garanzie per il passato, ma non per il futuro: una volta che la chiave privata di Alice è stata compromessa, Trudy potrà comunque far credere agli altri di essere Alice.

La forward secrecy, invece, è quella proprietà del protocollo che, se una chiave effimera viene scoperta, nulla si sa su tutte le altre chiavi effimere. Infatti, anche se Trudy è in grado di calcolare una o più chiavi effimere, questo non la deve aiutare nel calcolo delle chiavi effimere successive o precedenti, né tantomeno per il calcolo della chiave privata di Alice o di Bob. Questa proprietà è molto importante, perché di solito le chiavi effimere sono meno protette delle chiavi di lungo periodo:

• vengono condivise tra più persone;
• non vengono salvate in forma cifrata;
• sono usate per cifrare grandi quantità di dati, quindi sono più esposte alla crittanalisi.

Di conseguenza, è più probabile che venga scoperta una chiave effimera piuttosto che la chiave di lungo periodo, quindi è importante che da questa non si riesca a risalire alla chiave di lungo periodo, né alle chiavi temporanee future o passate.

Setup delle chiavi effimere

Le chiavi effimere possono essere decise da un singolo soggetto, oppure essere calcolate in parallelo da tutti i partecipanti alla sessione protetta.

Nel caso in cui la chiave venga decisa unilateralmente da un'entità, allora questa chiave dovrà essere cifrata con le credenziali di lungo periodo, in modo tale che gli utenti della sessione cifrata la possano ricevere in maniere sicura, senza che qualcuno possa leggerla. In questa manieral, la chiave temporanea viene protetta soltanto dalla chiave di lungo periodo.

Nel caso, invece, in cui le chiavi vengano calcolate in parallelo da tutti i partecipanti alla sessione cifrata, allora tutti dovranno immettere il loro contributo affinché la chiave possa essere generata; questa chiave, quindi, non dovrà circolare nella rete, non dovrà essere protetta, quindi non ci sarà il pericolo che venga recuperata a partire dalle registrazioni di una sessione di comunicazione.

Questo secondo approccio è più pesante del primo, dal punto di vista computazionale, ma offre la PFS ed è meno esposta a replay attack.

Chiave trasportata nella rete

La chiave temporanea $K_{t}$ può essere semplicemente decisa da Alice e poi comunicata a Bob in forma cifrata, usando la chiave master $K$ per cifrare la chiave temporanea. Se, assieme alla chiave, cifriamo anche il nome del destinatario, allora si impedisce che quello stesso messaggio possa essere usato per fare un replay attack contro Alice; questo attacco resta comunque possibile nei confronti di Bob, oltre al fatto che manca totalmente la PFS.

Per ovviare ai replay attack, si può imporre che sia Bob a comunicare ad Alice un numero $n$ nonce, in modo da rendere univoco il messaggio cifrato.

Aggiungendo poi le firme digitali, si ha un'autenticazione ancora più forte del messaggio.

Key Distribution Center

La distribuzione delle chiavi effimere per $n$ nodi prevede che ognuno di questi nodi conosca $(n-1)$ chiavi pubbliche, una per ogni altro partecipante alla sessione cifrata. Questo fatto è un problema, al crescere di $n$.

Per ovviare a questo problema nascono i Key Distribution Center KDC, i centri per la distribuzione delle chiavi effimere. Grazie al KDC, ogni nodo della rete protetta deve conoscere soltanto le credenziali proprie e del KDC, mentre il KDC stesso si incarica di tener traccia delle credenziali di tutti i nodi della rete protetta. Questo fa sì che il KDC sia un elemento fondamentale della rete, deve essere un nodo di fiducia per tutti coloro che si attestano alla rete, perché è l'unico vero intermediario tra i nodi deputato all'autenticazione di ogni singolo nodo e alla comunicazione delle chiavi temporanee.

Usare un KDC è sicuramente un vantaggio nelle reti di grandi dimensioni, dove la scalabilità è importante. Infatti, aggiungere un nodo ad una rete di 1000 computer è tanto semplice con un KDC tanto è difficile in una rete distribuita. Inoltre, se un singolo nodo viene compromesso, il KDC dovrà aggiornare soltanto le sue credenziali, mentre in una rete distribuita tutti devono essere informati della nuova chiave pubblica e del fatto che quella vecchia non deve più essere usata.

Al contrario, il KDC diventa un nodo nevralgico per la sicurezza di tutta la rete: se questo viene a mancare o se questo è sottodimensionato, rischia di diventare un collo di bottiglia per tutta la rete.

Un esempio di implementazione di un KDC è il protocollo Kerberos; analizziamo, in maniera semplificata, Kerberos v5.

Supponiamo che Alice voglia parlare con Bob: dovrà quindi mandare al KDC un messaggio che contenga il suo username, lo username di Bob, ed un numero $n$ come nonce. Il server KDC risponderà ad Alice con due ticket, due biglietti che contengono le credenziali per lei e per Bob: sarà Alice a dover comunicare a Bob le sue credenziali per poter iniziare la connessione cifrata.

Tutte le chiavi che vengono rilasciate dal server kerberos devono essere usate entro un certo tempo, definito tal numero $L$. Opzionalmente, Alice e Bob possono usare questa chiave $K_{t}$ per scambiarsi altre due chiavi, $K_{subA}$ e $K_{subB}$, delle sottochiavi di cifratura.

Le credenziali di Alice e Bob, in Kerberos, vengono derivate a partire dalle password degli utenti, attraverso una funzione MDC. È importante notare che, assieme alla password, viene usato anche il nome di dominio in cui opera il server: questo fatto fa sì che, se un utente usa la stessa password per più domini diversi, anche se il database di un dominio viene perso, gli altri domini non sono in pericolo.

Chiave calcolata da tutti i nodi

L'importanza di questo tipo di approccio è che tutti partecipano al calcolo della chiave.

Per generare le chiavi su usano dei numeri casuali, mentre per evitare il problema dei replay attack si ricorre all'uso di nonce.

File:Sicurezza chiavi derivate.png

Questo tipo di protocollo utilizza le credenziali di lungo periodo di Alice e di Bob per trasportare i numeri casuali con cui verrà calcolata la chiave, per esempio con un MDC:

$K_{t}=MDC(r_{1},r_{2})$

ma questo fa sì che il protocollo non goda della PFS: se la sessione viene registrata e se vengono scoperte le chiavi private di Alice e di Bob, i numeri casuali $r_{1}$ e $r_{2}$ possono essere recuperati e, di conseguenza, può essere ricalcolata la chiave effimera con cui decifrare tutti i messaggi.

Per aggiungere la PFS, si ricorre al protocollo Station To Station STS, che è una variante dell'algoritmo Diffie-Hellman con autenticazione.

File:Sicurezza chiavi derivate STS.png

In questo caso, Alice manda a Bob tutte le grandezza che sono necessarie all'algoritmo Diffie-Hellman; Bob risponde con gli altri valori necessari per il calcolo della chiave, ma aggiunge anche la versione cifrata (con la chiave temporanea) della sua firma sui due numero $g^{Sa}$ e $g^{Sb}$, in modo tale da autenticarsi ad Alice. Come ultimo passo, anche Alice si autentica a Bob, mandando la versione cifrata della sua firma sui due numero $g^{Sa}$ e $g^{Sb}$.

Ovviamente, come prevede l'algoritmo Diffie-Hellman, la chiave temporanea sarà

$K_{t}=g^{Sa\cdot Sb}\mod {p}$

Questo protocollo garantisce la PFS, perché questa volta davvero non circola nulla sulla rete che possa portare alla chiave temporanea. Lo scambio delle firme cifrate garantisce che sia Alice che Bob hanno calcolato la stessa $K_{t}$, e permette loro di autenticarsi. L'unico difetto di questo approccio è la complessità computazionale, dal momento che si usano sia Diffie-Hellman che chiavi asimmetriche.

Certification Authority

Le Certification Authority, CA rispondono alla necessità di autenticare le chiavi pubbliche: il concetto è simile al KDC, ma si opera nel mondo della crittografia asimmetrica. La CA si pone come un intermediario di fiducia tra Alice e Bob, che certifica l'autenticità d l'integrità delle loro chiavi pubbliche, in modo tale che essi siano in grado di riconoscersi senza ombra di dubbio.

Un certificato digitale non è altro che una firma apposta sulla coppia $(K_{pubA},A)$,

$Cert_{A}=S_{CA}(K_{pubA},A)$

cioè, l'autorità certificante firma e si pone da garante per Bob, dichiarando che la chiave pubblica $K_{pubA}$ è effettivamente associata ad Alice, cioè la particolare chiave è associata alla particolare persona (o azienda, o server).

Perché tutto questo funzioni, è necessario che Bob possegga la vera chiave pubblica del CA; inoltre, l'autorità deve essere di fiducia (trusted) sia per Alice che per Bob: Alice si fida dell'autorità e paga per avere il certificato, Bob si fida della CA ed accetta la sua firma come prova dell'identità di Alice.

L'autorità di certificazione può essere anche offline, non deve essere necessariamente collegata ad internet o consultabile perché il meccanismo funzioni: quando Bob possiede il certificato digitale e la chiave pubblica della CA (di cui ha la garanzia della veridicità), è in grado in qualsiasi momento di verificare la firma della CA, senza doverla interpellare.

Collegamenti esterni

• Pagina della Wikipedia inglese su SecurID (in inglese) (7/12/2008 verificato funzionante)
• ISO/IEC 9798-2 (in inglese) (negozio di contenuti a pagamento) (7/12/2008 verificato funzionante)
• ISO/IEC 9798-3 - RFC 3163 (in inglese) (7/12/2008 verificato funzionante)
• ISO/IEC 9798-4 (in inglese) (negozio di contenuti a pagamento) (7/12/2008 verificato funzionante)
• Sito di TcpDump (in inglese) (7/12/2008 verificato funzionante)