Verifica di protocolli di sicurezza crittografici

attraverso i quali determinare se un dato protocollo risponde o meno a certi
requisiti di sicurezza. In particolare verra` descritto l’approccio induttivo
dovuto a Laurence Paulson.
Nella seconda parte verra` data la definizione di protocollo di seconda
generazione, e verra` affrontato il problema di come formalizzare tali proto-
colli nel modello induttivo. Come rappresentante di tale classe di protocolli
verra` presentato un protocollo di e-mail certificata. Oltre a rivestire un par-
ticolare interesse per la sua natura di protocollo di seconda generazione, tale
protocollo ci dara` modo di discutere le problematiche nella formalizzazione e
nella verifica di protocolli che soddisfano requisiti di non repudiabilita`. Verra`
infatti presentata la formalizzazione di tale protocollo e la verifica delle sue
proprieta`. Infine verranno presentate alcune varianti di tale protocollo che
intendono garantire proprieta` non garantite dal protocollo stesso.
5
Capitolo 2
Protocolli di sicurezza
L’avvento di Internet ha messo in risalto alcune problematiche riguardanti la
comunicazione e l’esecuzione dei protocolli di comunicazione. La topologia
della rete permette infatti di intercettare i messaggi che intercorrono tra due
agenti. In oltre a priori e` impossibile stabilire con certezza il mittente di un
messagggio. Tali debolezze possono venire sfruttate da utenti maliziosi per
gli scopi piu` diversi.
2.1 Obbiettivi dei protocolli di sicurezza
In generale un protocollo e` detto protocollo di sicurezza se raggiunge almeno
uno dei seguenti obbiettivi :
2.1.1 Confidenzialita`
Dato un messaggio m, un insieme di agenti S ed un protocollo
P, si dice che P gode della proprieta` di confidenzialita` rispetto
al messaggio m ed all’insieme di agenti S se, nell’ipotesi che il
messaggio m prima dell’esecuzione di P sia noto alpiu` a tutti gli
agenti compresi in S e a nessun altro, tale ipotesi sia verificata
anche dopo l’esecuzione di P.
Esaminiamo nel dettaglio le varie parti dell’enunciato, definendo innanz-
itutto la natura dell’insieme S. L’esistenza stessa del messaggio m implica
l’esistenza di un agente A che lo ha generato. Avendolo generato, sicura-
mente A e` a conoscenza del messaggio m. Per tale motivo l’insieme S e` di
certo non vuoto e comprende A. Supponiamo che A, utilizzando il proto-
collo P, intenda spedire un messaggio m agli agenti B, C, D in maniera
6
confidenziale. Al termine dell’esecuzione del protocollo non deve esistere
nessun altro agente, all’infuori di B, C, D ed A stesso, che sia a conoscenza
di m. Se tale proprieta` e` soddisfatta, possiamo affermare che P soddisfa il
requisito di confidenzialita` rispetto al messaggio m ed all’insieme di agenti
{ A, B, C, D }. Non e` necessario che tutti gli agenti compresi in questo
insieme vengano a conoscenza del messaggio. E` necessario che, se un agente
E venga a conoscenza di m, esso sia compreso nell’insieme S. Per questo
motivo, un protocollo che goda della proprieta` di confidenzialita` rispetto
ad un insieme di agenti S, gode di tale proprieta` anche rispetto a tutti gli
insiemi S ′ tali che S sia compreso in S ′.
Esempio di protocollo che gode della proprieta` di confidenzialita`
Esistono vari stumenti studiati per garantire la confidenzialia` di un mes-
saggio. Prendiamo in considerazione un protocollo di esempio che utilizzi
la crittografia per garantire questo requisito. Un algoritmo crittografi-
co trasforma un messaggio m in un’altro messaggio m′, tale che si possa
ricavare da m′ il messaggio originale solo conoscendo un parametro aggiun-
tivo, denominato chiave. Supponiamo allora che l’agente A intenda spedire
in maniera confidenziale un messaggio m all’agente B. A deve occuparsi
innanzitutto di comunicare a B la chiave da utilizzare. Questo puo` avvenire
utilizzando un ulteriore protocollo per la distribuzione di chiavi, o attraverso
un’incontro personale di A e B. La seconda opportunita` non e` remota come
si possa pensare, considerando che tale chiave potrebbe essere utilizzata non
per una singola comunicazione, ma per tutti i messaggi che A intendera`
spedire a B in via confidenziale nel futuro. Sia allora k tale chiave. A
non deve fare altro che codificare il messaggio che intende spedire in modo
tale che possa essere decodificato utilizzando k, e spedirlo a B. Nell’ipotesi
che A e B siano gli unici agenti a conoscenza di tale chiave, nessun altro e`
in grado di risalire al messaggio originale da quello codificato e trasmesso.
Questo protocollo offre garanzia di confidenzialita` rispetto al messaggio m
ed all’insieme di agenti { A , B }.
2.1.2 Autenticita`
Dato un messaggio m, un protocollo P, si dice che P offre ad un
agente A garanzia di autenticita` rispetto al messaggio m se A e`
in grado di determinare chi ha generato tale messaggio.
La necessita` di protocolli che soddisfino un requisito di questo genere
nasce direttamente dalle imperfezioni delle reti. In una rete LAN e simil-
7
mente su internet, il mittente del messaggio viene inserito nell’intestazione
del messaggio da chi lo invia, dandogli modo potenzialmente di spacciarsi
per chiunque. Su internet il trasporto di un messaggio da mittente e desti-
natario avviene attraverso una serie di nodi intermedi. Nulla vieta ad uno di
questi di modificare l’intestazione di un messaggio prima di trasmetterlo al
nodo successivo lungo il percorso. Queste considerazioni rendono evidente
il fatto che nessuna garanzia puo` essere data sul mittente di un messaggio.
Tuttavia il requisito di autenticita` offre garanzie in merito all’agente che ha
generato il messaggio, non in merito al mittente del messaggio. Per gener-
azione di un messaggio si intende il momento nel quale tale messaggio e` stato
immesso sulla rete per la prima volta. Offrire quindi garanzia di autenticita`
di un messaggio ad un agente rispetto ad un messaggio significa fornirgli gli
strumenti per determinare da chi tale messaggio e` stato trasmesso originari-
amente, non se tale messaggio sia stato successivamente riutilizzato da altri.
Affinche` tale requisito possa essere soddisfatto e` necessario che il messaggio
in questione parli in qualche modo di chi lo ha generato, in maniera esplicita
o implicita.
Esempio di protocollo che soddisfa il requisito di autenticita`
Il protocollo mostrato a titolo di esempio per chiarire il concetto di confi-
denzialita` si presta anche come esempio di protocollo che offre il requisito
di autenticita`. Con una precisazione. Indichiamo con {m}k un messaggio
cifrato, tale che sia necessario conoscere k per ricavarne l’originale m. La
funzione utilizzata per ottenere m da {m}k e` detta funzione di decifrazione.
d(k, {m}k) = m
Essa dipende dall’algoritmo crittografico utilizzato, e si suppone che tutti
gli agenti siano in grado di utilizzarla. Essa restituisce un risultato corretto
solo se la chiave utilizzata e` a sua volta corretta. Nel caso in cui venga utiliz-
zata una chiave diversa da quella utilizzata per la cifratura, viene restituito
un messaggio diverso dall’originale.
d(k′, {m}k) = m′
k 6= k′ −→ m 6= m′
Quando un agente riceve un messaggio cifrato {m}k′ , con opportuni ac-
corgimenti e` in genere in grado di determinare se tale messaggio sia stato
8
cifrato o no con una determinata chiave k. Questa capacita` nasce diret-
tamente dalla capacita` di determinare se il risultato dell’operazione di de-
cifrazione sia o no corretto. Supponiamo ad esempio che il destinatario sia in
attesa di un messaggio contenete un testo in lingua italiana. Alla ricezione
di {m}k′ , applica a tale messaggio la funzione di decodifica usando la chiave
k.
d(k, {m}k′) = m′
Se m′ non contiene un testo in italiano, allora sicuramente k′ 6= k. In
oltre, le probabilita` che un utente malizioso riesca, non conoscendo k, a
generare un messaggio m tale che d(k, {m}k′) sia un testo in italiano tendono
a zero al crescere della lunghezza di m. Nel caso in cui non si possano fare
assunzioni cos`i decisive sul contenuto del messaggio, si potrebbe pretendere
che tale messaggio venga accompagnato da una checksum per verificarne la
corretta decodifica.
Supponiamo che un agente B riceva un messaggio {m}k′ , e che esista
una chiave k nota solo ad un altro agente A ed a B stesso. Sia l’agente
B in grado di determinare se il messaggio ricevuto e` o meno un messaggio
cifrato con la chiave k. Nel caso che tale controllo dia esito positivo, essendo
tale chiave nota solo a B e A, tale messaggio e` stato di certo generato da B
oppure da A. B e` ovviamente in grado di determinare se tale messaggio sia o
meno stato generato da egli stesso. In caso contrario di certo tale messaggio
e` stato generato da A.
2.1.3 Unicita`
Dato un messaggio composto
m = {m1,m2,m3, . . . ,mn}
Sia I un insieme di indici compresi fra 1 ed n.
Dato un protocollo P, si dice che P gode della proprieta` di unic-
ita` rispetto al messaggio composto m e all’insieme di indici I
se, per ogni messaggio m′ = {m′1,m′2, ...,m′n} che viene spedito
sulla rete durante lo svolgimento di una sessione del protocollo,
vale il seguente predicato
∀i ∈ I mi = m′i −→ ∀i ∈ {1 . . . n} mi = m′i
Le componenti indicate nell’insieme I caratterizzano univocamente il
messaggio m. Tale insieme e` di solito costituito da un’unico indice che
rappresenta un messaggio atomico in grado da solo di identificare la sessione.
9
Un requisito di questo genere di solito viene infatti utilizzato per stabilire una
corrispondenza tra un messaggio inviato durante una sessione del protocollo
e la sessione stessa. Supponiamo che un agente A spedisca un messaggio a
B per ottenere una informazione legata in qualche modo allo stato di B nel
momento nel quale A spedisce il messaggio. Ad esempio A potrebbe voler
conoscere il valore di un contatore interno a B. A in un certo istante A invia
a B una messagio tramite il quale manifesta a B la volonta` di conoscere il
valore di tale contatore. Supponiamo che tale contatore, nel momento in cui
B riceve questa richiesta, abbia un determinato valore v. B allora invia ad
A un altro messaggio mB nel quale indica il valore v. Un utente malizioso C
intercetta tale messaggio mB. Successivamente A intende conoscere il nuovo
valore che tale contatore interno a B ha assunto. Indichiamo tale valore con
v′. Ovviamente v′ non necessariamente coincide con v. A invia nuovamente
la richiesta all’agente B. Tuttavia tale richiesta viene intercettata da C, che
invia ad A il messaggio mB ottenuto dalla sessione precedente.
• Il valore del contatore interno a B assume il valore v.
• A invia a B il messaggio mA = ”comunicami il valore del tuo contatore
interno”.
• B invia ad A il messaggio mB = ” il valore del mio contatore interno
e` v”.
• Il messaggio mB viene intercettato da C e da questi ritrasmesso ad A.
• A riceve il messaggio mB deducendo che il valore del contatore interno
a B sia v.
• . . .
• il valore del contatore interno a B assume un nuovo valore v′.
• . . .
• A invia a B il messaggio m′A = ”comunicami il valore del tuo contatore
interno”.
• Tale messaggio viene intercettato da C.
• C invia ad A il messaggio mB, nel quale era indicato il valore v.
• A, quando riceve tale messaggio, si convince che il contatore interno a
B abbia ancora il valore v, mentre tale contatore gia` prima dell’inizio
della sessione aveva assunto il valore v′.
10
Nell’esecuzione presentata il requisito di autenticita` del messaggio mB
non viene violato, in quanto tale messaggio e` effettivamente stato generato
da B. Tuttavia esso e` stato generato da B per essere utilizzato in una
sessione precedente. Il fatto che A non sia in grado di stabilire se il messaggio
che riceve si riferisca alla sessione attuale o ad una svolta precedentemente
causa il fallimento del protocollo.
Per rendere impossibile una esecuzione quale quella indicata, e` neces-
sario inserire nel messaggio mB un elemento che indichi a quale sessione
si riferisca. Soprattutto e` necessario che anche l’agente A sia in grado di
discernere se tale messaggio si riferisce alla sessione corrente o ad una svolta
precedentemente. Supponiamo allora che l’agente A sia in grado di generare
un elemento nuovo n. Finche` tale n non viene inviato sulla rete, A ha la
certezza di essere l’unico agente a conoscenza dello stesso. In oltre, poiche`
tale elemento non era mai stato utilizzato, ogni messaggio presente sulla
rete che contenga n di certo e` stato generato successivamente ad n stesso.
Presentiamo una versione del protocollo per la quale, nell’ipotesi che A sia
in grado di autenticare mB, non soffra dell’inconveniente visto prima :
• A genera un elemento nuovo n(ad esempio un numero casuale)
• A invia a B il messaggio mA = ”comunicami il valore del tuo contatore
interno, la sessione e` identificata da n”.
• B invia ad A il messaggio mB = ” il valore del mio contatore interno,
per la sessione identificata da n, e` v”.
L’agente A, ricevendo mB, poiche` tale mB contiene l’identificativo di
sessione n, e` sicuro che tale messaggio e` stato generato in un istante suc-
cessivo alla generazione di tale identificativo. Quindi tale messaggio non
riguarda una sessione precedente, ma la sua generazione e` di certo successi-
va all’inizio della sessione in corso. Nell’ipotesi che nessun altro agente sia
in grado di generare il messaggio mB oltre B stesso, prevedendo quindi un
sistema per autenticare tale messaggio, e nell’ipotesi che B agisca onesta-
mente, comunicando il valore che il contatore assume al momento nel quale
la richiesta viene ricevuta, il valore di tale contatore e l’identificativo di ses-
sione risultano strettamente legati. In particolare non esistono due messaggi
nei quali viene indicato lo stesso numero di sessione e due valori diversi per
il contatore. Il protocollo in questione gode allora del requisito di unicita`
del messaggio mB rispetto all’elemento n, compreso in mB.
11
2.1.4 Autenticazione
Supponiamo che un agente A porti a termine il protocollo P con un agente
B. L’obbiettivo di autenticazione, secondo la formalizzazione di Lowe, puo`
essere raggiunto dal protocollo P in 4 livelli:
Aliveness l’agente A e` sicuro che B ha eseguito il protocollo.
Weak agreement l’agente A e` sicuro di aver eseguito il protocollo con
B. Questo e` il significato che si asserisce comunemente al termine
autenticazione
Non-injective agreement l’agente A e` sicuro di aver eseguito il protocollo
con B ed inoltre A e B concordano su un insieme di messaggi H.
Injective agreement l’agente A e` sicuro di aver eseguito il protocollo con
B, A e B concordano su un insieme di messaggi H e B non risponde
piu` di una volta nella sessione del protocollo.
Ognuno di questi quattro livelli sussume il precedente. Ad esempio, se
l’agente A e` sicuro di aver eseguito il protocollo con B, allora chiaramente
B ha eseguito il protocollo. Le situazioni nelle quali garantire tale requisito
si rende necessario sono fondamentalmente due :
1. un agente A vuole mettere a conoscenza B di una certa informazione,
ed accertarsi che B abbia effettivamente ricevuto tale informazione;
2. un agente B richiede l’accesso ad alcuni servizi forniti da un server S,
ed il server S vuole accertarsi dell’effettiva identita` di chi ha effettuato
tale richiesta.
Esaminiamo nel dettaglio le quattro forme del requisito di autenticazione,
e come spesso queste si riconducano ad altri requisiti di sicurezza.
Aliveness
Come si deduce dal nome stesso, un requisito di tal genere offre garanzie ad
un agente A che un secondo agente B sia attivo. Per offrire una garanzia di
questo genere e` necessario innanzitutto offrire garanzia di autenticita` rispet-
to qualche messaggio che si presume inviato da B. La presenza o meno di
B puo` essere dedotta solo dall’esistenza o meno di messaggi sulla rete si-
curamente generati da B. Nel caso in cui l’agente A voglia accertarsi che
12
le tracce di attivita` lasciate da B siano recenti, e` necessario che dai mes-
saggi che manifestano la presenza di B possano essere dedotte informazioni
di carattere temporale. Per offrire queste garanzie bisogna ricondursi alle
considerazioni riguardanti il requisito di unicita`. Supponiamo infatti che
esista un server S, nel quale A ripone completa fiducia, che ogni ora generi
un nuovo numero casuale, e lo distribuisca a tutti gli agenti sulla rete. Sia
n il numero distribuito all’ora h. Se un messaggio comprende al suo interno
tale n, di certo la sua generazione risale all’ora h o e` alpiu` successiva. In
tal modo, se l’agente A entra in possesso di un messaggio sicuramente ri-
conducibile a B che contenga il numero n, puo` avere la certezza che l’agente
B all’ora h era ancora attivo. Vari aspetti della generazione di elementi del
tutto nuovi verranno presi in considerazione nei paragrafi successivi.
Weak agreement
Questo livello di autenticazione prevede non solo che un agente A sia in grado
di determinare se B ha eseguito il protocollo recentemente, ma anche se B in
questa esecuzione A stesso sia stato coinvolto oppure no. Per chiarire questo
concetto, esaminiamo un protocollo che non e` in grado di garantire questo
grado di autenticazione: il protocollo Needham-Schroeder. Tale protocollo
sfrutta degli elementi verranno che approfonditi successivamente in questo
documento : la crittografia a doppia chiave e la capacita` da parte degli agenti
di generare numeri casuali mai utilizzati prima sulla rete. La crittografia a
doppia chiave si basa su un insieme di coppie di chiavi: una chiave pubblica
ed una privata. Ogni coppia viene assegnata ad un unico agente e non esitono
due agenti ai quali venga assegnata la stessa coppia di chiavi. Ogni agente
conosce tutte le chiavi pubbliche, ma solo il proprietario conosce la propria
chiave privata Una scrittura del tipo {x}Ka indica un messaggio cifrato con
la chiave pubblica dell’agente A. Essendo tale chiave pubblica, qualsiasi
altro agente a partire da x e` in grado di generare un messaggio di questo
tipo. Per decifrare questo messaggio e` invece necessario conoscere la chiave
privata dell’agente A. Ma solo A stesso e` a conoscenza di tale chiave. Per
questo motivo la crittografia a doppia chiave rappresenta un utile strumento
per la trasmissione di dati confidenziali. Ogni agente e` in grado di spedire un
messaggio ad un’altro agente B, cifrandolo con la chiave pubblica di B. In
questo modo solo B sara` in grado di decifrare questo messaggio. A differenza
del protocollo mostrato come esempio per il requisito di autenticita`, non e`
necessario presuppore che, prima della comunicazione, i due agenti si siano
scambiati in maniera confidenziale alcunche`. Siamo ora in grado di discutere
il protocollo Needham-Schroeder.
13
1. L’agente A genera un elemento nuovo Na, e spedisce a B il messaggio
{Na, A}Kb.
2. L’agente B, alla ricezione di questo messaggio, genera a sua volta
un’altro elemento nuovo Nb e spedisce ad A il messaggio {Na, Nb}Ka.
3. L’agente A spedisce infine a B il messaggio {Nb}Kb
Essendo l’elemento Na un elemento nuovo, alla ricezione del messaggio
indicato al passo 2 l’agente A ha la certezza che tale messaggio riguarda la
sessione corrente. In oltre A spedisce Na al passo 1 cifrato con la chiave
pubblica di B. In tal modo si assicura che solo B possa venire a conoscenza
di Na. Questo basta ad affermare l’autenticita` del messaggio spedito al passo
2. Grazie a queste due considerazioni l’agente A qundo riceve il messaggio
spedito al passo 2 ha la certezza che B stia eseguendo il protocollo. In oltre
il messaggio invitato al passo 2, sicuramente generato da B, viene inviato
cifrato con la chiave pubblica di A. Questo manifesta la convinzione di B
che all’altro capo della comunicazione ci sia A. Considerazioni analoghe sui
passi 2 e 3 ci portano ad affermare che anche B, al termine dell’esecuzione
del protocollo, abbia la certezza di aver eseguito il protocollo con A.
Nonostante questa dimostrazione infomale ci abbia convinto che il pro-
tocollo offra garanzie di autenticazione, nella forma week agreement, porter-
emo un controesempio per dimostrare che cos`i non e`. Supponiamo che un
agente A decida di iniziare una sessione del protocollo con un altro agente
B. A tal fine A invia a C il messaggio {Na, A}Kc. C e` in grado di leg-
gere il contenuto di questo messaggio. Ricava allora da questo Na e invia
il messaggio {Na, A}Kb ad un terzo agente B. Ricevendo tale messaggio,
l’agente B crede che A abbia intenzione di eseguire con lui una sessione del
protocollo. Per questo motivo invia ad A il messaggio {Na, Nb}Ka. Veden-
dosi recapitare tale messaggio A e` convinto che sia la risposta che attendeva
da C. Per questo motivo termina la sessione del protocollo inviando a C il
messaggio {Nb}Kc. A questo punto l’agente A ha la certezza di aver eseguito
il protocollo con C. Anche se questo non e` del tutto vero, tuttavia C era
effettivamente attivo durante la sessione appena terminata, ed inoltre ha
preso parte alla sessione stessa. Avendo ricevuto da A il messaggio {Nb}Kc
C e` in grado di ricavare Nb da tale messaggio. Puo` quindi trasmettere il
messaggio {Nb}Kb all’agente B, concludendo la sessione del protocollo che
aveva aperto con questo. Alla ricezione di questo messaggio, B e` convinto di
aver eseguito il protocollo con A, ma questo non e` affatto vero, poiche` il suo
effettivo interlocutore era C. L’attacco appena presentato fa riflettere su
14
quanto una proprieta` di questo genere sia difficile da garantire, e su quante
insidie un’analisi informale di un protocollo non sia in grado di svelare.
Non injective agreement
Offrire una garanzia di autenticita` con accordo non iniettivo significa dare i
mezzi ad un agente per verificare se le informazioni che ha inteso comunicare
sono giunte correttamente a destinazione. Viene richiesto non solo che un
agente A sia in grado di determinare se B ha eseguito il protocollo con lui,
ma anche che al termine della sessione B abbia ricevuto le informazioni che
A ha inteso comunicargli. Un requisito di tale tipo viene di solito garantito
prevedendo che B spedisca, al termine del protocollo, un riassunto delle
informazioni ottenute da A. Per generare tale riassunto vengono di solito
usate delle funzioni dette funzioni di hashing. Tali funzioni verranno trattate
dettagliatamente nel seguito. Basti sapere che una funzione hash permette
di ottenere da una sequenza di messaggi un ulteriore messaggio(tipicamente
un numero) che la caratterizzi univocamente. Supponiamo che A e B si
scambino i messaggi m1,m2, . . .mn durante una comunicazione. Per con-
fermare tali messaggi, A e B si inviano vicendevolmente il riassunto dei
messaggi scambiati. Nel caso in cui sia possibile autenticare i messaggi che
contengono tali riassunti, e che A e B siano in grado di determinare se i
messaggi ricevuti si riferiscono o meno alla sessione corrente, alla ricezione
del riassunto inviato da B, A puo` confrontarlo con quello da lui generato.
B similmente puo` confrontare quello che ha generato con quello ricevuto da
A. Se i due riassunti coincidono, allora A e B hanno eseguito una sessione
del protocollo scambiandosi effettivamente i messaggi m1,m2, . . .mn.
Injective agreement
Garantire questo grado di autenticazione puo` essere utile ad esempio nei
protocolli ad uso finanziario. Supponiamo ad esempio che il fine di un pro-
tocollo P sia quello di permettere ad un agente di spostare una somma di
denaro dal proprio conto a quello di un’altro agente. Un agente A decide di
trasferire una determinata somma c dal proprio conto a quello di un agente
B. Se tale protocollo P non offre garanzia di autenticita` con accordo iniet-
tivo, potrebbe allora accadere che la richiesta dell’agente A venga recepita
dalla banca due o piu` volte, causando un accreditamento sul conto di B su-
periore alla somma che A aveva intenzione di versare. Viene spontaneo pero`
porsi una domanda : come intendere e come garantire tale requisito su una
rete che preveda la ritrasmissione dei messaggi? In genere la ritrasmissione
15
dei messaggi e` prevista nell’architettura di rete ad un livello inferiore di
quello nel quale si collocano i protocolli in questione. Di solito la ritrasmis-
sione dei messaggi viene gestita nel livello di trasporto, mentre i protocolli
di sicurezza si collocano per lo piu` a livello applicativo. Per questo motivo
la gestione delle ritrasmissioni dovrebbe risultare trasparente al software che
implementi tali protocolli. Tuttavia l’attenzione nei confronti delle problem-
atiche di sicurezza si e` sviluppata in un’epoca successiva alla realizzazione di
molte delle infrastrutture che sono oggi alla base delle comunicazioni sulla
rete internet, e dei protocolli che regolano tali comunicazione. Per questo
motivo, anche se sarebbe lecito, non conviene presupporre nell’infrastruttura
di rete che gli strati sottostanti quello al quale il protocollo che intendiamo
esaminare si colloca siano sicuri. La ritrasmissione dei messaggi si rende
necessaria per garantire la consegna dei messaggi stessi. A seconda degli
obbiettivi che il protocollo si prefige, questa proprieta` potrebbe rivelarsi
non necessaria. Tornando al protocollo preso in considerazione all’inizio di
questo paragrafo, se la richiesta da parte di A di spostare una somma dal
suo conto al conto di C dovesse non giungere a destinazione, A dovrebbe
semplicemente eseguire una nuova sessione del protocollo, sperando che vada
a buon fine. Sarebbe invece molto piu` grave se A vedesse sottratta dal suo
conto una somma superiore a quella che intendeva trasferire.
2.1.5 Non repudiabilita`
Un protocollo P si dice fornire garanzie di non repudiabilita` ad
un agente A se fornisce ad A i mezzi per dimostrare che una
azione e` avvenuta.
Tipicamente, se A e B eseguono il protocollo P, A deve essere in grado di
dimostrarlo. Un protocollo che raggiunga un obbiettivo di questo tipo puo`
o no godere di un’altra proprieta` : fairness. Si dice che P gode di fairness se
per ogni garanzia G, che permette ad un agente A di dimostrare che B ha ese-
guito un’azione, viene fornita a B una garanzia complementare. Ad esempio
supponiamo di esaminare un protocollo nel quale A invia un messaggio m a
B. Una proprieta` di non repudiabilita` potrebbe essere A riesce a dimostrare
che B ha ricevuto il messaggio m. La proprieta` complementare e` B riesce
a dimostrare che A ha spedito il messaggio m. Lo studio delle garanzie di
non repudiabilita` differisce dallo studio degli altri requisiti di sicurezza. Un
protocollo di sicurezza classico offre ad un agente un modo per verificare
se una determinata azione sia o no avvenuta, basandosi su assunzioni che
tale agente e` in grado di verificare. Portare a termine protocollo che offra
16