Progetto, analisi ed implementazione di un protocollo di scambio chiavi basato su crittograa simmetrica

Vincenzo Maone 8 gennaio 2012

Specica del protocollo

Questo documento descrive un protocollo di key estabilishment basato su crittograa asimmetrica. Il protocollo concepito per essere impiegato nella costruzione di applicazioni distribuite basate sul modello client-server. I principali coinvolti nello scambio sono due: il client C, il quale eettua una richiesta di servizio al server il server S , il quale soddisfa le richieste dei client Si ipotizza lesistenza di una chiave segreta condivisa a lungo termine KCS tra ogni client C e ciascun server con cui C vuole comunicare. Si suppone inoltre ci sia una situazione di mutual trust tra ogni coppia client-server per cui esiste una chiave segreta condivisa. Ci comporta che C ed S hanno ducia luno nellaltro nella capacit di gestire le chiavi segrete condivise. Alla luce di queste premesse, sono di seguito specicati gli obiettivi che il protocollo si propone di raggiungere, una volta portato a termine: 1. implicit key authentication: C ed S stabiliscono un segreto condiviso KT , la chiave di sessione, che questi ultimi potranno usare per lespletamento del servizio 2. key conrmation: C ottiene una prova del fatto che S conosce la chiave di sessione, e viceversa 3. key freshness: C ed S ottengono una prova della freschezza della chiave di sessione scambiata Come ulteriore requisito, la chiave di sessione deve essere generata dal server S.

2 Il protocollo qui di seguito schematicamente descritto: M1 : C S M2 : C S M3 : C S C, S , NC S , {C, NC , NS , KT }KCS C, {S , NS }KT

Il messaggio M1 viene inviato in chiaro dal client per segnalare al server la sua volont del client stesso di iniziare il protocollo. Oltre agli identicatori di client e server, contiene la quantit NC , che un nonce generato dal client, utile per il perseguimento degli obiettivi del protocollo. Il messaggio M2 contiene, oltre allidenticatore in chiaro del mittente, un testo cifrato con la chiave KCS contenente la chiave di sessione KT ed un nonce NS generati dal server. Alla ricezione di questo messaggio il client viene a conoscenza della chiave di sessione ed autentica il server. Il messaggio M3 contiene, oltre allidenticatore in chiaro del mittente, un testo cifrato con la chiave di sessione KT appena generata contentente il nonce NS generato dal server. Alla ricezione di questo messaggio il server autentica il client ed ottiene conferma che questultimo eettivamente a conoscenza della chiave. Si noti come ogni esecuzione del protocollo espone un solo messaggio cifrato con la chiave a lungo termine KCS . Tale messaggio contiene, tra le altre cose, le quantit NS e KT , che non vengono mai inviate in chiaro e il cui tempo di vita si esaurisce con lespletamento del servizio 1 . Ci riduce le possibilit per un attaccante di montare degli attacchi di tipo known-plaintext. I testi cifrati nei messaggi M2 ed M3 contengono anche lidenticatore del destinatario del messaggio. Laggiunta di tali identicatori serve a ridurre le potenzialit dellattaccante di eettuare replay dei messaggi o parti di essi.

Le suddette quantit, pertanto, possono e dovrebbero essere distrutte subito dopo luso

Analisi del protocollo

In questa sezione si analizzer, utilizzando la logica BAN, il protocollo specicato nella sezione precedente.

Obiettivi
Nella seguente tabella sono indicati, in termini di belief, gli obiettivi che il protocollo si propone di raggiungere (cfr. sezione ). C key authentication key conrmation key freshness C | C S C | S | C S C | C S
KT KT KT

S S | C S S | C | C S S | C S
KT KT KT

Come si pu osservare, il protocollo simmetrico negli obiettivi, fornendo key authentication, key conrmation e key freshness ed entrambi i principali.

Protocollo idealizzato
Viene di seguito riportata la la versione idealizzata del protocollo, conforme a quanto esposto nella sezione relativamente al signicato dei messaggi. M2 : C S M3 : C S NC , NS , C S , NS , C S
KT KT KT

C S
KCS

KT

Essendo M1 in chiaro, esso non pu contribuire alla nascita di belief da parte del ricevente. Per questo motivo M1 non stato riportato nel protocollo idealizzato.

Ipotesi
Le ipotesi alla base del protocollo, elencate qui di seguito, rispecchiano lipotesi di mutual trust e tengono conto del fatto che il server S a generare la chiave di sessione. H1 : H2 : H3 : H4 : H5 : H6 : H7 : H8 : C | C S S | C S S | C S C | S C S S | C | S C S C S C | (NC ) S | (NS )
KT KT KT KT KCS KCS

Oltre alle ipotesi H1 H4 , le quali derivano direttamente dalle assunzioni fatte nora, sono state aggiunte le ulteriori ipotesi H5 H8 , le quali presumono che C ed S siano competenti nel generare le quantit fresche necessarie (NC , NS e KT ). Si osservi che le ipotesi H3 ed H5 coincidono rispettivamente con gli obiettivi di key authentication e key freshness per S : ci dovuto al fatto che il server S a generare da solo una chiave segreta di sessione. Nella successiva sessione verr dimostrato come il protocollo raggiunga i rimanenti obiettivi.

Analisi
A partire dai belief iniziali esposti nella sezione precedente, si procede con lanalisi della versione idealizzata del protocollo. Il messaggio M2 M2 : C S NC , NS , C S ,
KT

