Gestione di distribuzione delle chiavi

Gestione e distribuzione delle chiavi

L'obiettivo è che le due parti condividano una chiave e che altri al di fuori di quelle due parti non possano vederla. C'è anche una possibilità di consegnare le chiavi ad una terza parte affidabile.

Da notare che per la cifratura simmetrica c'è il problema della conoscenza della chiave. Ci deve inoltre essere un meccanismo di salvaguardia per cambiare periodicamente le chiavi in caso di un attacco.

Distribuzione di chiavi simmetriche

Per la distribuzione di chiavi simmetriche possiamo pensare a diverse possibilità affinché A e B condividano la chiave:

• L'operazione parte da A, A decide la chiave e fisicamente la consegna a B;
• Ci sta una terza parte che decide la chiave e la comunica sia ad A che a B;
• A e B abbiano precedentemente usato una chiave, e si cifra la nuova chiave usando la vecchia chiave; questa possibilità si basa sul fatto che già è stata condivisa una chiave;
• Ci sta una terza parte C dove c'è un canale di comunicazione reso sicuro dalla cifratura e si usa questo canale per mandare la chiave ad A e B.

Se abbiamo un certo numero di utenti coinvolti n e se per ogni coppia dobbiamo generare una chiave condivisa, il numero di chiavi che si devono generare è pari al numero di coppie che cresce al quadrato di n.

Gerarchia di chiavi

È stato pensato di semplificare la gestione delle chiavi creando una gerarchia di chiavi; ci sono delle chiavi chiamate Master (che non cambiano e sono sicure a priori) che permettono di ottenere le chiavi di sessione (usate per una sola comunicazione); lo scenario che si ha usando una terza parte per la distribuzione delle chiavi è il seguente:

La terza parte è chiamata KDC (centro di distribuzione delle chiavi). Nella comunicazione tra A e B c'è una delle due parti che inizia il processo perché deve mandare dei dati all'altra parte. La prima cosa che fa A è di effettuare una richiesta al KDC; quello che manda è l'ID sia di se stesso e sia del suo corrispondente con cui vuole fare la comunicazione ed un nonce.

Il KDC genera le chiavi che devono essere mandate; questo si basa sul fatto che sia A e sia B abbiano delle proprie chiavi master invia ad A (Ka e Kb). Nota: le chiavi master sono attributi del particolare utente e non della coppia. Queste chiavi master però sono note al centro.

A questo punto il KDC manda un messaggio ad A e lo cifra con la chiave master di A (così solo A può andare a leggerlo); questo messaggio è composto da due parti: una è effettivamente diretta ad A e l'altra è diretta a B; quindi cifra con la chiave di A (Ks è la chiave di sessione temporanea), gli rimanda gli ID di A e B e gli rimanda il nonce (queste informazioni gli vengono rimandate perché sono un riscontro a quanto lui ha mandato e dicono a quale richiesta si riferisce).

La seconda parte contiene un'informazione che è cifrata ed è diretta a B ed è una quantità cifrata con la chiave master di B e che è formata dalla chiave di sessione di prima e l'identificatore di A; quindi questa seconda parte ha una doppia cifratura: si cifra con Kb perché si vuole che solo B sia in grado di leggerla e la si cifra anche con Ka perché si vuole che solamente Ka sia in grado poi di estrarla per mandarla così com'è a B.

A questo punto A manda a B la seconda parte di informazione che ha ricevuto dal Centro. Adesso B, avendo ricevuto queste informazioni, può mandare ad A un secondo nonce cifrato già con la chiave di sessione. Il nonce fa da conferma che ha ricevuto il messaggio. A questo punto A manda a B una funzione del nonce sempre cifrata con la chiave di sessione. A questo punto la comunicazione può iniziare.

Vantaggi e svantaggi

Il vantaggio di fare questo è che non abbiamo più bisogno di n chiavi, ma di tante chiavi master quanti sono gli utenti. 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 un 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.

Generazione di una connessione sicura

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 un'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...