Sei sulla pagina 1di 9

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

Vincenzo Maone

8 gennaio 2012

Specifica del protocollo

Questo documento descrive un protocollo di key estabilishment basato su crittogra- fia 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 l’esistenza di una chiave segreta condivisa a lungo termine K CS 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 fiducia l’uno nell’altro nella capacità di gestire le chiavi segrete condivise. Alla luce di queste premesse, sono di seguito specificati gli obiettivi che il proto- collo si propone di raggiungere, una volta portato a termine:

1. implicit key authentication: C ed S stabiliscono un segreto condiviso K T , la chiave di sessione, che questi ultimi potranno usare per l’espletamento del servizio

2. key confirmation: 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.

1

2

Il

protocollo è qui di seguito schematicamente descritto:

 

M 1 :

C

S

C, S, N C

M 2 : C

S

S, {C, N C , N S , K T } K CS

M 3 :

C S

C, {S, N S } K T

Il

messaggio M 1 viene inviato in chiaro dal client per segnalare al server la sua

volontà del client stesso di iniziare il protocollo. Oltre agli identificatori di client

e server, contiene la quantità N C , che è un nonce generato dal client, utile per il perseguimento degli obiettivi del protocollo.

Il messaggio M 2 contiene, oltre all’identificatore in chiaro del mittente, un testo

cifrato con la chiave K CS contenente la chiave di sessione K T ed un nonce N S generati dal server. Alla ricezione di questo messaggio il client viene a conoscenza della chiave di sessione ed autentica il server.

Il messaggio M 3 contiene, oltre all’identificatore in chiaro del mittente, un testo

cifrato con la chiave di sessione K T appena generata contentente il nonce N S ge-

nerato dal server. Alla ricezione di questo messaggio il server autentica il client ed ottiene conferma che quest’ultimo è eettivamente a conoscenza della chiave. Si noti come ogni esecuzione del protocollo espone un solo messaggio cifrato con

la chiave a lungo termine K CS . Tale messaggio contiene, tra le altre cose, le quan-

tità N S e K T , che non vengono mai inviate in chiaro e il cui tempo di vita si esauri- sce con l’espletamento del servizio 1 . Ciò riduce le possibilità per un attaccante di montare degli attacchi di tipo known-plaintext. I testi cifrati nei messaggi M 2 ed M 3 contengono anche l’identificatore del destina- tario del messaggio. L’aggiunta di tali identificatori serve a ridurre le potenzialità dell’attaccante di eettuare replay dei messaggi o parti di essi.

1 Le suddette quantità, pertanto, possono e dovrebbero essere distrutte subito dopo l’uso

Analisi del protocollo

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

Obiettivi

Nella seguente tabella sono indicati, in termini di belief, gli obiettivi che il proto- collo si propone di raggiungere (cfr. sezione ).

 

C

 

S

key authentication

K

T

C|≡C ←→ S

 

K

T

S |≡C ←→ S

key confirmation

K

T

C|≡S |≡C ←→ S

S

K

T

|≡C|≡C ←→ S

key freshness

C|≡ C ←→ S

K

T

S

|≡ C ←→ S

K

T

Come si può osservare, il protocollo è simmetrico negli obiettivi, fornendo key authentication, key confirmation 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 significato dei messaggi.

M 2 : C S

M 3 : C S

N C , N S ,C ←→ S, C ←→ S K CS

K

T

K

T

N S ,C ←→ S K T

K

T

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

3

4

Ipotesi

Le ipotesi alla base del protocollo, elencate qui di seguito, rispecchiano l’ipotesi

di mutual trust e tengono conto del fatto che è il server S a generare la chiave di

sessione.

H 1 :

H 2 :

H 3 :

H 4 :

H 5 :

H 6 :

H 7 :

H 8 :

K

CS

C|≡C ←−→ S

K

CS

S |≡C ←−→ S

K

T

S |≡C ←→ S

K

T

C|≡S C ←→ S

S |≡ C ←→ S

K

T

C|≡S C ←→ S

K

T

C|≡ (N C ) S |≡ (N S )

Oltre alle ipotesi H 1 H 4 , le quali derivano direttamente dalle assunzioni fatte

finora, sono state aggiunte le ulteriori ipotesi H 5 H 8 , le quali presumono che C

ed

S siano competenti nel generare le quantità fresche necessarie (N C , N S e K T ).

Si

osservi che le ipotesi H 3 ed H 5 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 l’analisi

della versione idealizzata del protocollo. Il messaggio M 2

M 2 : C S

N C , N S ,C ←→ S, C ←→ S K CS

K

T

K

T

inviato da S è lecito in base alle ipotesi H 3 ed H 5 2 . Alla ricezione di M 2 , 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 all’ipotesi H 1 :

C|≡C ←−→ S, C N C , N S ,C ←→ S, C ←→ S K CS