C S
KCS

KT

inviato da S lecito in base alle ipotesi H3 ed H5 2 . Alla ricezione di M2 , C espande i suoi belief come segue.
2

Un principale pu infatti trasmettere solo belief in cui crede

5 Per la message meaning rule applicata allipotesi H1 : C | C S , C

KCS

NC , NS , C S ,
KT

KT

C S
KCS KT

KT

C | S | NC , NS , C S , ed inoltre, poich vale la H7 C | (NC ) C | NC , NS , C S ,

KT

C S

C S

KT

e quindi C crede nella freschezza della quantit KT , che scoprir successivamente essere la chiave di sessione (key freshness). Di conseguenza, per la nonce verication rule applicata agli ultimi due belief ottenuti C | C S , C | S | C S
KT KT KT

C | S | C S che fornisce key conrmation a C. Applicando quindi la jurisdiction rule, per lipotesi H4 C | S | C S , C | S C S C | C S che fornisce key authentication a C. In maniera analoga C | C S C | S |
KT KT KT KT

, C | S | C S
KT

C S

KT

e quindi, ancora per la jurisdiction rule, con lipotesi H6 C | S | C S , C | S C | che fornische key freshness a C. Dopo la ricezione del messaggio M3 M3 : C S NS , C S
KT KT KT

C S

KT

C S

KT

6 S espande i suoi belief come segue. Per la message meaning rule applicata allipotesi H2 : S | C S , S
KT

NS , C S
KT

KT

KT

S | C | NS , C S Poich vale la H5 , per la nonce verication rule S | C S , S | C | C S S | C | C S e quindi S ottiene key conrmation.
KT KT KT

Considerazioni sullanalisi
Alla luce dellanalisi eettuata nel paragrafo precedente, si nota come lipotesi H8 non venga mai utilizzata. Cinonostante gli obiettivi del protocollo vengono raggiunti. In eetti lutilizzo del nonce NS ridondante, in quanto di fatto la chiave di sessione stessa KT , che non viene ovviamente trasmessa in chiaro, funge da nonce nello scambio challenge-response incluso nei messaggi M2 ed M3 . Il protocollo potrebbe dunque essere semplicato nel modo seguente M1 : C S M2 : C S M3 : C S C, S , NC S , {C, NC , KT }KCS C, {S }KT

rimanendo valida lanalisi in logica BAN (con i dovuti piccoli cambiamenti legati alleliminazione del nonce NS ). Nonostante ci, il nonce NS viene mantenuto per aumentare in pratica la robustezza del protocollo. In caso contrario, se il server S generasse in futuro una chiave di sessione gi generata in una esecuzione passata del protocollo 3 , un attaccante potrebbe accorgersene facilmente, semplicemente controllando che i messaggi M3 coincidano. Se lattaccante anche riuscito in qualche modo a estrarre la chiave di sessione dalla comunicazione passata, allora anche in grado di attaccare la comunicazione corrente, sia attivamente che passivamente. A questo proposito, poich
3

ci pu essere dovuto alle caratteristiche del generatore di numeri casuali o pi semplicemente

allesaurimento dello spazio delle chiavi

7 la chiave di sessione concepita per fornire condenzialit nei limiti temporali dellespletamento del servizio tra C ed S, la si potrebbe utilizzare congiuntamente ad algoritmo crittograco pi veloce, ma meno resistente ad attacchi al cifrario4 . Di conseguenza potrebbe non essere troppo dicile per un attaccante dotato di mezzi opportuni e tempo suciente riuscire a recuperare una chiave di sessione passata. La possibilit che un attaccante monti lattacco appena descritto cala drasticamente se il nonce NS viene mantenuto. In questo caso, infatti, il messaggio M3 sporcato dalla quantit casuale NS . Anche se una chiave di sessione passata dovessere essere riutilizzata, lattaccante non potrebbe accorgersene avento a disposizione solamente M3 .

Fermo restando che la chiave a lungo termine venga utilizzata con un algoritmo di crittograa

diverso, pi resistente e pi lento.

Implementazione
Il protocollo stato implementato in C++ utilizzando la primitive crittograche oerte dalle librerie OpenSSL (http://www.openssl.org). In particolare stato utilizzato il cifrario simmetrico DES, in modalit EBC, per cifrare sia con la chiave segreta a lungo termine, sia con la chiave di sessione. Per semplicare la fase di codica, le funzionalit di openSSL utilizzate sono state opportunamente innestate in alcune classi wrapper, perch potessero fornire una interfaccia orientata agli oggetti. Sono stati realizzati un esempio di programma client ed un esempio di programma server. Dopo aver eseguito il protocollo, il client invia al server un le cifrandolo con la chiave di sessione ottenuta da questultimo. Per garantire lintegrit del le inviato, viene calcolato ed inviato un digest del le, grazie alla funzione hash SHA1 (fornita dalle librerie openSSL). Per eettuare le prove, decomprimere e poi scompattare il le progetto_sicurezza_427807.tar.gz in una directory. Lanciare il comando make all nella stessa directory per compilare sia client che server. A questo punto saranno disponibili i le server e client, che implementano rispettivamente il server ed il client di esempio. Il server in ascolto sullindirizzo 127.0.0.1 (localhost) sulla porta 32002, e deve essere lanciato senza parametri a linea di comando. Il client accetta come unico parametro il percorso del le che si desidera spedire. Il server salva il le ricevuto nella sua directory corrente, sotto il nome fileReicevuto.txt .