Di Salvatore Valerio

Lo scambio delle chiavi  - con operazioni manuali

Uno dei più importanti aspetti nel creare una VPN sicura riguarda la gestione e lo scambio delle chiavi. Le chiavi una volta create devono essere scambiate tra i pari partecipanti per poter instaurare un canale sicuro. Lo scopo di scambiarsi le chiavi segrete è quello di assicurare delle comunicazioni a prova di intercettazione. Solo se, le chiavi sono conosciute “solamente” dalla sorgente e dalla destinazione, è possibile fornire un canale di comunicazione sicuro. Ma, il mero atto di scambiarsi le chiavi su un canale insicuro espone le chiavi ad un potenziale attaccante che può comprometterle. È quindi importante realizzare dei metodi “sicuri” per scambiarsi le chiavi. Questi metodi risolvono il problema di come scambiarsi le chiavi in sicurezza.

Uno dei metodi di scambio delle chiavi è quello manuale. Cioè, gli utenti si incontrano personalmente oppure si scambiano le chiavi su un canale sicuro “differente” da quello insicuro che verrà utilizzato.

Questo metodo di scambio viene chiamato in gergo “Out-of-band” cioè, viene usato un canale di comunicazione separato per trasferire le chiavi. In genere questi canali “sicuri” Out-of-band  sono molto più “costosi” dei canali che verranno effettivamente usati è vengono utilizzati solo per lo scambio delle chiavi. Dopo lo scambio queste chiavi devono essere configurate manualmente sul sistema per poter permettere l’instaurazione di un canale sicuro.

Queste tecniche di gestione, di scambio e di inserimento manuale delle chiavi possono andare bene in un piccolo ambiente di rete statico dove i vari utenti si trovano sotto controllo di una singola amministrazione e/o magari dove  c’è una politica di configurare le chiavi in modo statico ma, hanno i gravi difetti di essere soggette ad errori ( solitamente di digitazione ma, non solo), di essere vulnerabili ad alcuni tipi di attacchi e di non essere usabili in ambienti vasti e dinamici e cioè, di non scalare bene. 

Quindi è necessario utilizzare altre tecniche automatiche di scambio per negoziare i parametri e le chiavi on-line.

Lo scambio della chiavi – con l'algoritmo di scambio Diffie-Hellman 

Diversi standard sono emersi per proteggere la segretezza delle chiavi e per facilitare lo scambio di queste chiavi su un canale insicuro in sicurezza. L’algoritmo di scambio Diffie-Hellman implementa lo scambio delle chiavi senza che sul canale insicuro vengano realmente scambiate le chiavi. Questo l'algoritmo è estesamente usato per stabilire una sessione adatta a cifrare i dati.

L'algoritmo Diffie-Hellman (RFC 2631) offre un modo sicuro per due utenti, Alice e Bob, di stabilire una chiave segreta condivisa che solamente loro conoscono. La chiave segreta condivisa può essere stabilita anche se gli utenti Alice e Bob stanno comunicando su un canale insicuro. Questa chiave segreta è usata poi per cifrare i dati usando l’algoritmo di cifratura della chiave segreta selezionato da Alice e Bob.  I Due pari generano dei numeri primi Alice p e Bob q, composti da 200 o 300 cifre almeno (lunghezza stabilita in base al Gruppo D-H di appartenenza) e vengono condivisi e scambiati sul canale insicuro. Con questi numeri ogni pari (Alice e Bob) generano un numero "g", un numero minore di  "p" e "q", con alcune restrizioni.  

A questo punto Alice e Bob generano ognuno un grande numero casuale che viene tenuto segreto, chiamato "XA" e "XB".

Con questo numero casuale viene generato dai pari una chiave pubblica YA e YB. Ognuno con la rispettiva formula YA =  g ^ (esponente di) XA mod p per Alice e YB =  g ^ (esponente di) XB mod p per Bob. Il risultato YA e YB vengono scambiati tra i pari sul canale insicuro.

A questo punto viene generato un segreto condiviso tra i pari che è un numero ricavato dalla seguente formula ZZ = YB^ (esponente di) XA mod p  per Alice e ZZ = YA^ (esponente di) XB mod p  per Bob. Cioè, il numero condiviso tra i pari ZZ è uguale sia per Alice che per Bob. L'algoritmo di scambio Diffie-Hellman che permette di condividere un segreto (la chiave ZZ ) senza scambiarlo realmente sul canale insicuro ora è realizzato.

