Valutazione delle prestazioni di soluzioni per la distribuzione di chiavi crittografiche in ambito multicast

Capitolo 1
diffondendo sempre di piu` anche in organizzazioni private di ogni dimensione. Il
suo impiego permette infatti alle aziende di sfruttare tutti i benefici delle applica-
zioni multicast minimizzando l’impatto sulla capacita` ed i tempi di risposta della
rete IP.
A differenza della modalita` unicast, il multicast e` tuttavia sprovvisto di tut-
ti quei meccanismi di sicurezza che sono indispensabili per l’impiego di questa
tecnologia in alcuni scenari applicativi. Le applicazioni per cui e` stato pensato
il multicast hanno spesso, infatti, intrinseche esigenze di dotarsi di meccanismi
che permettano una comunicazione sicura: si pensi per esempio al caso di una
video-conferenza, in cui e` fondamentale garantire la confidenzialita` dell’informa-
zione trasmessa, nonche´ l’autenticazione di chi trasmette tale informazione, come
pure e` importante consentire la partecipazione all’evento solo agli aventi diritto.
Oppure si pensi alla possibilita` di realizzare servizi a pagamento per la distribu-
zione real-time di contenuti audio o video, in cui l’esigenza di consentire l’accesso
ai contenuti trasmessi solo ai sottoscrittori di un abbonamento e` di fondamentale
importanza. Alla base di questi meccanismi vi e` tutta una serie di operazioni
crittografiche realizzate tramite l’impiego di apposite chiavi.
Oggi la realizzazione di servizi di sicurezza nell’ambito della comunicazione
unicast e` un’operazione tutto sommato abbastanza semplice dal punto di vista
tecnologico, data la presenza di due sole parti coinvolte nella comunicazione. La
presenza di piu` parti coinvolte nelle operazioni di sicurezza non consente l’e-
stensione delle soluzioni valide per la modalita` unicast, soprattutto a causa della
difficolta` di gestire le chiavi indispensabili per le operazioni crittografiche nell’am-
bito di gruppi di utenti. Per questo motivo e` necessario lo sviluppo di soluzioni ad
hoc che tengano conto di molti fattori tipici delle dinamiche di gruppo, quali ad
esempio la variabilita` della dimensione del gruppo multicast oppure la frequenza
con la quale gli utenti abbandonano il gruppo o ne entrano a far parte.
4
Capitolo 2
Multicast e sicurezza
2.1 Il multicast
La trasmissione in modalita` unicast e` il metodo attraverso il quale si sono comin-
ciati a distribuire i primi contenuti audio/video attraverso Internet, utilizzando
l’architettura classica client-server su cui sono basate la maggior parte delle ap-
plicazioni. Con questo metodo e` possibile distribuire contenuti audio/video con
la stessa logica attraverso la quale si distribuiscono informazioni attraverso un
sito web: al posto del browser l’utente usa un player tramite il quale si connette
ad un server (media server) che eroga i contenuti audio/video richiesti. Tutta-
via, negli ultimi anni, grazie allo sviluppo delle applicazioni Internet, e` emersa la
necessita` di una nuova modalita` di comunicazione all’interno di gruppi di utenti:
il multicast, in cui un pacchetto viene inviato da un unico host, ma e` ricevuto
da piu` dispositivi destinatari. Si definisce quindi multicast una modalita` di co-
municazione in cui un host sorgente (sender) spedisce messaggi ad una serie di
host destinatari (receiver) in cui le due operazioni fondamentali che caratteriz-
zano l’attivita` degli host nell’ambito del gruppo sono quelle di join e leave, ossia
le operazioni necessarie per entrare a far parte del gruppo e per abbandonarlo,
rispettivamente.
Nel caso di una comunicazione che coinvolge un gruppo di utenti esistono nu-
merose ragioni che rendono il multicast molto vantaggioso rispetto alla modalita`
unicast. Il primo grande vantaggio e` la diminuzione del carico di rete che si ha
5
Capitolo 2 Il multicast
trasmettendo un messaggio in multicast rispetto a quello che si avrebbe se questo
fosse trasmesso in modalita` unicast tante volte quanti sono i ricevitori. Ci sono
molte applicazioni che richiedono di mandare gli stessi pacchetti ad un numero
elevato di stazioni, e questi pacchetti condivideranno probabilmente una serie di
link sul percorso che li portera` alle varie destinazioni. Il pacchetto rimarra` unico
finche´ non sara` necessario duplicarlo; risulta quindi evidente che una trasmissione
multicast porta una notevole diminuzione del traffico in rete, come illustrato in
figura 2.1.
Le principali applicazioni che usano la modalita` di comunicazione multicast
sono le audio e video conferenze e la distribuzione di dati audio e video: esse si
inseriscono in due contesti diversi: la prima presuppone infatti l’esistenza di tanti
sender e tanti receiver; mentre la seconda ha un solo sender e un gruppo piu` o
meno numeroso di receiver.
Sender
Receiver 1
Receiver 2
Receiver 3
Figura 2.1: Un ipotetico scenario multicast
2.1.1 Multicast IP
Per le applicazioni multicast si usano indirizzi IP di classe D che sono compresi
nell’intervallo tra 224.0.0.0 e 239.255.255.255. Per ogni indirizzo multicast esisto-
6
Capitolo 2 Il multicast
no uno o piu` host che attendono pacchetti inviati a tale indirizzo: questo insieme
di membri e` detto gruppo multicast. Per inviare dati al gruppo, non occorre cono-
scerne i membri, ma basta conoscere l’indirizzo del gruppo stesso. Esistono due
tipi di indirizzi:
• permanenti :
essi vengono assegnati dallo IANA (Internet Assigned Numbers Authority)
e l’elenco e` pubblicato nella RFC 1700. L’appartenenza al gruppo non
e` permanente, ogni membro puo` effettuare join/leave a piacimento ed il
gruppo, inteso come indirizzo, continua ad esistere indipendentemente dalla
sua cardinalita`. Alcuni indirizzi permanenti sono:
– 224.0.0.0:
indirizzo base riservato;
– 224.0.0.1:
tutti i sistemi di questa sottorete:
– 224.0.0.2:
tutti i router di questa sottorete.
• transitori :
ogni gruppo che non e` permanente e` transitorio. L’assegnamento di questi
indirizzi e` dinamico. Il gruppo cessa di esistere quando non ha piu` membri.
Dato che il traffico multicast non si limita ad una sola rete fisica, ma potenzial-
mente puo` estendersi in tutta la rete Internet, c’e` bisogno di prendere precauzioni
per evitare l’instaurarsi di pericolosi cicli dei pacchetti di multicast. Cio` significa
che i router devono utilizzare dei protocolli specifici per il trattamento e l’instra-
damento di tali pacchetti. Per poter inviare pacchetti multicast attraverso piu`
reti devono essere soddisfatti due requisiti:
• bisogna poter stabilire un meccanismo che consenta ai membri del gruppo
multicast di effettuare le operazioni di join e leave: un apposito protocollo
e` IGMP (Internet Group Management Protocol, [16]);
7
Capitolo 2 Il multicast
• bisogna poter determinare l’estensione del gruppo, dato che esso puo` poten-
zialmente coprire tutta Internet. Per esempio si puo` usare il campo TTL
(Time To Live) dell’header IP del datagramma multicast, che viene decre-
mentato ogni ogni volta che si attraversa un router (ossia ad ogni “hop”).
Prima di elaborare un pacchetto viene controllato il suo TTL:
– TTL=0:
un pacchetto ricevuto con TTL=0 e` visto esclusivamente dall’host
sorgente e non raggiunge alcun altro host del gruppo;
– TTL=1:
un pacchetto ricevuto con TTL=1 raggiunge tutti gli host della sot-
torete che fanno parte del gruppo. I router decrementano il valore a
zero, ma, a differenza del caso unicast non c’e` nessun messaggio ICMP
d’errore che viene mandato al mittente. La scadenza di un pacchetto
e` un evento frequente nel multicast;
– TTL=2 o piu`:
il datagramma raggiunge tutti gli host della sottorete che fanno parte
del gruppo, e i router inoltrano il pacchetto.
IP Multicast e`, cos`ı come IP Unicast, un protocollo a datagramma di tipo
“best effort”, cioe` inaffidabile. Non viene garantita la consegna dei pacchetti a
destinazione, ne´ tanto meno che arrivino nell’ordine con cui sono stati manda-
ti. Attualmente l’unico protocollo standard a livello di trasporto che supporta
il multicast e` UDP (User Datagram Protocol), anch’esso inaffidabile. Tuttavia
all’IETF e` presente un working group (RMT, Reliable Multicast Transport) che
si sta occupando di realizzare nuove soluzioni per il multicast affidabile. Tra i
protocolli di livello applicativo piu` importanti si segnalano SRM (Scalable Relia-
ble Multicast), RMTP (Reliable Multicast Transfer Protocol) e PGM (Pragmatic
General Multicast, detto anche “Pretty Good Multicast”), i quali sopperiscono
alla mancanza di affidabilita` a livello di trasporto, forniscono dei meccanismi di
recupero dei pacchetti persi, e sono in grado di rendere il multicast una modalita`
di trasmissione affidabile. Attualmente, tuttavia, tali protocolli non sono diffusi.
8
Capitolo 2 Il multicast
2.1.2 Il protocollo IGMP
Il protocollo IGMP [16] e` usato dagli host per dialogare con il router multicast
piu` vicino per chiedere di entrare a far parte di un gruppo multicast o per abban-
donarlo. Si tratta di un’estensione di ICMP (Internet Control Message Protocol,
entrambi occupano la stessa posizione nello stack protocollare) ed e` integrato
direttamente in IPv6, mentre e` supportato opzionalmente in IPv4.
Messaggi IGMP
I messaggi IGMP sono incapsulati nei pacchetti IP. Per indicare un pacchetto
IGMP, nell’header IP si utilizza un valore pari a 2 per il campo “protocol number”.
Il campo dati contiene il messaggio illustrato in figura 2.2.
tipo max resp. time checksum
indirizzo classe D
0 8 16 31
8
ottetti
Figura 2.2: Formato del pacchetto IGMP
I campi nel messaggio contengono le seguenti informazioni:
• tipo:
specifica il tipo di messaggio, ad esempio:
– membership query :
viene inviato dal router multicast per sapere quali gruppi hanno degli
host in una sottorete connessa al router (“general query”) o per sapere
se un particolare gruppo ha degli host in una sottorete connessa al
router (“group-specific query”);
– membership report :
viene inviato da un host per segnalare la propria appartenenza ad un
9
Capitolo 2 Il multicast
determinato gruppo multicast in seguito ad un messaggio di “mem-
bership query” del router. Non viene inviato dall’host che decide di
abbandonare un gruppo multicast;
• max response time:
e` usato nei messaggi di tipo “membership query” e specifica il tempo massi-
mo che un host puo` attendere prima di inviare il corrispondente messaggio
di report. Specificando un opportuno valore per tale campo il router puo`
controllare il tempo massimo che trascorre tra un evento di leave e l’istante
in cui il router e` informato che non ci sono piu` membri del gruppo in quella
sottorete. Infatti il valore di max response time e` pari al tempo massimo in
cui un router attende i report degli host. Se entro tale tempo gli host non
hanno risposto (non confermando quindi la volonta` di continuare a parte-
cipare al gruppo), allora e` certo che in quella sottorete non ci saranno piu`
utenti appartenenti per quel particolare indirizzo multicast;
• checksum:
contiene un campo di 16 bit per la somma di controllo;
• indirizzo classe D :
contiene un indirizzo multicast valido.
H4H2
Gruppo 1
H5
Gruppo 1
H1
Gruppo 2
H3
Gruppo 1
Gruppo 2
Multicast Router
Query
Figura 2.3: Messaggio IGMP Query
10
Capitolo 2 Il multicast
Operazioni del protocollo
Sia gli host, sia i router sono coinvolti nelle operazioni del protocollo IGMP. Si
ribadisce come queste operazioni avvengano esclusivamente tra gli host di una
sottorete ed il relativo router multicast. Si descrivono di seguito le principali
operazioni da svolgere per la gestione dei gruppi multicast sia da parte degli host
(che devono potersi unire ad un gruppo ed abbandonarlo), sia da parte dei router
(che devono gestire le informazioni necessarie per recapitare in modo ottimale
agli host tutti i pacchetti a loro destinati).
Operazioni degli host Per ricevere pacchetti multicast un host deve associarsi
ad un gruppo (operazione di join). Se un host e` connesso a piu` reti esso puo`
associarsi ad un gruppo su una o piu` interfacce. Se piu` processi sullo stesso host
sono in attesa di messaggi dallo stesso gruppo, l’host effettua comunque un unico
join. Per effettuare un join, l’host manda un messaggio IGMP di “membership
report” indirizzato al gruppo di interesse attraverso una delle interfacce di rete.
Non e` necessario associarsi al gruppo “tutti gli host” (224.0.0.1): l’appartenenza a
questo gruppo e` automatica. Per abbandonare un gruppo (operazione di leave) e`
sufficiente che l’host non risponda al messaggio di “membership query” del router
e che ignori i pacchetti che eventualmente continueranno a giungergli (se un altro
host appartenente allo stesso gruppo sara` presente sulla stessa sottorete). Quando
non ci saranno piu` host sulla sottorete, il router cessera` di inoltrare pacchetti
multicast verso di essa.
Operazioni dei router Quando un host vuole associarsi ad un gruppo, il rou-
ter della sottorete riceve il messaggio IGMP di “membership report” e inserisce
una voce nel suo “local group database”, che tiene traccia dei membri dei vari
gruppi situati nelle sottoreti connesse. Ogni voce e` del tipo [gruppo, sottorete
associata]. Cio` significa che la sottorete associata a quel gruppo ha almeno un
host che vi partecipa. I router ascoltano tutti messaggi di multicast che arrivano
loro, ma inoltrano solo quelli che hanno una entry nel database sull’interfaccia
specificata. Per controllare l’appartenenza ai vari gruppi, i router mandano rego-
larmente dei messaggi IGMP “membership query” all’indirizzo “tutti gli host”.
11
Capitolo 2 Il multicast
Ogni membro che non vuole abbandonare il gruppo deve rispondere. La gia` citata
RFC 2236 [16] specifica che questo controllo andrebbe effettuato ogni 125 secondi,
tuttavia, per evitare che sulla sottorete tutti gli host rispondano simultaneamente
causando dei picchi di traffico, le risposte vengono inviate con dei ritardi casuali.
Dato che non si tiene traccia del numero di host di ciascun gruppo, se un host
riceve la risposta di un altro host della sottorete (si tratta di un messaggio di
tipo “membership report packet”, quindi di un messaggio multicast), rinuncia ad
inviare la propria, che a quel punto sarebbe superflua. Se nessun host risponde al
router, esso ne deduce che su quella sottorete non ci sono piu` host appartenenti
a quel determinato gruppo.
2.1.3 Il routing per il multicast
IGMP specifica solo le modalita` di comunicazione tra gli host in ricezione e i
rispettivi router multicast. L’instradamento dei pacchetti tra router e` gestito
da appositi protocolli che sono studiati in modo da inoltrare i pacchetti su quei
percorsi sui quali ci sono effettivamente dei membri del gruppo, in modo da
minimizzare il traffico in rete. Segue una breve descrizione dei principali algoritmi
e protocolli, per i dettagli si rimanda alla bibliografia [13].
Gli algoritmi di forwarding
Gli algoritmi di forwarding sono usati per stabilire dei cammini nella rete che
consentano al traffico multicast di raggiungere effettivamente tutti i membri del
gruppo e devono soddisfare i seguenti requisiti:
• devono inoltrare il traffico solo ai membri del gruppo;
• devono ottimizzare il cammino dalla sorgente alle destinazioni;
• devono creare dei percorsi senza che si instaurino dei cicli;
• devono fornire la possibilita` di fare segnalazione;
• non devono concentrare il traffico su degli insiemi particolari di link.
Esistono due categorie principali:
12
Capitolo 2 Il multicast
Router 1
Router 3
Router 2
Multicast Routing ProtocolGroup Membership Protocol (IGMP)
Figura 2.4: Lo scenario Multicast IP
• Reverse Path Forwarding Algorithm (RPF):
ad ogni membro e` associato un albero di distribuzione che viene usato per
inoltrare i datagrammi. Il nome dell’algoritmo e` dato dal fatto che viene
memorizzata una tabella che contiene un percorso inverso con il quale e`
possibile raggiungere ogni sorgente. Ogni rete sorgente nota viene associa-
ta a un’interfaccia privilegiata tramite la quale e` possibile raggiungere la
sorgente. Vengono inoltrati solo i pacchetti che arrivano da tale interfaccia
(che e` quella che verrebbe usata per mandare pacchetti verso la sorgente),
mentre gli altri sono scartati. I due vantaggi principali di questa catego-
ria di algoritmi sono la velocita` e l’efficienza data dal fatto che per ogni
host di destinazione viene calcolato un albero di distribuzione che viene
continuamente aggiornato.
• Center-Based Tree Algorithm (CBT):
viene scelto un nodo centrale nella rete, il quale rappresenta il centro del
gruppo multicast. Ogni destinatario invia una richiesta IGMP di join a
quel nodo, che viene elaborata da tutti i router intermedi e dal nodo cen-
13
Capitolo 2 Il multicast
trale. Se il router e` gia` membro dell’albero di distribuzione viene aggiunta
un’interfaccia, mentre se si tratta della prima richiesta di join la si inoltra
verso la sorgente: in questo modo viene costruito un unico albero per cia-
scun gruppo. Dato che la sorgente non deve necessariamente appartenere
al gruppo, i pacchetti che vengono inviati dalla stessa raggiungono dappri-
ma il nodo centrale e da l`ı vengono poi inoltrati ai destinatari. Potrebbero
quindi instaurarsi dei percorsi non ottimali per alcune sorgenti e per alcuni
membri.
I protocolli di routing
I tre principali protocolli di routing per il multicast sono i seguenti e implementano
gli algoritmi visti in precedenza.
• Distance Vector Multicast Routing Protocol (DVMRP, [46]):
non elabora i pacchetti unicast. Viene descritto come un protocollo di tipo
“invia in broadcast e poi taglia”. Dapprima vengono costruiti gli alberi
di distribuzione per ogni sorgente, che poi vengono “potati” per creare un
unico albero relativo all’intero gruppo. Usa gli algoritmi della categoria
RPF.
• Multicast Open Shortest Path First (MOSPF, [32]):
si tratta dell’estensione al multicast del protocollo di routing OSPF v.2 in
modo da sfruttare le informazioni contenute nei database OSPF per creare
un albero di distribuzione a percorso minimo che ha la radice nel nodo
sorgente. Elabora sia pacchetti multicast, sia unicast, dato che viene usato
nelle reti che supportano gia` OSPF.
• Protocol Independent Multicast (PIM, [15]):
la complessita` di MOSPF ha portato allo sviluppo di questo protocollo che
pero` e` indipendente dai protocolli di routing unicast esistenti. Ne esistono
due versioni; PIM Sparse Mode e Dense Mode. Se la probabilita` di trovare
un membro del gruppo all’interno di una certa sezione della rete e` elevata,
allora si parla di elevata densita` dei membri e si usa PIM in versione Dense
14
Capitolo 2 La sicurezza applicata al multicast
Mode. Viceversa, se la probabilita` e` piu` bassa, la densita` dei membri si
riduce (sono piu` “sparsi”) e quindi si usa PIM in versione Sparse Mode.
Nel primo caso si utilizza un algoritmo di forwarding di tipo RPF, nel
secondo caso di tipo CBT.
2.1.4 La rete MBONE
La rete di backbone per il multicast e` detta MBONE ed esiste dal 1992. Il suo sco-
po era inizialmente quello di effettuare degli esperimenti sui protocolli multicast,
e nacque come una rete virtuale sovrapposta a quella fisica. In seguito MBONE
venne usata sempre piu` per trasmissioni di tipo audio e video streaming. L’uso
privato e commerciale di MBONE attualmente continua ad aumentare anche se
ad oggi la maggior parte dei router di Internet supporta il multicast, cosa che agli
albori di MBONE rappresentava un’eccezione. Il traffico multicast tuttavia non
riesce ancora a raggiungere tutti i punti della rete Internet. MBONE consiste di
una serie di isole che sono interconnesse tra di loro tramite dei tunnel i quali,
attraversando i router standard, trasportano i pacchetti attraverso quelle zone
che non supportano il multicast.
2.2 La sicurezza applicata al multicast
Due problematiche legate alle comunicazioni multicast sono oggi in particolare
oggetto di ricerca. Esse sono l’affidabilita` (cioe` la garanzia che i pacchetti vengano
ricevuti e nell’ordine corretto) e la sicurezza.
Gli obiettivi della sicurezza in ambito multicast sono principalmente due: l’au-
tenticazione e la segretezza dei dati. Bisogna, cioe`, consentire l’accesso ai dati
trasmessi solo agli host registrati e fornire delle garanzie sull’identita` della sorgen-
te dei dati stessi. La scelta di un’infrastruttura che garantisca questi due aspetti
dipende da una serie di parametri che riguardano il gruppo multicast, come per
esempio la dimensione del gruppo e la potenza di calcolo nonche´ la memoria di-
sponibile sugli host partecipanti. L’aspetto piu` importante che influenza in modo
fondamentale la scelta di un’infrastruttura e` la frequenza con cui cambiano i
15
Capitolo 2 La sicurezza applicata al multicast
membri all’interno del gruppo e il tempo massimo che deve essere impiegato per
aggiornare il gruppo dopo ogni cambiamento.
La segretezza dei dati viene ottenuta facendo uso di chiavi di cifratura note
ai soli membri del gruppo: queste chiavi vengono chiamate chiavi di gruppo e
quando i membri del gruppo cambiano e` necessario il loro aggiornamento. Infatti,
una volta che il nuovo membro ha ricevuto la chiave di gruppo, e` in grado di
decifrare i messaggi destinati al gruppo multicast. Percio`, aggiornando la chiave
di cifratura, si vuole evitare che i nuovi partecipanti possano accedere ai dati
scambiati all’interno del gruppo prima del loro ingresso1. Per poter definire una
chiave di gruppo devono essere soddisfatte quattro proprieta` fondamentali, che
sono:
1. Group Key Secrecy:
segretezza della chiave di gruppo. Si tratta della proprieta` principale: ga-
rantisce che per un avversario e` computazionalmente “impossibile” ottenere
la chiave di gruppo in seguito ad un attacco di tipo crittoanalitico.
2. Forward Secrecy:
nuove chiavi di gruppo non devono poter essere ricavate da parte dei membri
che hanno abbandonato il gruppo.
3. Backward Secrecy:
chiavi di gruppo usate precedentemente non devono poter essere ricavate
da parte dei nuovi membri del gruppo.
4. Key Independence:
si tratta della proprieta` piu` forte. Un avversario che e` in grado di conoscere
un sottoinsieme delle chiavi di gruppo utilizzate non deve poter ricavare
nessuna delle chiavi al di fuori di questo sottoinsieme.
L’operazione piu` problematica e` comunque l’aggiornamento delle chiavi in
seguito all’uscita di un membro dal gruppo. In questo caso, infatti, la chiave di
gruppo deve essere aggiornata e distribuita a tutti i membri rimasti, in modo che
1Una buona introduzione ai problemi derivanti alla gestione delle chiavi di cifratura
all’interno di un gruppo e` data dal documento [47].
16
Capitolo 2 La sicurezza applicata al multicast
il membro uscente non sia piu` in grado di decifrare i nuovi messaggi mandati al
gruppo.
`
E evidente che trasmettere la nuova chiave ad ogni membro rimasto in
modalita` unicast comporterebbe una notevole occupazione di banda: infatti, se
N fosse il numero di partecipanti al gruppo, in seguito ad un leave il controllore
(l’entita` deputata alla gestione delle chiavi dei singoli membri) dovrebbe mandare
la nuova chiave di gruppo a N−1 membri, quindi si occuperebbe la rete con N−1
messaggi di update. Inoltre, per rendere il canale sicuro, il controllore dovrebbe
mandare questi messaggi cifrandoli con una chiave che condivide con ciascun
membro e per poterlo fare dovrebbe tenere in memoria N chiavi di cifratura.
Naturalmente una soluzione del genere diventa insostenibile se il numero di
partecipanti e` elevato.
`
E quindi fondamentale che un’infrastruttura di multi-
cast sicuro sia scalabile, ossia che la complessita` dell’infrastruttura non cresca
eccessivamente all’aumentare del numero di utenti. Inoltre e` necessario che il
tempo impiegato per l’aggiornamento delle chiavi non sia elevato, in modo da
non interrompere il flusso dati per periodi di tempo troppo lunghi.
L’autenticazione della provenienza del flusso dati multicast puo` essere fatta
a due livelli: si puo` fare in modo che un receiver sia certo di aver ricevuto il
messaggio da un membro del gruppo (autenticazione di gruppo), ma anche che
il receiver sappia esattamente l’identita` del sender che ha mandato il messaggio
(autenticazione di sorgente). La tecnica piu` tradizionale per l’autenticazione sia di
sorgente, sia di gruppo prevede l’uso dei Message Authentication Code (MAC) (si
veda l’appendice A.3) ed e` descritta nel dettaglio al paragrafo 3.3.1. Attualmente
sono oggetto di studio anche altre tecniche piu` efficienti che sono descritte nel
paragrafo 3.3.
A seconda dei contesti in cui viene utilizzata la comunicazione multicast, ri-
sultano piu` o meno importanti alcuni aspetti di sicurezza rispetto ad altri. I
due contesti principali che si possono individuare sono la comunicazione “uno a
molti”, che si ha quando un unico sender trasmette dati a tanti receiver, e la
comunicazione “molti a molti”, in cui vi e` piu` di un sender che trasmette dati al
gruppodeireceiver.
17