Simulazione di griglie computazionali: applicazione al progetto DataGRID

Introduzione 
 
2
risultava composto da elementi eterogenei anche nella tipologia, infatti essi non solo 
erano supercomputer dall’architettura assai differente (multicomputer a memoria 
distribuita: IBM SP, Intel Paragon, Cray T3D; sistemi multiprocessore a memoria 
condivisa: SGI Challenge, Convex Exemplar; sistemi a processore vettoriale: Cray C90, 
Cray Y-MP) ma anche strumenti scientifici (microscopi e radiotelescopi), sistemi per la 
realtà virtuale (CAVE ed ImmersaDesk) e database [2]. 
Per “ambiente collaborativo” si intende sia un ambiente che permetta la 
collaborazione culturale fra i partecipanti allo stesso progetto, sia un ambiente realizzato 
grazie alla collaborazione fra i diversi domini amministrativi (VO: Virtual 
Organization) che mettono a disposizione degli altri le proprie risorse. Possiamo quindi 
affermare, che una Griglia Computazionale è un ambiente collaborativo, integrato e 
distribuito [3]. 
Com’è ormai chiaro, le risorse delle Griglie Computazionali sono caratterizzate da 
tre aspetti: 
™ eterogeneità anche nella tipologia, 
™ appartenenza ad amministrazioni differenti, 
™ distribuzione su larga scala [3]. 
 
Per poter essere adoperate quindi, è necessaria un’infrastruttura software che oltre a 
fornire ad esse un’interfaccia comune, assicuri un accesso sicuro, permetta la raccolta di 
informazioni su di esse, dia la possibilità di scoprirle e pianifichi il loro utilizzo [3]. 
L’eterogeneità delle risorse degli ambienti Grid permettono l’esecuzione di 
un’ampia varietà di applicazioni, tuttavia quelle che più si avvantaggiano di un 
ambiente siffatto sono quelle che sfruttano [1]: 
™ supercalcolo distribuito – è necessario tutte le volte che la complessità 
dell’applicazione rende improponibile la sua esecuzione su un unico 
elaboratore; 
™ elaborazione high-throughput – con l’elaborazione high-throghput si cerca di 
pianificare l’esecuzione di un gran numero di tasks debolmente correlati, in 
modo da adoperare la potenza computazionale degli elaboratori 
temporaneamente inutilizzati; 
™ elaborazione on-demand – l’elaborazione on-demand viene adoperata 
ogniqualvolta c’è la necessità di una gran potenza computazionale per un 
breve periodo di tempo; 
Introduzione 
 
3
™ elaborazione data-intensive – le applicazioni data-intensive sintetizzano 
nuove informazioni partendo dai dati conservati in database distribuiti 
geograficamente. 
 
All’elaborazione high-throughput e data-intensive sono interessati i partecipanti al 
progetto europeo DataGRID capeggiato dal CERN, che vede la partecipazione di enti 
ed agenzie di prestigio come: 
™ ESA: European Space Agency (EU); 
™ CNRS: Centre National de la Recherche Scientifique (F); 
™ INFN: Istituto Nazionale di Fisica Nucleare (I); 
™ NIKHEF: National Institute for Nuclear Physics (D); 
™ PPARC: Particle Physics and Astronomy Research Council (UK). 
 