È importante notare che Alice e Bob non hanno un metodo per determinare l'un l'altro l'identità. Lo scambio è vulnerabile ad un attacco man-in-the-middle. L’algoritmo Diffie-Hellman provvede a fornire la riservatezza ma non provvede a fornire l'autenticazione. L'autenticazione viene realizzata dall'uso di firme digitali nello scambio dei messaggi Diffie-Hellman. 

I Diffie-Hellmann Group sono valori che specificano il tipo di generatore di cifratura (modulus per [MODP] o la grandezza del campo di Galois per la curva ellittica [EC2N]). Questi gruppi D-H specificano inoltre la lunghezza base dei numeri primi (che sono il materiale base) usato per generare il segreto condiviso. Più è grande il numero del gruppo D-H più sono grandi i numeri primi utilizzati.

Attualmente sono definiti 10 gruppi. La RFC 2409 definisce i gruppi da 1 a 4. La  RFC 3526, definisce il gruppo 5 e i gruppi da 14 a 18. Più si sale di gruppo maggiore è la forza crittografica delle chiavi ricavate. La forza crittografica di ogni chiave così generata dipende, in parte, dalla forza del gruppo Diffie-Hellmann sulla quale i numeri primi sono basati. La scelta di un gruppo Diffie-Hellman molto grande può aumentare di molto il tempo di processamento dei pacchetti.

Lo scambio delle chiavi  pubbliche mediante Certificate Autority

Quando vengono scambiate le chiavi pubbliche come fanno gli utenti ad avere la certezza che la chiave pubblica ricevuta sia autentica? Cioè, che appartenga veramente all’entità con cui si vuole comunicare?

È infatti possibile per un pirata informatico impersonare un utente legittimo (BOB) (attacco man-in-the-middle) ed inviare ad Alice una falsa chiave pubblica, così da decifrare i messaggi che Alice cifra con tale chiave.

È importante essere certi dell’identità del soggetto possessore della chiave pubblica. Con il semplice scambio delle chiavi pubbliche è possibile che NON si stia comunicando con chi crediamo di comunicare.

È necessario quindi che per risolvere questo problema, ci sia una parte terza agli utenti gerarchicamente superiore che garantisca sulla corrispondenza tra un utente e la sua coppia di chiavi asimmetriche PKI (Public Key Infrastructure).

Una Certification Authority (CA) è una “parte terza” agli utenti (Alice e Bob). Questa particolare entità viene riconosciuta dagli utenti come una parte “fidata” a loro gerarchicamente superiore. La CA offre un servizio utile a creare e garantire “fiducia” fra gli utenti. La CA crea, assegna, rilascia, sospende e revoca “certificati digitali”.   

I certificati digitali

I certificati digitali sono degli oggetti informatici conformi allo standard ITU-T X.509v3  RFC  2510 e 3280 che garantiscono valore legale alle firme digitali, attraverso l’assicurazione della corrispondenza tra un determinato paio di chiavi asimmetriche e un particolare utente o apparecchiatura. Il certificato digitale è strettamente associato alla coppia di chiavi Pubblica/Privata e all’entità a cui si riferisce (Alice / Bob) o all’apparecchiatura e contiene una serie di dati identificativi dell’utente o dell’apparecchiatura, come il nome, il numero seriale, o l’indirizzo IP e della chiave pubblica più una serie di campi opzionali.

La CA rilascia il certificato digitale dopo un processo chiamato “procedura di certificazione” che serve a dare garanzie sulla autenticità, sulla corrispondenza fra le chiavi e il suo possessore. L’utente o l’apparecchiatura, in questo caso Alice dopo avere generato la sua coppia di chiavi Pubblica/Privata chiede alla CA di certificare la sua chiave pubblica. La CA o per lei la RA (Registration Autority) che è una emanazione amministrativa della CA realizzata per alleggerirne il lavoro.

Esegue una “procedura di identificazione” e identificando Alice come la proprietaria di una coppia di chiavi asimmetriche ne verifica la corrispondenza. A questo punto la RA  chiede alla CA di generare un certificato digitale per Alice e la sua chiave pubblica.  Il certificato dell’utente Alice viene firmato dalla CA con un suo certificato digitale chiamato “Root CA” che è auto–certificato (self–signed).

