Gestione di distribuzione delle chiavi

Un’altra possibilità di diminuire il carico organizzativo della gestione delle chiavi è di creare una

gerarchia dei centri di distribuzione delle chiavi locali. Ogni KDC locale ha il proprio bacino di

utenza e gestisce in proprio le chiavi per le comunicazioni tra le persone appartenenti al proprio

bacino di utenza.

Ogni KDC locale gestisce le chiavi master degli utenti che appartengono al suo bacino locale.

Il vantaggio qui non è solo dal punto di vista organizzativo, ma anche dal punto di vista della

sicurezza, perché se viene compromesso un KDC locale, allora viene compromesso solo l’insieme

di chiavi di quel gruppo locale.

Qualunque sia il livello di sicurezza, è opportuno che queste chiavi periodicamente vengano

cambiate. Lo svantaggio è che si passa molto tempo a richiedere la generazione delle chiavi e

questo causa un ritardo nella comunicazione. Ci deve essere 1 compromesso tra la sicurezza e il

carico di comunicazione computazionale. C’è inoltre il problema di definire ogni quanto si vanno a

cambiare le chiavi realizzando un compromesso tra queste due esigenze.

C’è quindi il problema di definire ogni quanto si va a cambiare queste chiavi.

Vediamo ora cosa succede all’interno di ogni singolo host quando si vuole generare una

connessione sicura.

In questo caso la richiesta di una comunicazione sicura parte dall’applicazione e si immagina che

ci sia un modulo dentro l’host (SSM) che si occupa di gestire la sicurezza interagendo con un

centro di distribuzione delle chiavi. Nel momento in cui una applicazione chiede di instaurare una

comunicazione sicura, il contenuto effettivo della comunicazione viene messo in standby ossia

prima si pensa a generare le chiavi responsabili della sicurezza e poi si manda effettivamente il

messaggio. Quindi il modulo che si occupa della sicurezza va a chiedere al centro di distribuzione

la chiave di sessione e a questo punto il centro di distribuzione la manda sia alla prima parte della

comunicazione e sia alla seconda parte.

A questo punto, entrambe le parti hanno ottenuto la chiave, e il mittente può aprire la connessione

e scambiare i dati utilizzando la chiave segreta.

In questo schema, come a quello visto in precedenza, c’è la presenza di un centro di distribuzione

delle chiavi. L’introduzione di questa parte può aggiungere dei problemi ossia in particolare deve

essere sicura perché poiché gestisce tutte le chiavi degli host che fanno riferimento ad esso, una

sua compromissione significa che tutte le comunicazioni tra quegli host non sono più sicure. Una

possibilità è quella di eliminare questa distribuzione centralizzata e di ricorrere ad un meccanismo

decentralizzato. Ovviamente questo non è consigliabile per reti molto grandi perché il carico della

gestione delle chiavi si sposta sui singoli host dove ogni host deve gestire (n-1) chiavi.

NOTA: stiamo sempre parlando di chiavi simmetriche per una sessione di comunicazione.

Il funzionamento è il seguente:

il mittente interagisce direttamente con il destinatario ed invia ad esso il suo ID ed un nounce.

Il destinatario cifra una serie di informazioni che contengono: la chiave si sessione, l’identificativo

di A, l’identificativo di B, una funzione del nounce ed un altro nounce che genera lui stesso.

Il mittente a questo punto riceve il messaggio, può estrarre la chiave di sessione e manda questa

chiave di sessione assieme ad una risposta al nounce.

In questo tipo di comunicazione si utilizza una chiave master condivisa dove ogni host deve tenere

n-1 chiavi ed si utilizza una chiave si sessione.

Il vantaggio di usare la chiave master solo per lo scambio necessario per ottenere la chiave di

sessione è che viene esposta per poco dove il messaggio è molto breve in modo da risultare

difficile all’attaccante fare criptoanalisi di questi messaggi.

Una ulteriore complicazione del meccanismo di gestione delle chiavi è quella di specializzare

anche le chiavi, quindi di rendere più limitato il loro utilizzo (è una forma di protezione). In questo

caso le chiavi sono esposte poco perché ogni chiave serve per un ambito specifico.

Un vantaggio è che l’attaccante non sa per quale ambito la chiave vale.

Per controllare questa specializzazione di utilizzo di ogni chiave si deve specificare ossia ogni volta

che si manda la chiave serve un’informazione che specifichi l’utilizzo della chiave.

Il primo meccanismo è quello di associare una targhetta ad ogni chiave, in particolare nel DES si

possono usare gli 8 bit inutilizzati in modo da avere 256 possibilità diverse.

Un’alternativa al DES è usare un vettore di controllo mediante una funzione di hash.

Il vettore di controllo è una stringa di bit che non è più fatta di 8 bit come nel caso del DES, ma si

può fare lunga a piacimento;

il vettore di controllo viene fatto in XOR con la chiave master e questa combinazione viene

utilizzata per cifrare la chiave di sessione.

Un’altra possibilità per la distribuzione è quello dell’uso della cifratura asimmetrica. Utilizziamo

quindi una cifratura asimmetrica per distribuire chiavi simmetriche.

La cifratura a chiave asimmetrica viene applicata in maniera abbastanza diretta perché il mittente A

manda la sua chiave pubblica a B, gli associa il suo identificativo; a questo punto B risponde