L’obiettivo del Progetto DataGRID è la creazione di un ambiente Grid che permetta la 
collaborazione fra gli scienziati europei, impegnati nelle più diverse ricerche, 
adoperando le risorse già disponibili e solo open software. In particolare i campi di 
ricerca nei quali sono impegnati i partecipanti al progetto DataGRID sono tre: 
™ Fisica delle alte energie. Al CERN è in costruzione il più potente acceleratore 
di particelle mai esistito, chiamato Large Hadron Collider (LHC) che darà 
risposta ad alcuni interessanti quesiti sulle particelle, come il perché alcune 
sono più pesanti di altre e perché possiedono una massa. Le risposte vanno 
ricercate nel cosiddetto campo di Higgs e nell’interazione, mediata dal 
bosone di Higgs, esistente fra esso e le particelle. Gli eventi che evidenziano 
l’esistenza del campo di Higgs sono così rari che cercarli è come cercare un 
ago in venti pagliai, infatti LHC fornirà durante gli esperimenti dati ad una 
velocità elevatissima e anche dopo il loro filtraggio, se venissero memorizzati 
su CD-ROM, questi potrebbero essere accatastati formando una pila alta un 
chilometro. I dati restanti dopo il filtraggio, verranno analizzati alla ricerca 
degli eventi rivelanti l’esistenza del campo di Higgs. 
™ Osservazione terrestre. L’ESA gestisce diverse missioni d’osservazione 
terrestre attraverso satelliti che generano 100 gigabyte di immagini al giorno; 
questo numero è destinato ad aumentare di un fattore cinque nell’immediato 
futuro grazie al satellite ENVISAT. Attualmente sono stati raccolti 800 
terabyte di dati. 
Introduzione 
 
4
™ Studio del genoma umano. Il DNA umano con i suoi 3.5 miliardi di 
nucleotidi costituisce un’altra sorgente di informazioni alla quale è interessata 
la ricerca biologica. Lo studio del genoma umano consiste nell’analisi del 
DNA sequenziato, alla ricerca delle sequenze di nucleotidi codificanti i 
100000 geni che si stima abbia l’essere umano. 
 
In tutti i tre casi, i ricercatori hanno la necessità di accedere ed analizzare una enorme 
quantità di dati. Per far ciò è necessaria una potenza di calcolo ed una capacità di 
memorizzazione che nessun computer attualmente possiede. Un ambiente Grid 
costituito dalle risorse sparse nei centri di ricerca partecipanti alle diverse ricerche, 
darebbe soluzione a questo problema. 
I problemi da risolvere nella realizzazione di un ambiente Grid sono molteplici, 
tuttavia il più ostico è quello dello scheduling che consiste nella messa a punto di 
meccanismi e politiche che permettano la pianificazione dell’esecuzione delle 
applicazioni, in modo da massimizzare o almeno ottimizzare le prestazioni. 
Il concetto di “prestazioni” è molto generico e soggettivo. Per un utente finale un 
sistema è tanto più “prestante”, quanto più riesce a soddisfare i requisiti legati alla 
qualità del servizio. Nel nostro caso, una grandezza indicante la qualità del servizio è il 
tempo di risposta dell’ambiente Grid, che definiamo come tempo intercorrente 
dall’istante in cui un utente formula una richiesta di servizio, all’istante in cui riceve i 
risultati dell’esecuzione di tale richiesta, nell’ipotesi che questa venga completata con 
successo. 
Per un amministratore invece, il sistema è tanto più prestante, quanto più alto è il 
suo throughput e/o throughput relativo. Il throughput è il numero di richieste 
completate con successo nell’unità di tempo, mentre per throughput relativo definiamo 
il rapporto fra il numero di richieste completate con successo ed il numero di quelle 
formulate in un determinato periodo di tempo. 
Di fondamentale importanza per chi progetta un algoritmo di scheduling, è 
l’overhead causato dall’algoritmo, che possiamo definire come rapporto fra il tempo 
necessario allo scheduling di una richiesta ed il tempo di risposta dell’ambiente per tale 
richiesta. 
A questo punto ci si deve chiedere come questi indicatori possano essere 
determinati. Le possibilità sono tre: 
™ calcolarli analiticamente o numericamente; 
Introduzione 
 
5
™ misurarli sperimentalmente; 
™ misurarli tramite simulazione. 
 