K

CS

K

T

K

T

C|≡S |∼ N C , N S ,C ←→ S, C ←→ S

K

T

K

T

ed inoltre, poichè vale la H 7

C|≡ (N C )

C|≡ N C , N S ,C ←→ S, C ←→ S

K

T

K

T

e quindi C crede nella freschezza della quantità K T , che scoprirà successivamente

essere la chiave di sessione (key freshness).

Di conseguenza, per la nonce verification rule applicata agli ultimi due belief

ottenuti

C|≡ C

←→ S , C|≡S |∼C ←→ S

K T

K

T

K T

C|≡S |≡C ←→ S che fornisce key confirmation a C.

Applicando quindi la jurisdiction rule, per l’ipotesi H 4

K

T

K

T

C|≡S |≡C ←→ S, C|≡S C ←→ S

K T

C|≡C ←→ S

che fornisce key authentication a C.

In maniera analoga

C|≡ C ←→ S , C|≡S |∼ C ←→ S

K

T

K

T

C|≡S |≡ C ←→ S

K

T

e quindi, ancora per la jurisdiction rule, con l’ipotesi H 6

C|≡S |≡ C ←→ S , C|≡S C ←→ S

K

T

K

T

C|≡ C ←→ S

K

T

che fornische key freshness a C.

Dopo la ricezione del messaggio M 3

M 3 : C S

N S ,C ←→ S K T

K

T

6

S espande i suoi belief come segue.

Per la message meaning rule applicata all’ipotesi H 2 :

S |≡C ←→ S, S N S ,C ←→ S K T

K

T

K

T

K T

S |≡C|∼ N S ,C ←→ S

Poichè vale la H 5 , per la nonce verification rule

S |≡ C ←→ S , S

K

T

K

T

|≡C|∼C ←→ S

K T

S |≡C|≡C ←→ S

e quindi S ottiene key confirmation.

Considerazioni sull’analisi

Alla luce dell’analisi eettuata nel paragrafo precedente, si nota come l’ipotesi

H 8 non venga mai utilizzata. Ciònonostante gli obiettivi del protocollo vengono

raggiunti. In eetti l’utilizzo del nonce N S è ridondante, in quanto di fatto la chiave

di sessione stessa K T , che non viene ovviamente trasmessa in chiaro, funge da

nonce nello scambio challenge-response incluso nei messaggi M 2 ed M 3 .

Il protocollo potrebbe dunque essere semplificato nel modo seguente

M 1 :

C

S

C, S, N C

M 2 : C

S

S, {C, N C , K T } K CS

M 3 :

C S

C, {S} K T

rimanendo valida l’analisi in logica BAN (con i dovuti piccoli cambiamenti legati

all’eliminazione del nonce N S ).

Nonostante ciò, il nonce N S viene mantenuto per aumentare in pratica la robustez-

za

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 M 3

coincidano. Se l’attaccante è anche riuscito in qualche modo a estrarre la chiave di

sessione dalla comunicazione passata, allora è anche in grado di attaccare la comu-

nicazione corrente, sia attivamente che passivamente. A questo proposito, poiché

3 ciò può essere dovuto alle caratteristiche del generatore di numeri casuali o più semplicemente all’esaurimento dello spazio delle chiavi

7

la chiave di sessione è concepita per fornire confidenzialità nei limiti temporali del- l’espletamento del servizio tra C ed S, la si potrebbe utilizzare congiuntamente ad algoritmo crittografico più veloce, ma meno resistente ad attacchi al cifrario 4 . 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 l’attacco appena descritto cala drasticamente se il nonce N S viene mantenuto. In questo caso, infatti, il messaggio M 3 è spor- cato dalla quantità casuale N S . Anche se una chiave di sessione passata dovessere essere riutilizzata, l’attaccante non potrebbe accorgersene avento a disposizione solamente M 3 .

4 Fermo restando che la chiave a lungo termine venga utilizzata con un algoritmo di crittografia diverso, più resistente e più lento.

Implementazione

Il protocollo è stato implementato in C++ utilizzando la primitive crittografiche 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 semplificare la fase di codifica, 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 file cifrandolo con la chiave di sessione ottenuta da quest’ultimo. Per garantire l’integrità del file inviato, viene calcolato ed inviato un digest del file, grazie alla funzione hash SHA1 (fornita dalle librerie openSSL). Per eettuare le prove, decomprimere e poi scompattare il file progetto_sicurezza_427807.tar.gz in una directory. Lanciare il comando make all nella stessa directory per com- pilare sia client che server. A questo punto saranno disponibili i file server e client, che implementano rispettivamente il server ed il client di esempio. Il server è in ascolto sull’indirizzo 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 file che si desidera spedire. Il server salva il file ricevuto nella sua directory corrente, sotto il nome ¨ fileReicevuto.txt ¨ .

8