La CA con il suo proprio certificato digitale, che è un certificato particolarmente robusto, firma i certificati digitali degli utenti autenticandoli e garantendo per la loro corrispondenza ad una particolare identità.  La CA pubblicherà su un particolare server pubblico chiamato “Certificate Server” liberamente accessibile, una lista dei certificati in corso di validità o con l’indicazione se questi certificati sono revocati o sospesi . In realtà le liste pubblicate sul Certificate Server sono di tre tipi e i certificati revocati e sospesi sono rispettivamente pubblicati nelle liste CRL (Certificate Revocation List) e CSL (Certificate Suspension List). L’utente Alice a questo punto riceve dalla CA un proprio certificato digitale firmato + il certificato digitale “Root” (self-signed) della CA.

Ogni volta che Alice invierà la sua chiave pubblica, allegherà il proprio certificato digitale oppure un numero seriale dello stesso.

La struttura di un certificato digitale

La struttura di un certificato digitale X.509 v3 mostrata sotto è formata da attributi ed estensioni:

- Attributi del certificato digitale

o        Versione : numero di versione del certificato che attualmente è la 3.

o        Serial Number : numero seriale del certificato che identifica il certificato in modo univoco all’interno della CA.

o        Firma : Identificativo dell'algoritmo usato dalla CA per firmare il certificato.

o        Issuer : questo campo identifica le entità che hanno firmato ed emesso il certificato.  Questo campo contiene un distiguished name DN e Issuer Distinguished Name.

·        Distinguished Name: identificativo dell’utente suddiviso nelle voci: CN ed E che stanno per nome della Certificate Autority ed Email dell’utente certificato.

·        Issuer Distinguished Name: nello stesso formato del DN, identifica la CA che ha emesso il certificato.

o        Validità (not after, not before) : l’ora e le date di inizio del periodo di validità del certificato.

o        Soggetto : nome

o        Informazioni sulla chiave pubblica del soggetto

·        Algoritmo per l'utilizzo della chiave pubblica

·        Chiave pubblica

-Estensioni (facoltativo) del certificato digitale.

o        CRLDistributionPoint : è un puntatore, un URL del server da dove scaricare la CRL (Certificate Revocation List) relativa ad un particolare certificato.

o        KeyUsage: questo campo dichiara gli scopi per i quali è possibile utilizzare la chiave pubblica (uno o più tra i seguenti):

·        Digital Signature : firma digitale.

·        Key Encipherment : “canale sicuro” per chiavi simmetriche.

·        Non Repudiation : assieme a “Digital Signature” per la firma e per il non ripudio dei documenti.

·        Data Encipherment : cifratura dei dati.

·        CRL e KeyCert Signature : firma di CRL (Certificate Revocation List). e la firma del Certificato della chiave (usato dalla CA).

-Algoritmo di firma del certificato

-Firma del certificato

La verifica

L’utente (Alice) quando invierà la propria chiave pubblica, allegherà il proprio certificato digitale oppure il suo numero di serie. La chiave pubblica dell’utente firmata dal certificato digitale viene pubblicato a cura della CA su un server chiamato “Certificate Server “ liberamente accessibile per le verifiche. Il ricevente (Bob) per verificare la corrispondenza del certificato ricevuto da Alice, scarica dal Certificate Server della CA mediante il numero seriale il certificato corrispondente e lo confronta con quello ricevuto da Alice. Le verifiche vengono eseguite in reciprocità fra Alice e Bob ed eseguite anche in maniera automatica e questo permette di accettare come affidabili tutte le comunicazioni fra i due pari.

Con una CA non è necessario configurare le chiavi su tutti i pari IPsec. Per aggiungere/configurare un nuovo pari IPsec ad una rete è sufficiente richiedere un certificato digitale ad una CA. Le CA forniscono una soluzione di gestire in modo dinamico e altamente scalabile le reti IPsec.

Uno dei metodi automatici di scambio delle chiavi è il protocollo IKE (Internet Key Exchange) che è un sofisticato meccanismo che utilizza le Certificate Autority per poter realizzare lo scambio delle chiavi on-line

Continua.....