Data la complessità di un ambiente Grid, è improbabile pensare di determinarli 
analiticamente o numericamente. L’idea di determinarli sperimentalmente è da scartare 
in quanto il sistema ancora non esiste inoltre; ammesso che si possa costruire un 
prototipo dell’ambiente finale, il costo delle modifiche necessarie con il progredire del 
progetto risulterebbe eccessivo. La determinazione tramite simulazione, oltre a non 
produrre costi, risulta essere più flessibile ed adattabile dell’approccio sperimentale, 
caratteristica derivante dalla semplicità con cui è possibile studiare le diverse alternative 
nel progetto. 
In questa Tesi si vuol proporre una soluzione al problema della determinazione 
degli indicatori presentati, tramite simulazione. In particolare il problema affrontato è 
quello della realizzazione di un Simulatore di Griglie Computazionali. Sebbene 
l’approccio adottato per la realizzazione del Simulatore possa essere adattato ad una 
qualsiasi Griglia Computazionale, il modello preso come riferimento è quello del 
Progetto DataGRID. 
Il Simulatore è stato realizzato adoperando la progettazione Object Oriented 
assistita dal calcolatore. In particolare per la descrizione dei sistemi concettuali ed 
implementativi sono stati adoperati strumenti CASE basati sullo Unified Modeling 
Language (UML) [4][5]. UML è il successore di una serie di metodologie di analisi e 
progettazione orientate agli oggetti (OOA&D: Object-Oriented Analysis and Design) 
apparse fra la fine degli anni ’80 ed i primi anni ’90 e costituisce l’unificazione, 
standardizzata dalla OMG (Object Management Group), dei metodi di Booch, 
Rumbaugh e Jacobson, standardizzata dalla OMG (Object Management Group). 
Lo sviluppo del software è stato realizzato interamente in Java in quanto esso, 
oltre a sposarsi perfettamente con la progettazione orientata agli oggetti, è un linguaggio 
object oriented puro, permette con estrema facilità la scrittura di applicazioni complesse 
grazie al supporto nativo del multi-threading, alla gestione trasparente dei puntatori e 
della memoria, permettendo di mantenere anche nel software un elevato grado di 
astrazione. 
I contenuti e la struttura di questa Tesi rispecchiano la sequenza delle fasi 
necessarie per la progettazione di un simulatore (Figura 2). La prima fase consiste nella 
formulazione del problema, a cui è dedicata questa introduzione. 
Introduzione 
 
6
 
Figura 2: Fasi del progetto di un simulatore. 
Introduzione 
 
7
La seconda fase consiste nella raccolta dei dati necessari che riguardano l’architettura e 
l’utilizzo del sistema da simulare. Questa fase è svolta nei Capitoli I e II. Nel primo 
verrà descritta l’architettura di DataGRID, partendo dall’analisi di quella delle Griglie 
Computazionali in genere, per poi passare alla descrizione del Globus Toolkit adoperato 
nel Progetto DataGRID, per concludere con la descrizione di tutte quelle integrazioni 
realizzate ad hoc dai membri del progetto. Nel secondo invece, verrà descritta 
l’organizzazione e la modalità d’utilizzo delle risorse, prendendo come riferimento il 
Progetto MONARC. 
Le ultime quattro fasi, ossia realizzazione del modello del sistema, codifica, 
verifica e validazione sono discusse nel Capitolo III. Nel Capitolo IV invece, varrà 
illustrato come adoperare il simulatore illustrando un caso d’uso. 
 
 CAPITOLO 1 
ARCHITETTURA DI DATAGRID 
1.1. Componenti di una Griglia Computazionale 
Le Griglie Computazionali sono costituite da una serie di componenti che permettono 
l’utilizzo delle risorse da parte degli utenti finali, ossia rendono uniforme l’accesso a 
risorse eterogenee. Essi sono organizzati in un’architettura gerarchica a livelli, nella 
quale componenti di livello superiore adoperano quelli di livello inferiore. 
 