cifrando con la chiave pubblica di A la chiave simmetrica. In questo caso è chiaro che solamente A

può decifrare questo messaggio e quindi ottenere la chiave simmetrica perché la decifratura si

deve fare con la chiave privata di A.

Il grande problema di questo approccio è che è vulnerabile ad attacchi di tipo Man in The Middle.

Per quanto riguarda questo attacco si ha:

- A manda il suo ID e la sua chiave pubblica;

- C blocca questo pacchetto ed invece di farlo mandare verso B, genera una sua coppia di

chiavi privata/pubblica e manda ad B il messaggio con l’ID di A.

- B ricevendo la chiave pubblica di C con l’ID di A, quando deve mandare un messaggio per

inviare la chiave simmetrica, lo cifra con la chiave pubblica che ha ricevuto ossia quella

dell’attaccante;

- Questo messaggio torna indietro e C cosi come aveva bloccato il precedente, blocca anche

questo; poiché è stato cifrato con la sua chiave pubblica, lui può leggerlo con la sua chiave

privata;

- Adesso C estrae la chiave simmetrica e si sostituisce a B nel mandare il messaggio di

ritorno e manda ad A questa volta un messaggio cifrato con la chiave pubblica di A e gli

cifra la chiave simmetrica che B ha inviato.

Questo meccanismo con l’uomo in mezzo fa saltare sia la riservatezza che l’integrità.

Un ulteriore meccanismo per la distribuzione delle chiavi nella cifratura simmetrica usando un

meccanismo a chiave pubblica è il seguente:

In questo caso si utilizzano entrambe le chiavi e permette di ottenere sia riservatezza che

autenticazione.

- Il mittente cifra con la chiave pubblica di B il suo ID ed il nounce per evitare attacchi di tipo

replay. Questo messaggio lo manda a B e solamente B lo può leggere perché cifrato con la

chiave pubblica;

- B risponde cifrando con la chiave pubblica di A il nounce di prima concatenato con un altro

nounce generato da lui stesso; anche questo messaggio non potrebbe essere letto

correttamente da qualcun altro perché deve essere decifrato con la chiave privata di A.

- A, avendo ricevuto la risposta da B, con questo secondo nounce, risponde con il nounce

che ha ricevuto prima cifrato con la chiave pubblica di B

- A può completare questi scambi perché può cifrare, con la chiave pubblica di B in modo

che solo B possa leggerlo, la chiave segreta cifrata con la chiave privata di A. Questo

garantisce l’autenticazione.

Un altro problema che si pone è quello della distribuzione delle chiavi pubbliche perché quando

una persona manda una chiave pubblica chi ci dice che la persona che ha effettivamente

associato a se quella chiave pubblica? Il problema a questo punto diventa sapere chi sta dietro le

chiavi pubbliche.

Ci sono 4 categorie di tecniche più diffuse per la distribuzione delle chiavi pubbliche:

- Annuncio pubblico: ognuno è responsabile della distribuzione della propria chiave pubblica.

Questo significa che il mittente A ha una serie di soggetti a cui vuole inviare dei messaggi e

quindi manda questa chiave pubblica a tutte queste persone; questo meccanismo è molto

semplice ma poco sicuro.

- Elenco pubblico delle chiavi: c’è un elenco pubblico e chiunque può andare a consultare

questo elenco; qui la responsabilità non è più della singola persona di distribuire la sua

chiave pubblica, ma entra in gioco una organizzazione terza. Questa autorità mantiene

l’elenco in cui ogni per ogni partecipante c’è la chiave pubblica con associato il nome della

persona che ha quella chiave pubblica. questo ci garantisce che il nome sia corretto perché

l’assegnazione della chiave pubblica con nome avviene mediante un meccanismo di

verifica sicuro a priori. Ogni partecipante a questo elenco può sostituire la chiave che ha

comunicato in qualunque momento. La vulnerabilità qui è che se l’autorità che gestisce

l’elenco viene violata, a quel punto tutto ciò che faceva l’autorità lo può fare l’attaccante;

l’attaccante cosi può modificare l’elenco e può ascoltare tutte le comunicazioni tra l’autorità

che detiene l’elenco e i partecipanti.

- Ricorso ad una autorità: l’autorità che gestiva semplicemente l’elenco, può entrare in gioco

in maniera più diretta. In questo caso non c’è più un elenco consultabile, ma di volta in volta

in una comunicazione con la persona che vuole mettere una chiave pubblica (oppure che

vuole recuperarla) si innesta una comunicazione che viene cifrata con la chiave privata

dell’autority e che quindi può essere decifrata con la sua chiave pubblica. in questa

maniera non c’è più un meccanismo di lettura ma c’è un meccanismo di richiesta/risposta in

cui l’autorità fa da server che utilizza la sua chiave privata.

- Utilizzo di certificati: qui c’è sempre l’autorità ma il vantaggio di questo schema è che non

si deve ogni volta invocare l’autorità per farci dare la chiave pubblica; l’utilizzo dell’autorità

può essere considerata come un collo di bottiglia perché deve essere invocata ogni volta

che serve una chiave pubblica di qualcuno e , visto che la chiave pubblica può ambiare,

ogni volta che bisogna comunicare con qualcuno si deve richiedere la chiave pubblica. Per

ris