Grid Applications Grid Applications 
Application 
Grid Programming Environments and Tools 
Collective User Level Middleware – Resource Aggregators 
Grid Tools 
Resource Low Level Middleware Services 
Connectivity Security Infrastructure 
Grid Middleware 
Fabric Grid Fabric Grid Fabric 
Figura 3.1: Architetture a livelli degli ambienti Grid. 
Nella Figura 3.1 sono rappresentate tre differenti architetture equivalenti fra loro. A 
sinistra c’è la proposta di I. Foster, C. Kesselman e S. Tuecke [6], al centro quella di M. 
Chetty e R. Buyya [7], a destra quella di M. Baker, R. Buyya e D. Laforenza [3]. 
Nel seguito daremo una descrizione delle componenti seguendo il modello di I. 
Foster, C. Kesselman, S. Tuecke. 
1.1.1. Livello Fabric: Risorse delle Griglie Computazionali 
Il livello Fabric è composto dalle risorse delle Griglie Computazionali. Come è stato già 
detto, le risorse delle Griglie Computazionali sono caratterizzate da tre aspetti [3]: 
™ estrema eterogeneità anche nella tipologia; 
™ appartenenza ad amministrazioni differenti; 
™ distribuzione su larga scala. 
 
Architettura di DataGRID 
 
9
L’eterogeneità delle risorse è portata all’estremo negli ambienti Grid: infatti esse oltre a 
poter essere della stessa tipologia ma di architettura differente, possono appartenere 
anche a tipologie differenti. Accanto a computer, supercomputer e database quindi, 
possiamo trovare altri strumenti scientifici come microscopi, radiotelescopi e sensori. 
L’appartenenza delle risorse a domini amministrativi differenti è una caratteristica 
derivante dalla collaboratività dell’ambiente: infatti ogni Virtual Organization mette a 
disposizione degli altri le proprie risorse ma ne mantiene sia la proprietà che 
l’amministrazione, ognuna di esse quindi, ha piena libertà nella gestione. 
Anche la distribuzione su larga scala risulta essere estrema, infatti le risorse non 
solo possono essere distribuite sull’intero pianeta ma anche nello spazio circostante: si 
pensi ai satelliti. 
Elencare tutte le risorse integrabili in un ambiente Grid, è un compito arduo oltre 
che inutile. Perché una risorsa possa appartenere ad una Griglia Computazionale è 
necessario che essa [6]: 
™ sia condivisibile; 
™ metta a disposizione meccanismi di interrogazione che permettano di 
scoprirla e di conoscere il suo stato; 
™ metta a disposizione meccanismi di gestione che permettano di controllarla. 
1.1.2. Livello Connectivity: Comunicazione fra le Risorse 
Nel livello Connectivity si trovano i protocolli di comunicazione che permettono alle 
diverse componenti del livello Fabric di scambiarsi dati ed informazioni. Questi 
protocolli devono permettere il trasporto, l’instradamento e l’assegnazione di nomi ai 
diversi nodi. I vari progetti che si occupano dello sviluppo di Griglie Computazionali 
convergono sull’opportunità di adoperare gli standard de facto affermatisi con Internet: 
parliamo dei protocolli IP, ICMP, TCP, UDP e DNS [6]. 
In questo livello ci si deve anche preoccupare di rendere la comunicazione sicura, 
per mezzo di meccanismi di autenticazione che devono permettere [6]: 
™ Autenticazione singola. Gli utenti devono poter autenticarsi una volta per 
tutte all’atto della connessione con l’ambiente Grid ed adoperare tutte le 
risorse sulle quali possiedono i diritti d’accesso, senza dover ripetere il 
processo di log-on. 
Architettura di DataGRID 
 
10
™ Delega. Un programma eseguito su richiesta di un utente deve ereditare da 
esso tutte le autorizzazioni per poter adoperare le risorse sulle quali l’utente 
possiede i diritti d’accesso. Inoltre, qualora il programma dovesse richiedere 
l’intervento di un altro programma, deve poter fornire a quest’ultimo un 
insieme ridotto di autorizzazioni (delega ristretta). 
™ Integrazione con i sistemi di sicurezza locali. Ogni sito deve poter adoperare i 
propri protocolli di sicurezza ed i meccanismi implementati nell’ambiente 
Grid devono dialogare con questi senza compromettere la sicurezza locale. 
1.1.3. Livello Resource: Accesso alle Risorse 
Il livello Resource si preoccupa di rendere uniforme l’accesso a risorse eterogenee, ossia 
crea risorse logiche uniformi adoperando quelle del livello Fabric. I componenti di 
questo livello possono essere suddivisi in due categorie [6]: 
™ Sistemi informativi. Forniscono informazioni sulla struttura e lo stato di una 
risorsa, come ad esempio la sua configurazione, il carico e le politiche 
d’utilizzo. 
™ Sistemi di gestione. Permettono l’accesso e l’utilizzo condiviso delle risorse, 
nel rispetto delle politiche d’accesso stabilite dall’amministrazione locale. 
 
Osserviamo che le componenti del livello Resource dialogano con le risorse del livello 
Fabric, per cui essi devono possedere un certo grado di specializzazione su queste 
ultime. 
1.1.4. Livello Collective: Coordinazione delle Risorse 
Se il livello Resource permette l’accesso ad una risorsa, il livello Collective contiene i 
servizi che permettono l’utilizzo e la coordinazione di più risorse. I servizi di questo 
livello si distinguono in [6]: 
™ Servizi di indicizzazione. Permettono di scoprire l’esistenza di risorse, dando 
la possibilità di effettuare ricerche per nome, per attributi come la tipologia, la 
disponibilità, il carico. 
™ Servizi di co-allocazione, scheduling e brokering. Permettono l’allocazione di 
una o più risorse pianificando l’esecuzione di tasks. 
Architettura di DataGRID 
 
11
™ Servizi di replicazione dati. Permettono la gestione dei dati realizzando i 
meccanismi come la replicazione, che incrementano le prestazioni 
nell’accesso ai dati, in base a metriche come il tempo di risposta, il costo e 
l’affidabilità. 
™ Servizi di individuazione del software. Permettono la scelta della “miglior” 
implementazione software e della “miglior” piattaforma d’esecuzione. 
 
Osserviamo che l’utilità e l’utilizzo dei servizi del livello Collective, dipende dalle 
applicazioni, per cui essi devono possedere un certo grado di specializzazione su queste 
ultime. 
1.1.5. Livello Application: Applicazioni delle Griglie Computazionali 
Il livello Application è costituito sia dagli strumenti (linguaggi, librerie, compilatori) che 
permettono la realizzazione di applicazioni Grid, che queste ultime stesse [3]. 
L’eterogeneità delle risorse degli ambienti Grid permettono l’esecuzione di 
un’ampia varietà di applicazioni; tuttavia quelle che più si avvantaggiano di un 
ambiente siffatto sono quelle che sfruttano: 
™ Supercalcolo distribuito. E’ necessario tutte le volte che la complessità 
dell’applicazione rende improponibile la sua esecuzione su un unico 
elaboratore. Un esempio è costituito dalla simulazione interattiva distribuita, 
spesso adoperata in ambito militare per l’addestramento. Questi sistemi 
simulano l’interazione fra centinaia di migliaia di entità che potenzialmente 
assumono comportamenti complessi. Altri esempi sono costituiti dalla 
simulazione degli esperimenti di fisica delle alte energie, di cosmologia e di 
chimica [1]. 
™ Elaborazione high-throughput. Con l’elaborazione high-throghput si cerca di 
pianificare l’esecuzione di un gran numero di tasks debolmente correlati, in 
modo da adoperare la potenza computazionale degli elaboratori 
temporaneamente inutilizzati. Ad esempio, alla Advanced Micro Devices 
(AMD) è stata adoperata questa tecnica durante la progettazione dei 
microprocessori K6 e K7. Gli elaboratori adoperati erano sparsi sulle 
scrivanie degli ingegneri nelle diverse sedi della AMD e venivano usati per la 
verifica del progetto quando risultavano inutilizzati. Un altro esempio lo 
Architettura di DataGRID 
 
12
abbiamo con il sistema Condor della University of Wisconsin, adoperato per 
la gestione delle workstations delle università e dei laboratori sparsi per il 
mondo, durante la simulazione molecolare dei cristalli liquidi e durante lo 
studio dei radar GPR (Ground Penetrating Radar) [1]. 
 
 
APPLICATION 
 
Supercalcolo Distribuito, High-throughput, On-demand, Data-intensive 
 
 
Linguaggi, Librerie, Compilatori 
 
 
COLLECTIVE 
 
Ricerca delle Risorse, Co-allocazione, Scheduling, Brokering, Replicazione dei Dati, 
Individuazione del Software 
 
 
RESOURCE 
 
Monitoraggio e Gestione delle Risorse 
 
 
CONNECTIVITY 
 
Protocolli di Comunicazione, Meccanismi di Autenticazione 
 
 
FABRIC 
 
Sistemi Operativi, Sistemi Operativi di Rete, Protocolli di Comunicazione, Database 
Supercomputer, Workstation, PC, Reti, Microscopi, Radiotelescopi, Satelliti, Sensori 
 
Figura 4.1: Dettagli dell’architettura a livelli. 
™ Elaborazione on-demand. L’elaborazione on-demand viene adoperata 
ogniqualvolta c’è la necessità di una gran potenza computazionale per un 
breve periodo di tempo. Proprio il breve periodo d’utilizzo rende non 
conveniente l’acquisto degli elaboratori necessari [1]. 
™ Elaborazione data-intensive. Le applicazioni data-intensive sintetizzano 
nuove informazioni partendo dai dati conservati in database distribuiti 
Architettura di DataGRID 
 
13
geograficamente. Ad esempio, durante un esperimento di fisica delle alte 
energie vengono raccolti un terabyte (1 TB ≈  1.100 ×  10
12
 byte) di dati al 
giorno, che corrispondono a circa mezzo petabyte (1 PB ≈  1.126 ×  10
15
 byte) 
l’anno e le applicazioni d’analisi accedono ad una considerevole frazione di 
questi dati, alla ricerca di eventi interessanti. Una situazione analoga la si ha 
nello studio del genoma umano [1]. 
1.2. Globus 
Globus Toolkit fornisce un’infrastruttura middleware che permette la realizzazione di 
Griglie Computazionali. 
Dal momento che una Griglia Computazionale deve supportare un’ampia varietà 
di applicazioni e paradigmi di programmazione, piuttosto che fornire una struttura 
monolitica ed uniforme, Globus Toolkit mette a disposizione una serie di servizi con i 
quali si possono realizzare strumenti ed applicazioni adattabili alle diverse esigenze [8]. 
La struttura modulare di Globus permette di adoperare solo alcuni servizi, dando la 
possibilità, in seguito, di incorporare gli altri in modo incrementale. 
L’architettura di Globus è a strati e servizi globali ad alto livello si appoggiano su 
servizi locali a basso livello [3]. I principali servizi forniti da Globus Toolkit sono [8]: 
™ Grid Security Infrastructure (GSI); 
™ Metacomputing Directory Service (MDS) anche conosciuto come Grid 
Information Service (GIS); 
™ Globus Resource Allocation Manager (GRAM). 
1.2.1. Grid Security Infrastructure (GSI) 
Il modulo GSI di Globus Toolkit costituisce un’implementazione dello standard (RFC 
2078 / 2743) Generic Security Service Application Program Interface (GSS-API), 
basata sui certificati X.509 e realizzata adoperando le librerie OpenSSL [9]. 
Il sistema di sicurezza di Globus si basa sulla crittografia a chiave pubblica. Nella 
crittografia a chiave pubblica ogni entità dispone di due chiavi: una pubblica, l’altra 
privata. Le due chiavi sono matematicamente correlate: la chiave privata viene 
adoperata, sfruttando opportuni algoritmi, per cifrare un messaggio, quella pubblica per 
decifrarlo. Questo significa che, il linea di principio, si può risalire dalla chiave pubblica 
a quella privata tuttavia, con le conoscenze matematiche e con la potenza 
Architettura di DataGRID 
 
14
computazionale attualmente disponibili, sarebbe necessaria un’elaborazione 
incredibilmente lunga dell’ordine di milioni di anni [10]. 
Un’entità può dar prova di essere la proprietaria di una certa chiave pubblica, 
semplicemente cifrando un messaggio con la propria chiave privata: se tale messaggio è 
decifrabile per mezzo della chiave pubblica della quale si vuole verificare la proprietà, 
allora la verifica ha esito positivo [10]. In modo analogo è possibile firmare i messaggi 
per attestarne la provenienza: si calcola un codice hash del messaggio, si cifra tale 
codice con la chiave privata e il risultato costituisce la firma. Il destinatario per 
verificare l’autenticità del messaggio calcola il codice hash del messaggio (privato della 
firma), decifra la firma per mezzo della chiave pubblica del mittente e verifica che 
coincida con il codice hash calcolato [11]. 
Certificati 
Il certificato costituisce il concetto alla base del sistema di sicurezza di Globus. Esso 
identifica ogni utente ed ogni servizio della Griglia Computazionale e contiene [12]: 
™ il nome del soggetto rappresentato dal certificato, 
™ la sua chiave pubblica, 
™ l’identità dell’autorità di certificazione (CA: Certificate Authority) che ha 
firmato il certificato per attestare che la chiave pubblica riportata appartenga 
al soggetto che reclama la proprietà del certificato, 
™ la firma della CA. 
 
Il GSI codifica i certificati secondo lo standard X.509 [12]. 
Si può notare, quindi, che viene adoperata una terza entità (il CA) che certifica il 
collegamento fra la chiave pubblica e soggetto del certificato. Inoltre, affinché il 
contenuto del certificato possa essere considerato attendibile, è necessario essere a 
conoscenza del certificato della CA in quanto, tramite esso, è possibile verificare 
l’autenticità della firma dell’autorità certificante [12]. 
Quando un’entità è a conoscenza del certificato di una CA si dice che l’autorità è 
fidata [12]. 
Architettura di DataGRID 
 
15
Mutua Autenticazione 
Affinché due entità possano comunicare è necessario che si autentichino 
vicendevolmente. Perché questo sia possibile, l’una deve riconoscere come fidato il CA 
che garantisce l’associazione fra il nome del soggetto rappresentato dal certificato e la 
chiave pubblica in esso riportata. Questo meccanismo è noto come mutua 
autenticazione [12] ed avviene adoperando il protocollo Secure Socket Layer (SSL), 
attualmente noto come Transport Security Layer (TSL). 
Illustriamo questo processo con un esempio. Supponiamo che due entità A e B 
vogliano stabilire una connessione: 
1. A fornisce a B il suo certificato. 
2. Per mezzo del certificato ricevuto, B viene a conoscenza dell’identità che A 
sostiene di avere, della sua chiave pubblica e del CA che certifica l’autenticità 
dell’associazione fra identità e chiave pubblica. 
3. B deve verificare che tutto sia vero; per far ciò è necessario che riconosca 
come fidato il CA certificante, in questo caso B possiede una copia del 
certificato del CA, in caso contrario l’autenticazione non può proseguire. 
4. Nell’ipotesi che il CA sia riconosciuto come fidato, l’entità B verifica la 
correttezza della firma posta dal CA sul certificato di A. Se tale firma è 
corretta, B può essere sicuro che la firma pubblica di A corrisponde 
all’identità che A sostiene di possedere. 
5. A questo punto è necessario verificare che A sia effettivamente chi sostiene di 
essere. Per far ciò B genera un messaggio casuale, lo spedisce ad A e gli 
chiede di cifrarlo. 
6. A cifra il messaggio adoperando la sua chiave privata e lo rispedisce a B. 
7. B decifra il messaggio ricevuto per mezzo della chiave pubblica di A e se 
corrisponde al messaggio originale, B può essere certo dell’identità di A. 
8. A questo punto l’intero procedimento viene ripetuto da A per autenticare B. 
 
Osserviamo che la crittografia a chiave pubblica viene adoperata solo in fase di 
autenticazione mentre, normalmente, la comunicazione fra le due entità che hanno 
stabilito la connessione avviene in chiaro per evitare l’overhead generato dalle 
operazioni di cifratura/decifratura. Tuttavia se lo si desidera è possibile cifrare anche la 
comunicazione (comunicazione confidenziale) [12].