,QIUDVWUXWWXUHD&KLDYH3XEEOLFDH ... · 1,1752’8=,21(La sempre maggiore diffusione delle reti di...

8QLYHUVLWj��GHJOL��6WXGL��GL��%RORJQD

FACOLTA’ DI INGEGNERIA

Corso di Laurea in Ingegneria Informatica

Reti di Calcolatori

,QIUDVWUXWWXUH�D�&KLDYH�3XEEOLFD�H

$JHQWL�0RELOL�SHU�LO�UHFXSHUR�H�OD

FRQYDOLGD�GHL�&HUWLILFDWL�(OHWWURQLFL

Tesi di Laurea di: Relatore:

ANGELO COLANTONIO Chiar.mo Prof. Ing. ANTONIO CORRADI

Correlatori:

Chiar.mo Prof. Ing. EUGENIO FALDELLA

Dott.ssa Ing. REBECCA MONTANARI

��$QQR�$FFDGHPLFR��

3DUROH�&KLDYH�

Sicurezza

Agenti Mobili

Firma Digitale

Sistemi di Certificazione

Liste di Revoca

$L�PLHL�JHQLWRUL

FRQ�LPPHQVR�DPRUH

I

,1',&(

,1752'8=,21(��

&$3,72/2��6,&85(==$�(�&5,772*5$),$��

1.1 INTRODUZIONE ..................................................................................................... 31.2 CRITTOGRAFIA A CHIAVE SIMMETRICA ................................................................. 51.3 CRITTOGRAFIA A CHIAVE PUBBLICA ..................................................................... 71.4 LA FIRMA DIGITALE .............................................................................................. 91.5 LA NECESSITÀ DI COPPIE DI CHIAVI DISTINTE PER CIFRATURA E FIRMA............... 121.6 CERTIFICATI ELETTRONICI.................................................................................. 14

&$3,72/2��6,67(0,�',�&(57,),&$=,21(��

2.1 INTRODUZIONE ................................................................................................... 172.2 GESTIONE DEI CERTIFICATI ELETTRONICI............................................................ 18�� *HVWLRQH�GHOOH�FKLDYL �� &LFOR�GL�YLWD�GHL�FHUWLILFDWL��

2.3 LO STANDARD X.509 PER I CERTIFICATI............................................................. 21

&$3,72/2��,1)5$67587785(�$�&+,$9(�38%%/,&$��

3.1 INTRODUZIONE ................................................................................................... 253.2 REQUISITI DI UNA PKI ........................................................................................ 263.3 COMPONENTI DI UNA PKI ................................................................................... 273.4 DEFINIZIONE DI CAMMINO DI CERTIFICAZIONE.................................................... 293.5 FUNZIONALITÀ DI UNA PKI................................................................................. 313.6 LA REVOCA DI UN CERTIFICATO.......................................................................... 333.7 MODELLI ORGANIZZATIVI DI PKI........................................................................ 37�� 6WUXWWXUD�JHUDUFKLFD �� 6WUXWWXUD�GLVWULEXLWD��

&$3,72/2��6,67(0,�',�',5(&725<��

4.1 INTRODUZIONE ................................................................................................... 434.2 ALCUNI ESEMPI DI DIRECTORY SERVICE E LORO LIMITAZIONI. ........................... 444.3 LA SOLUZIONE ATTRAVERSO LA DEFINIZIONE DI UNO STANDARD:X.500............ 454.4 IL MODELLO INFORMATIVO ................................................................................ 484.5 IL MODELLO FUNZIONALE .................................................................................. 494.6 IL PROTOCOLLO DI COMUNICAZIONE DAP.......................................................... 524.7 METODI PER LA RICERCA DELLE INFORMAZIONI. ................................................ 544.8 UN PROTOCOLLO "LEGGERO" DI ACCESSO ALLE DIRECTORY PER INTERNET LDAP55

&$3,72/2��6,67(0,�',675,%8,7,�(�02%,/,7$�'(/�&2',&(��

5.1 INTRODUZIONE ................................................................................................... 575.2 I SISTEMI DISTRIBUITI ......................................................................................... 575.3 MODELLO CLIENT-SERVER................................................................................. 615.4 MOBILITÀ DEL CODICE........................................................................................ 625.5 CONTROLLO SULLA LOCAZIONE DELLE RISORSE................................................. 635.6 LINGUAGGI A CODICE MOBILE............................................................................. 64

5.7 PARADIGMI DI PROGETTAZIONE BASATI SULLA MOBILITÀ DEL CODICE................66�� 5HPRWH�(YDOXDWLRQ �� &RGH�RQ�GHPDQG �� $JHQWL�PRELOL ��

5.8 AGENTI MOBILI ...................................................................................................69�� 0LJUD]LRQH �� &RPXQLFD]LRQH�WUD�DJHQWL �� 6LFXUH]]D ��

5.8.3.1 Riservatezza ed integrità ..........................................................................735.8.3.2 Autenticazione..........................................................................................735.8.3.3 Autorizzazione e controllo degli accessi ..................................................73

5.9 JAVA UN LINGUAGGIO ADATTO PER I SISTEMI AD AGENTI ....................................745.10 SISTEMI ESISTENTI AD AGENTI MOBILI.................................................................78�� 7HOHVFULSW �� 2GLVVH\�� $JOHWV �� 9R\DJHU ��

&$3,72/2��620$�81�6,67(0$�$'�$*(17,�02%,/, ��

6.1 INTRODUZIONE ....................................................................................................836.2 ARCHITETTURA GENERALE DEL SISTEMA ............................................................846.3 AGENTI MOBILI...................................................................................................856.4 MOBILITÀ ............................................................................................................866.5 COMUNICAZIONE.................................................................................................87�� &RPXQLFD]LRQH�WUD�$JHQWL�VLWXDWL�VX�SODFH�GLYHUVL �� &RPXQLFD]LRQH�WUD�$JHQWL�VLWXDWL�VXOOR�VWHVVR�SODFH ��

6.6 SICUREZZA ..........................................................................................................89�� 3URWH]LRQH�GHOODPELHQWH �� 3URWH]LRQH�GHJOL�DJHQWL ��

&$3,72/2��6,67(0,�3(5�,/�5(&83(52�'(,�&(57,),&$7,��

7.1 INTRODUZIONE....................................................................................................917.2 RICERCA E CONVALIDA DEI CAMMINI DI CERTIFICAZIONE ...................................91�� 3.,�FRQ�VWUXWWXUD�JHUDUFKLFD �� 3.,�FRQ�VWUXWWXUD�GLVWULEXLWD �� &RQIURQWR�WUD�OH�GXH�RUJDQL]]D]LRQL�GL�3.,��

7.3 SISTEMA CLIENT/SERVER: I PROTOCOLLI LDAP E OCSP...................................957.4 UN SISTEMA AD AGENTI MOBILI PER LA RICERCA E CONVALIDA DEI CERTIFICATI95�� 0RWLYD]LRQL�� $UFKLWHWWXUD �� $JHQWL�GL�VHUYL]LR�H�VHUYL]L�UHDOL]]DWL�� 8WLOL]]R�GHL�YDUL�DJHQWL �� 7HFQLFD�GL�ULFHUFD�H�FRQYDOLGD�GHO�FDPPLQR�GL�FHUWLILFD]LRQH ��

7.4.5.1 PKI con struttura gerarchica.....................................................................987.4.5.2 Gestione dell’insuccesso...........................................................................99

�� 3.,�FRQ�VWUXWWXUD�GLVWULEXLWD �� &RQYDOLGD�GHO�FDPPLQR�LQ�DVVHQ]D�GHO�VHUYL]LR�2&63 �� 2VVHUYD]LRQL�H�SRVVLELOL�PLJOLRULH ��

&$3,72/2��,03/(0(17$=,21(�(�5,68/7$7, ��

III

8.1 INTRODUZIONE ................................................................................................. 1038.2 LA SCELTA DEL SUPPORTO ................................................................................ 1038.3 L’INTERFACCIA TRA IL SISTEMA E I SERVIZI DI DIRECTORY............................... 1048.4 IL SISTEMA PER IL RECUPERO E LA CONVALIDA DEI CERTIFICATI AD AGENTI

MOBILI........................................................................................................................ 1048.5 LA SICUREZZA DEGLI AGENTI RICERCA ............................................................. 111�� 3URWH]LRQH�VXOOD�UHWH�GL�FRPXQLFD]LRQH �� 3URWH]LRQH�QHL�SODFH�GL�HVHFX]LRQH�� /H�YDULDELOL�LQWHUQH ��

8.6 I TEST DELL’APPLICAZIONE E L’ANALISI DELLE PRESTAZIONI ............................ 112

&$3,72/2��&21&/86,21,��

$33(1',&(��$&&(662�$�',5(&725<�(�/,1*8$**,2�-$9$��-1',� ��

%,%%/,2*5$),$ ��

1

,1752'8=,21(

La sempre maggiore diffusione delle reti di calcolatori, grazie soprattutto

all’espansione di Internet e del Web, sta portando profonde innovazioni nei

processi economici e sociali, offrendo l’opportunità di realizzare su rete servizi di

tipo amministrativo, commerciale e finanziario. Indubbiamente l’utilizzo della

rete comporta innumerevoli vantaggi dalla possibilità di scambiare informazioni

in tempi rapidissimi e senza vincoli geografici, alla praticità di trattamento e di

archiviazione dei dati.

Tuttavia le informazioni che viaggiano attraverso una rete così aperta

possono essere intercettate e subire alterazioni e contraffazioni. Al fine di

proteggere le comunicazioni su rete dai pericoli derivanti da un uso illecito delle

informazioni è quindi indispensabile fornire contromisure di sicurezza mirate a

garantire l’integrità, l’autenticità, la riservatezza e il non ripudio dei dati.

La tecnologia della crittografia a chiave pubblica sembra fornire la

risposta più adeguata a queste esigenze di sicurezza, che una rete distribuita come

Internet richiede; in particolare permette l’autenticazione dell’origine dei dati,

l’integrità e il supporto per il non ripudio attraverso la firma digitale, e garantisce

la riservatezza tramite operazioni di cifratura dei dati.

Affinché tale tecnica sia utilizzabile su larga scala, si richiede la

realizzazione di infrastrutture a chiave pubblica (PKI), con il compito specifico

di gestire il ciclo di vita delle chiavi crittografiche. In uno scenario costituito da

una molteplicità di PKI è impensabile che ogni utente abbia diretta conoscenza

delle chiavi pubbliche di ogni potenziale interlocutore, sotto forma di certificati

elettronico, o delle chiavi pubbliche delle corrispondenti autorità di certificazione

competenti. Occorre, quindi, disporre di un meccanismo corretto di ritrovamento

e convalida dei certificati elettronici degli interlocutori appartenenti a differenti

domini di sicurezza.

Nella costruzione di infrastrutture a chiave pubblica scalabili, una delle

difficoltà principali consiste nell’individuare e successivamente validare una

sequenza di certificati che garantisca la corretta associazione tra una chiave

pubblica e una certa identità fisica. A tal fine nasce l'esigenza di progettare

sistemi affidabili ed efficienti per il recupero e la verifica dei certificati.

Si ritiene che la ricerca dei certificati elettronici in ambiente distribuito

possa essere notevolmente migliorata, sia in termini di efficienza che di riduzione

del traffico di rete, utilizzando il paradigma di programmazione ad Agenti

Mobili; le caratteristiche peculiari di questo modello lo rendono particolarmente

adatto alla ricerca di informazioni in sistemi distribuiti.

Lo scopo di questa tesi è quello di proporre e sperimentare delle soluzioni

efficaci, basate su agenti mobili, per costruire e verificare cammini di

certificazione in tempi brevi.

Inizialmente è stata svolta un’analisi dei requisiti progettuali e funzionali

di un’infrastruttura a chiave pubblica con particolare attenzione al processo di

ricerca dei certificati e di determinazione dei cammini di certificazione (Capitoli

1-3); si è in particolare analizzato l’organizzazione dei sistemi di Directory

X.500 per comprendere come i certificati possono essere pubblicati e recuperati

(Capitolo 4). Successivamente è stato analizzato il modello di programmazione

ad agenti mobili per comprendere lo stato dell’arte di tale tecnologia e il suo

utilizzo per applicazioni di ricerca di informazioni (Capitoli 5-6). Una volta a

disposizione delle conoscenze e degli strumenti necessari, si è passati alla

definizione delle specifiche di un sistema ad agenti mobili per il recupero e la

convalida dei certificati e alla realizzazione di un'applicazione prototipale

(Capitoli 7-8). Infine si è svolta un’analisi delle prestazioni del sistema realizzato

(Capitoli 8-9).

3

&DSLWROR��6,&85(==$�(�&5,772*5$),$

�� ,QWURGX]LRQH

Molti dizionari definiscono la sicurezza come misura necessaria per

proteggersi da situazioni di spionaggio, di attacco o di crimine in genere. Dal

punto di vista dell'informatica, per sicurezza si intendono tutte le attività che

permettono la protezione dei sistemi aziendali attraverso la verifica delle

autorizzazioni, dove solo utenti identificati dovrebbero essere abilitati all'accesso

alle reti, ai sistemi, alle applicazioni, ai dati e questo sulla base di liste per il

controllo degli accessi.

Per inquadrare meglio il problema è opportuno rifarsi al modello di

riferimento proposto dall'ISO (International Organization for Standardization)

che individua cinque classi di funzionalità necessarie per garantire il desiderato

livello di sicurezza. Queste sono:

1) FRQILGHQ]LDOLWj:� con tale funzionalità si vuole impedire di rilevare

informazioni riservate ad entità non autorizzate alla conoscenza di tali

informazioni;

2) LQWHJULWj�GHL�GDWL:� i servizi di integrità dei dati proteggono contro gli attacchi

attivi1 finalizzati ad alterare illegittimamente il valore di un dato; l'alterazione

di un messaggio può comprendere la cancellazione, la modifica, o il

cambiamento dell'ordine dei dati;

3) DXWHQWLFD]LRQH: i servizi di autenticazione garantiscono l'accertamento

dell'identità e si suddividono in:

• servizi di autenticazione dell'entità: in questo caso si autentica l'identità

presentata ad un entità remota che partecipa ad una sessione di

1 Si definisce attacco passivo un attacco con cui un intrusore intercetta semplicemente un flusso di

informazioni, senza apportare alcun genere di modifiche; con un attacco attivo, invece, l’intrusoreintroduce alterazioni al flusso di dati che possono comprendere modifica del contenuto informativo,eliminazione di tutto o solo di alcune parti del messaggio o trattenimento del messaggio per poi replicarloin tempi successivi.

comunicazione (le password sono un esempio tipico di strumenti atti ad

ottenere autenticazione dell'entità);

• servizi di autenticazione dell'origine dei dati: in questo caso si autentica

l'identità che il mittente di un messaggio rivendica di avere;

4) FRQWUROOR�GHJOL�DFFHVVL:�una volta che l'autenticazione è avvenuta, è possibile

eseguire un controllo degli accessi in modo tale da verificare che siano

utilizzate solo quelle risorse o servizi ai quali si è autorizzati;

5) VHUYL]L�GL�QRQ�ULSXGLR�� tali servizi hanno la finalità di impedire che un'entità

riesca successivamente a rinnegare con successo la partecipazione a

transazione o comunicazione a cui in realtà ha preso parte; i servizi di non

ripudio non prevengono la sconfessione di una comunicazione o di una

transazione, forniscono, invece, gli elementi per dimostrare in caso di

contenzioso l'evidenza dei fatti. Se è vero che autenticazione ed integrità dei

dati sono elementi essenziali nell'implementazione di un servizio di non

ripudio senza, il non ripudio, tuttavia, va oltre le problematiche di

autenticazione ed integrità: è, infatti, lo strumento con cui dimostrare ad una

terza parte e dopo l'accadimento del fatto che una comunicazione o

transazione è stata originata o avviata da una certa entità o consegnata ad una

certa entità. Si pensi ad esempio al caso di una persona, Alice, che invia un

ordine di acquisto di beni a Bob; la paternità dell'ordine di acquisto viene

attribuita con assoluta certezza ad Alice se si adotta un servizio corretto di

non ripudio; in caso di contenzioso Bob può dimostrare con assoluta certezza

che l'ordine di acquisto è stato spiccato da Alice. Nei documenti cartacei,

quali contratti, ordini, bonifici, è la firma autografa ad essere utilizzata per

garantire il servizio di non ripudio, nei documenti elettronici è, invece, la

tecnica crittografica di firma digitale2.

La crittografia [FAQC98] [S96] con le sue tecniche di cifratura e di firma

digitale è in grado di fornire i servizi di sicurezza sopra descritti; pertanto

rappresenta una componente basilare nell'implementazione di un sistema di

sicurezza.

2 Vedremo nei paragrafi seguenti cosa si intende veramente

5

La crittografia è lo studio della codifica e della decodifica dei dati. Il

termine FULWWRJUDILD viene dalle parole greche NU\SWRV che significa QDVFRVWR, e

JUDSKLD che significa VFULWWXUD.

Le tecniche crittografiche permettono quindi di cifrare e successivamente

decifrare un testo scritto; questo è possibile grazie all'algoritmo crittografico che

fornisce le funzioni di trasformazione di un testo da testo in chiaro a testo cifrato

e viceversa. Gli algoritmi crittografici si suddividono in due classi distinte:

DOJRULWPL�D�FKLDYH�VLPPHWULFD e�DOJRULWPL D�FKLDYH�SXEEOLFD�

�� &ULWWRJUDILD�D�FKLDYH�VLPPHWULFD

Gli algoritmi simmetrici utilizzano un singola "chiave" matematica sia per

la codifica che per la decodifica dei dati. Un messaggio sicuro viene cifrato dal

mittente utilizzando una chiave nota solamente a lui ed al destinatario.

Il principio matematico su cui si basa l'algoritmo è che cifrando un testo in

chiaro con una certa chiave e decifrando il testo cifrato con la medesima chiave

si ottiene nuovamente il testo in chiaro.

)LJ��: Schema di funzionamento di un algoritmo Simmetrico

Vediamo ora l'implementazione di un protocollo crittografico sicuro che

utilizza la tecnica di crittografia a chiave simmetrica, finalizzato a garantire una

comunicazione confidenziale tra due interlocutori, lo schema di funzionamento è

indicato in figura 1.1.

Chiave Segreta Chiave Segreta

Testo Testo Testoin chiaro criptato in chiaro

Codifica Decodifica

Algoritmo Algoritmo

Siano Alice e Bob i due interlocutori che si devono inviare messaggi

confidenziali, siano Eve3 e Mallet i potenziali intrusori, l’uno passivo, l’altro

attivo. Definiti gli attori in gioco, i passi del protocollo si possono sintetizzare

nei seguenti:

1) Alice e Bob concordano, innanzitutto, un sistema crittografico, ossia il tipo di

algoritmo simmetrico e la lunghezza della chiave da utilizzare;

2) Alice e Bob concordare e si distribuiscono una chiave segreta;

3) Alice cifra il messaggio in chiaro utilizzando l’algoritmo e la chiave di cui ai

punti precedenti;

4) Alice invia il messaggio cifrato a Bob;

5) Bob decifra il messaggio con lo stesso algoritmo e la stessa chiave.

Tale protocollo presenta alcune vulnerabilità ed è soggetto ad attacchi sia

passivi che attivi. Il punto critico del protocollo è sicuramente quello in cui Alice

e Bob concordano quale chiave segreta utilizzare. È di fondamentale importanza

che la distribuzione della chiave segreta avvenga in modo assolutamente sicuro.

Data anche per assunta una distribuzione sicura della chiave, vediamo a

quali tipi di attacchi è soggetto il protocollo.

Che cosa potrebbe fare Eve, che ricopre il ruolo di un intrusore passivo, se

intercettasse le comunicazioni tra Alice e Bob? E se fosse Mallet che ha il ruolo

di intrusore attivo, ad interporsi tra Alice e Bob?

Se Eve non ha in alcun modo la possibilità di conoscere la chiave segreta

concordata tra Alice e Bob, l'unico tipo di attacco di crittoanalisi possibile è

quello cosiddetto "ciphertextonly attack"4 a cui la maggior parte degli algoritmi

sono, tuttavia, resistenti; se, invece, Eve conosce la chiave simmetrica di

cifratura, è in grado ovviamente di interpretare il contenuto dei messaggi tra

Alice e Bob.

Mallet, invece, può intercettare i messaggi scambiati tra Alice e Bob,

alterarne il contenuto inficiandone l'integrità del contenuto, o effettuare delle

sostituzioni.. Se Mallet è venuto a conoscenza della chiave segreta che Alice e

3 Eve richiama il termine inglese "eavesdropper" con cui si indica colui che sta in ascolto; Eve è l'attore

in gioco che nei protocolli crittografici ricopre il ruolo dell'intrusore passivo. Mallet, invece, sta per"malicious active attacker" e ricopre il ruolo dell'intrusore attivo.

4 Il crittoanalista dispone solo di campioni di testo cifrato; a partire da tali campioni tenta di dedurre lachiave di cifratura o di trovare un algoritmo alternativo attraverso risalire al testo in chiaro.

7

Bob hanno concordato, Mallet può intercettare i messaggi inviati da Alice a Bob

e sostituirli con messaggi non autentici. Alla ricezione, Bob non è in grado di

distinguere chi effettivamente è il vero mittente dei messaggi, continua a pensare

che l'originatore dei dati sia Alice; il protocollo descritto, quindi, non fornisce

alcun tipo di autenticazione dell'origine dei dati.

Dalle considerazioni di cui sopra emerge chiaramente che i protocolli

crittografici di comunicazione realizzati con algoritmi simmetrici presentano sia

difficoltà implementative che limiti di sicurezza. Il problema implementativo

principale è legata alla difficoltà di distribuire le chiavi simmetriche in modo

sicuro e su larga scala; se si assume che una chiave distinta è richiesta per ogni

coppia di interlocutori, il numero di chiavi da distribuire aumenta drasticamente

all'aumentare delle parti in gioco; se, infatti, n sono le parti coinvolte, il numero

di chiavi da distribuire è pari a n*(n-l)/2. 1 limiti di sicurezza, invece, sono dati

dalla mancanza, a livello di protocollo, di strumenti che garantiscano integrità ed

autenticazione dell'origine dei dati.

�� &ULWWRJUDILD�D�FKLDYH�SXEEOLFD

Fino a poco più di vent'anni fa erano conosciuti solo gli algoritmi a chiave

simmetrica; nel 1976 Diffie ed Hellman [DH76] presentarono un protocollo per

lo scambio di una chiave segreta attraverso un canale insicuro; tale meccanismo

era stato inteso essenzialmente per risolvere il problema dell'avvio di un normale

sistema di cifratura a chiavi simmetriche, ma in realtà ha posto le basi della

crittografia a chiave pubblica.

Gli algoritmi a chiave pubblica o altrimenti detti asimmetrici, sono

progettati in modo tale che la chiave di codifica risulta differente dalla chiave di

decodifica. Quello che viene cifrato con la chiave di codifica, detta chiave

pubblica, può essere decifrato solo con l'altra chiave di decodifica, detta chiave

privata. La conoscenza della chiave pubblica non permette di determinare quella

privata (si tratta di un problema computazionalmente complesso). Questo è il

motivo per cui la chiave di cifratura può essere resa pubblica senza

compromettere la sicurezza del sistema.

Gli algoritmi asimmetrici possono essere utilizzati sia per la

confidenzialità che per l'autenticazione, gli schemi di funzionamento sono

indicati in figura 1.2.

)LJ��: schema di funzionamento di una algoritmo asimmetrico

Se Alice vuole inviare messaggi cifrati a Bob, Alice deve cifrare i

messaggi utilizzando la chiave pubblica di Bob; soltanto Bob è in grado di

decifrare i messaggi essendo in possesso della chiave privata di decifratura. Se,

invece, Bob alla ricezione di un messaggio vuole essere garantito sull'origine dei

dati, occorre utilizzare gli algoritmi asimmetrici per fornire autenticazione

dell'origine dei dati; in tal caso l'uso delle chiavi è invertito rispetto al caso

precedente; Alice, infatti, cifra il messaggio da inviare a Bob con la propria

chiave privata e Bob decifra con la chiave pubblica di Alice. Se l'operazione di

&RQILGHQ]LDOLWj Chiave Pubblica Chiave Privata del destinatario del destinatario

Testo Testo Testo in chiaro criptato in chiaro

Codifica Decodifica

$XWHQWLFD]LRQH Chiave Privata Chiave Pubblica del mittente del mittente

Testo Testo Testo in chiaro criptato in chiaro

Codifica Decodifica

Algoritmo Algoritmo

Algoritmo Algoritmo

9

decodifica ha successo, data la corrispondenza biunivoca tra le chiavi privata e

pubblica, soltanto Alice può essere effettivamente il mittente dei dati.

Per gestire la distribuzione delle chiavi in un ambiente aperto come

Internet, gli algoritmi a chiave pubblica presentano, evidentemente, vantaggi

sostanziali. Con tali algoritmi, infatti, non è necessario prevedere un canale

sicuro per la trasmissione della chiave, ma essendo la chiave di decifratura

distinta da quella di cifratura, è possibile distribuire quest'ultima in maniera non

riservata tramite dei server pubblici. Se, poi, n sono gli utenti coinvolti, n è

anche il numero di chiavi da distribuire e non n*(n-1)/2 come nel caso degli

algoritmi simmetrici.

�� /D�ILUPD�GLJLWDOH

Fino a pochissimo tempo fa la firma autografa era considerata l'unico

strumento adeguato per attribuire con certezza la paternità di un messaggio : un

documento originale, stampato su carta e firmato in maniera autografa, è ritenuto,

infatti, legalmente valido. Tale validità legale è attribuita ritenendo che:

• sia possibile rilevare alterazioni o abrasioni della carta che ne indichino una

contraffazione ;

• sia possibile ricondurre con certezza (quantomeno "legale") la firma apposta

in calce ad un documento alla persona la cui firma è apposta, e alla

manifestazione della sua volontà di sottoscrivere, accettare o richiedere

quanto esposto nel documento stesso.

La certezza dell'autenticità della firma, come è ben evidente a chiunque

abbia falsificato la firma di un conoscente, è assai lontana dalla realtà. E tuttavia

la legge tutela questa forma di manifestazione della volontà, e la considera

talmente valida da richiedere che certi documenti, di cui si ipotizza una futura

contestazione, debbano essere conservati per lunghi periodi di tempo.

La firma digitale, invece, è, oggi, la tecnologia con cui possono essere

effettivamente soddisfatti tutti i requisiti richiesti per dare validità legale ad un

documento elettronico firmato digitalmente; garantisce i servizi di integrità,

autenticazione e non ripudio.

Analizziamo quali sono le proprietà richieste al processo di apposizione di

una firma, proprietà che nel caso della firma autografa si assume siano garantite,

nel caso della firma digitale, invece, se ne ha la certezza:

• autenticità della firma: la firma deve assicurare il destinatario del documento

che il mittente ha deliberatamente sottoscritto il contenuto del documento;

• non falsificabilità: la firma è la prova che solo il firmatario e nessun altro ha

apposto la firma sul documento;

• non riusabilità: la firma fa parte integrante del documento, non deve essere

utilizzare su un altro documento;

• non alterabilità: una volta firmato, il documento non deve poter essere

alterato;

• non contestabilità: il firmatario non può rinnegare con successo la paternità

dei documenti firmati; la firma attesta la volontà del firmatario di

sottoscrivere quanto contenuto nel documento.

Grazie alla tecnologia di firma digitale tutte le proprietà di cui sopra sono

assolutamente soddisfacibili. La firma digitale può essere realizzata tramite

tecniche crittografiche sia simmetriche che a chiave pubblica. Dati gli svantaggi

di scalabilità introdotti da schemi di firma digitale che utilizzano la crittografia

simmetrica, la firma digitale viene implementata con la crittografia a chiave

pubblica.

L'algoritmo di cifratura a chiave pubblica è intrinsecamente inefficiente ed

applicarlo all'intero testo che può essere molto lungo può richiedere troppo

tempo; l'utilizzo di particolari funzioni matematiche, chiamate funzioni hash

unidirezionali (l'unidirezionalità è dovuta al fatto che dato x è facile calcolare

f(x), dato, invece, f(x) è computazionalmente difficile risalire a x) permette di

ridurre questo tempo.

Il processo di firma digitale, indicato in figura 1.3, si compone di tre parti:

1) Generazione dell'impronta digitale del testo.

2) Generazione della firma.

3) Apposizione della firma.

Inizialmente fase viene applicata al documento in chiaro una funzione

hash appositamente studiata che produce una stringa binaria di lunghezza

11

costante e piccola, tipicamente 128 o 160 bit, chiamata GLJHVW� PHVVDJH, ossia

impronta digitale. Questo hash costruito viene cifrato con la chiave privata del

mittente, il risultato non è altro che la firma digitale, la quale viene aggiunta in

una posizione predefinita, normalmente alla fine, al testo; ottenendo così il

documento firmato.

)LJ��: generazione della firma

Il ricevente verifica la firma digitale ricalcolando, con la medesima

funzione usata nella fase di firma, un hash nuovo a partire dal documento in

chiaro ricevuto; poi decifra l'hash ricevuto e cifrato dal firmatario; controlla se

l'hash nuovo calcolato corrisponde all'hash ricevuto e se i due hash coincidono il

processo di verifica si conclude con successo.

)LJ��: verifica della firma

Lo schema del processo di verifica è indicato in figura 1.4.

L’algoritmo per la firma digitale più utilizzato è RSA [RSA78], mentre

per le funzioni hash citiamo SHA-1 [S96] e MD5 [RFC1321].

�� /D�QHFHVVLWj�GL�FRSSLH�GL�FKLDYL�GLVWLQWH�SHU�FLIUDWXUD�HILUPD

L'algoritmo a chiave pubblica ha la proprietà di permettere sia operazioni

di cifratura sia operazioni di firma digitale con la stessa coppia di chiavi

crittografiche; tuttavia un tale uso doppio della coppia di chiavi è sconsigliato. 1

motivi sono deducibili dall'esame dei requisiti di gestione che sono differenti nel

caso in cui le chiavi siano utilizzate per la cifratura o per la firma digitale.

Per la coppia di chiavi di firma digitale si devono, infatti, rispettare i

seguenti requisiti [F94]:

• la chiave privata di firma deve essere custodita durante l'intero periodo di

validità in modo tale che solo il suo legittimo possessore può averne accesso;

tale requisito, si ribadisce nuovamente, è un presupposto fondamentale per

fornire supporto a servizi di non ripudio; è comunemente raccomandato,

talvolta imposto, che la chiave di firma sia custodita all'interno dello stesso

dispositivo in cui sarà utilizzata;

• una chiave privata di firma non necessita, in generale, di essere sottoposta a

backup a protezione contro perdite accidentali della chiave privata; se la

chiave di firma, infatti, viene accidentalmente persa, una nuova coppia di

chiavi di firma può essere facilmente generata; sottoporre a backup la chiave

privata di firma contrasterebbe con il primo requisito;

• una chiave privata di firma non necessita di essere archiviata; l'archiviazione

contrasterebbe con il primo requisito; una chiave privata di firma deve essere

distrutta in modo sicuro allo scadere della sua validità; se, infatti, si potesse

risalire al suo valore anche dopo la cessazione del suo utilizzo, tale chiave

privata potrebbe ugualmente essere utilizzata per falsificare la firma su vecchi

documenti; l'impiego di servizi di opposizione di un timbro orario

(time/stamping) sicuro ridurrebbe il rischio conseguente ad una mancata

13

rilevazione di firma falsa; tuttavia, i servizi di time/stamping non sono ancora

diffusamente implementati;

• una chiave pubblica di firma necessita di essere archiviata; tale chiave

potrebbe essere utilizzata per la verifica di firme apposte su documenti in

tempi successivi alla scadenza della validità della coppia di chiavi di firma.

Per la coppia di chiavi di cifratura, invece, si devono rispettare i seguenti

requisiti, in contrasto con i precedenti:

• la chiave privata, utilizzata nelle operazioni di decifratura, necessita

generalmente di essere sottoposta a backup od archiviata; solo tramite

l'archiviazione o backup è possibile risalire dai dati cifrati al corrispondente

testo in chiaro (si ottiene il recupero dei dati tramite il cosiddetto meccanismo

di recovery); se una chiave privata è andata persa (i motivi possono essere

dovuti o alla corruzione del dispositivo di protezione della chiave o alla

dimenticanza o perdita da parte del legittimo possessore del segreto utilizzato

per sbloccare l'accesso al dispositivo di protezione) e non ci sono meccanismi

di recupero della chiave, è inaccettabile perdere irrimediabilmente l'accesso ai

dati cifrati con quella chiave;

• la chiave pubblica utilizzata per la cifratura dei dati non necessita

generalmente di archiviazione; l'algoritmo utilizzato determina se un backup

della chiave pubblica è necessario o meno (se si utilizza un meccanismo di

trasporto delle chiavi basato su RSA, il backup non è necessario, può

diventarlo se si utilizza, invece, Diffie-Hellmann per lo scambio delle chiavi);

• la chiave privata non deve essere distrutta allo scadere della sua validità di

impiego per poter continuare a decifrare in futuro i documenti cifrati con la

corrispondente chiave pubblica.

Alla luce delle considerazioni elencate è evidente, quindi, che sarebbe

impossibile garantire il soddisfacimento contemporaneo di tutti i requisiti se si

impiega un'unica coppia di chiavi sia per la cifratura che per la firma.

Alla precedente ragione si aggiungono anche, in seconda istanza, altri

motivi:

• le implementazioni a chiave pubblica utilizzate a supporto della cifratura sono

tipicamente soggette a limiti di esportazioni più restrittivi rispetto a quelli

previsti per la firma digitale; ad esempio la lunghezza della chiave di cifratura

può essere limitata ad un valore più basso rispetto a quella di firma;

• le chiavi di firma e di cifratura possono avere validità temporali differenti per

motivi di politica organizzativi/gestionali e di sicurezza;

• non tutti gli algoritmi a chiave pubblica hanno la proprietà di effettuare sia

cifratura sia firma con la stessa coppia di chiavi.

�� &HUWLILFDWL�HOHWWURQLFL

Nella tecnologia di crittografia a chiave pubblica sia in fase di cifratura

che in fase di verifica di una firma digitale, occorre ritrovare la chiave pubblica o

del destinatario di un messaggio o del firmatario del messaggio firmato. In

entrambi i casi il valore delle chiavi pubbliche non è confidenziale; la criticità del

reperimento delle chiavi sta nel garantire non la confidenzialità, ma l'autenticità

delle chiave pubbliche, ossia sta nell'assicurare che una certa chiave pubblica

appartenga effettivamente all'interlocutore per cui si vuole cifrare o di cui si deve

verificare la firma. Se, infatti, una terza parte prelevasse la chiave pubblica del

destinatario sostituendola con la propria, il contenuto dei messaggi cifrati sarebbe

disvelato e le firme digitali potrebbero essere falsificate.

La distribuzione delle chiavi pubbliche è, pertanto, il problema cruciale

della tecnologia a chiave pubblica. In un dominio con un numero limitato di

utenti si potrebbe anche ricorrere ad un meccanismo manuale di distribuzione

delle chiavi: due interlocutori che abbiano una relazione di conoscenza già

stabilita, potrebbero, ad esempio, scambiarsi reciprocamente le chiavi attraverso

floppy disk. Meccanismi di distribuzione manuali diventano, tuttavia,

assolutamente inadeguati ed impraticabili in dominio scalabile dove non c'è

alcuna diretta conoscenza prestabilita tra gli interlocutori.

Il problema della distribuzione delle chiavi pubbliche è risolto tramite

l'impiego dei certificati elettronici. I certificati a chiave pubblica costituiscono,

15

infatti, lo strumento affidabile e sicuro attraverso cui rispondere ad esigenze di

scalabilità; attraverso i certificati elettronici le chiavi pubbliche vengono

distribuite e rese note agli utenti finali con garanzia di autenticità ed integrità.

L'utilizzo dei certificati elettronici presuppone, tuttavia, l'esistenza di un'autorità

di certificazione (Certification Authority o CA) che li emetta e li gestisca.

Ogni certificato è una struttura dati costituita da una parte dati contenente

al minimo:

• informazioni che identificano univocamente il possessore di una chiave

pubblica (ad esempio il nome);

• il valore della chiave pubblica;

• il periodo di validità temporale del certificato;

e da una parte contenente la firma digitale della autorità di certificazione con cui

si assicura l'autenticità della chiave e l'integrità delle informazioni contenute nel

certificato.

17

&DSLWROR��6,67(0,�',�&(57,),&$=,21(

�� ,QWURGX]LRQH

Il sistema di distribuzione delle chiavi tramite certificati è caratterizzato da

una certa facilità di implementazione; la semplicità del meccanismo di

distribuzione delle chiavi è diretta conseguenza delle caratteristiche stesse dei

certificati: i certificati, infatti, possono essere distribuiti senza dover

necessariamente ricorrere ai tipici servizi di sicurezza di confidenzialità,

integrità, ed autenticazione delle comunicazioni.

Per le proprietà della crittografia a chiave pubblica non c'è infatti alcun

bisogno di garantire la riservatezza del valore della chiave pubblica; durante il

processo di distribuzione, poi, non ci sono requisiti di autenticazione ed integrità

dal momento che il certificato è per costruzione una struttura già protetta (la

firma digitale dell'autorità di certificazione sul certificato fornisce, infatti, sia

autenticazione sia integrità).

Se, quindi, un intrusore tentasse, durante la pubblicazione del certificato,

di alterarne il contenuto, la manomissione sarebbe immediatamente rilevata in

fase di verifica della firma sul certificato; il processo di verifica fallirebbe e

l'utente finale sarebbe avvertito della non integrità della chiave pubblica

contenuta nel certificato.

Le caratteristiche stesse del certificato permettono quindi di distribuire i

certificati a chiave pubblica anche mediante canali non sicuri (file server insicuri

o sistemi di directory o protocolli di comunicazione intrinsecamente insicuri).

�� *HVWLRQH�GHL�FHUWLILFDWL�HOHWWURQLFL

La gestione dei certificati si articola lungo tutto il suo ciclo di vita

(generazione, distribuzione, aggiornamento, sospensione e revoca) ed è

influenzata dai requisiti e dalle fasi che caratterizzano la gestione delle

corrispondenti coppie di chiavi crittografiche. I processi di generazione della

coppia di chiavi e del relativo certificato possono talvolta essere integrati.

�� *HVWLRQH�GHOOH�FKLDYL

La gestione delle coppie di chiavi (NH\�PDQDJHPHQW) si può suddividere

nelle seguenti fasi:

• JHQHUD]LRQH� GHOOD� FRSSLD� GL� FKLDYL: quando una coppia di chiavi viene

generata, è necessario provvedere ad un trasferimento sicuro sia della chiave

privata che della chiave pubblica; la chiave privata deve essere trasferita sul

sistema crittografico del possessore della coppia di chiavi e se ne è richiesta

l'archiviazione, sul sistema di archiviazione; la chiave pubblica deve, invece,

essere inviata ad una o più autorità di certificazione perché sia certificata.

Esistono due approcci alternativi per la generazione delle chiavi:

� la coppia di chiavi è generata sul sistema del possessore in cui la chiave

privata sarà poi effettivamente memorizzata ed utilizzata; nel caso che la

coppia di chiavi sia utilizzata per la firma digitale, questo approccio è

obbligatorio onde non contravvenire al requisito del non ripudio; in questo

modo si aumenta il livello di garanzia che nessun altro al di fuori del

legittimo possessore possa entrare in possesso ed utilizzare

illegittimamente la chiave privata;

� la coppia di chiavi è generata in un sistema centrale, possibilmente

associato e gestito dall'autorità di certificazione garante dell'autenticità del

corrispondente certificato elettronico; la chiave privata è poi trasferita in

modo sicuro sul sistema del suo utilizzatore; questo schema risulta

adeguato nel caso in cui sia richiesta l'archiviazione della chiave privata

utilizzata nelle operazioni di decifratura; non può, invece, essere

impiegato se la coppia di chiavi generata viene utilizzata per la firma;

19

• SURWH]LRQH� GHOOD� FKLDYH� SULYDWD: il materiale crittografico deve essere

custodito in modo sicuro, solo il legittimo possessore deve avere accesso alla

propria coppia di chiavi; l'accesso è controllabile mediante meccanismi di

autenticazione personale;

• DJJLRUQDPHQWR�GHOOD�FRSSLD�GL�FKLDYL: una politica di sicurezza adeguata deve

prevedere un aggiornamento delle chiavi con scadenze regolari o in

conseguenza a compromissioni sospettate delle chiave privata; quando una

nuova coppia di chiavi viene generata, è evidente che deve essere generato

anche un nuovo certificato

Bisogna anche mantenere una copia delle chiavi dal fatto che l'eventuale

perdita delle chiavi comporta l'impossibilità di decifrare i messaggi codificati e

verificare i documenti firmati. Spesso le organizzazioni richiedono un backup

delle chiavi dei loro membri per evitare che l'onere di mantenimento delle copie

sia esclusivamente di questi ultimi. Tali organizzazioni possono avere la

necessità di verificare documenti digitalmente firmati dai loro membri anche

oltre la validità temporale di tali chiavi e non possono fidarsi unicamente delle

eventuali copie di backup fatte dal possessore delle chiavi.

�� &LFOR�GL�YLWD�GHL�FHUWLILFDWL

L'emissione effettiva di un certificato elettronico da parte di un'autorità di

certificazione deve essere preceduta da una fase di UHJLVWUD]LRQH� dell'utente

richiedente il certificato elettronico. Attraverso il processo di registrazione

l'utente richiedente un servizio di certificazione si identifica presso l'autorità

preposta al servizio di registrazione; le credenziali che in questa fase l'utente

deve sottoporre all'autorità di registrazione dipendono fortemente dalle modalità

e procedure di registrazione definite nell'ambito di una politica di sicurezza.

Il processo di registrazione stabilisce una relazione iniziale tra utente

finale ed autorità di certificazione; l'utente finale, una volta attestata l'autenticità

della sua identità, viene registrato nel dominio di fiducia gestito dall'autorità di

certificazione. L'obiettivo, quindi, di primaria importanza del processo di

registrazione è garantire che la chiave pubblica di cui un certo utente finale

richiede la certificazione sia realmente associata e quindi appartenga, solo al

nome del richiedente e non a quello di qualcun altro utente.

Terminata la fase di registrazione, l'utente può richiedere l'emissione di un

certificato elettronico. La procedura di JHQHUD]LRQH di un certificato elettronico

consiste dei seguenti passi:

• l'utente finale sottopone all'autorità di certificazione le informazioni da

certificare;

• l'autorità di certificazione può verificare l'accuratezza delle informazioni

presentate in accordo a politiche e standard applicabili;

• l'autorità di certificazione firma le informazioni generando il cosiddetto

certificato; generato il certificato, l'autorità di certificazione può direttamente

pubblicarlo sul sistema scelto per la distribuzione dei certificati;

opzionalmente l'autorità di certificazione può archiviare una copia del

certificato; ogni operazione di generazione di certificati elettronici viene

registrata su un archivio di registrazione dati.

Ogni certificato elettronico generato ha una validità temporale limitata al

cui termine va sostituito; il periodo di validità di un certificato, in assenza di

compromissioni o usi illeciti, garantisce l'utente che deve utilizzare tale

certificato che la chiave pubblica può essere utilizzata per lo scopo per cui è stata

generata e che l'associazione tra la chiave pubblica e le altre informazioni

contenute nel certificato è ancora valida.

Anche le chiavi crittografiche dovrebbero essere periodicamente sostituite

per ragioni di sicurezza; l'aggiornamento delle chiavi comporta

conseguentemente un aggiornamento dei certificati elettronici corrispondenti;

l'aggiornamento dei certificati può essere richiesto e realizzato manualmente o

mediante un processo trasparente al possessore del certificato; questo significa

che il possessore si ritrova ad avere un certificato valido senza essersi registrato

nuovamente e senza aver esplicitamente richiesto la generazione di un nuovo

certificato. Se, tuttavia, l'autorità di certificazione prevede una politica di

sicurezza che obbliga l'utente finale a presentarsi periodicamente per

riconfermare la validità delle informazioni contenute nel certificato, è evidente

21

che il processo di aggiornamento non può essere trasparente al possessore del

certificato.

Un certificato elettronico, una volta generato ed eventualmente

aggiornato, deve essere distribuito pubblicamente; il meccanismo di distribuzione

comunemente utilizzato impiega un servizio di directory; una tecnologia

completa di servizio di directory distribuito è stato sviluppato e standardizzato

attraverso la cooperazione tra l'Intemational Telecommunication Union (ITU) e

l'International Organization for Standardization (ISO) sotto la sigla di

raccomandazioni X.500. L'adozione e l'implementazione di directory X.500,

soprattutto all'interno di grosse organizzazioni, sta solo attualmente aumentando

soprattutto grazie alla tecnologia a chiave pubblica. Analizzeremo i servizi di

directory nel quarto capitolo.

Ogni certificato elettronico ha una ben definita data di scadenza naturale,

ma in presenza di compromissioni o usi illeciti il certificato viene revocato e

cessa la sua validità. L'operazione di revoca è una fase del ciclo di vita dei

certificati ad alta criticità e prevede degli specifici sistemi di gestione che

vedremo in dettaglio nel prossimo capitolo.

�� /R�VWDQGDUG�;��SHU�L�FHUWLILFDWL

Lo standard ormai diffusamente riconosciuto di definizione del formato

dei certificati è quello descritto nello standard X.509 ISO/IEC/ITU [RFC2459]

(Visa e MasterCard hanno ad esempio adottato le specifiche X.509 come base

per la definizione dello standard per il commercio elettronico SET, Secure

Electronic Transaction). Lo standard X.509 costituisce il "framework" di

autenticazione disegnato per supportare i servizi di directory X.500. Le versioni

proposte per il formato dei certificati X.509 sono attualmente tre: la prima

versione definita nel 1988, la seconda versione uscita nel 1993 e la terza versione

del 1996.

Negli anni 1993-94, quando sono stati avviate le prime sperimentazioni

basate su X.509 su larga scala, è emerso chiaramente che le prime due versioni

dei certificati X.509 erano insufficienti a risolvere molte delle problematiche che

si presentavano.

)LJ��formato dei certificati X.509 versione 1 e 2

Si è resa evidente la necessità di introdurre nel formato dei certificati

relativo alle versioni 1 e 2 delle modifiche; molteplici sono le motivazioni che

giustificano le aggiunte, tra cui le principali si possono sintetizzare nelle

seguenti:

• ogni utente può avere più certificati per chiavi differenti; è indispensabile

inserire un meccanismo con cui poter distinguere univocamente i diversi

certificati appartenenti allo stesso possessore;

• i certificati necessitano, nell'ambito di alcune applicazioni, di riportare

all'interno informazioni dell'utente aggiuntive rispetto al semplice nome

(indirizzo di e-mail ad esempio);

• i certificati possono essere emessi secondo politiche di certificazione e per

finalità differenti; ad esempio l'autorità di certificazione potrebbe aver

emesso un certificato ad un utente affinché sia utilizzato solo per operazioni

di cifratura e non per operazioni di firma su transazioni ad alto valore

finanziario;

• le autorità di certificazione stabiliscono relazioni di fiducia reciproche; deve

essere possibile introdurre dei vincoli che regolino il trasferimento di fiducia

da un dominio di sicurezza ad un altro.

&HUWLILFDWH�IRUPDW�YHUVLRQ

&HUWLILFDWH�VHULDO�QXPEHU

6LJQDWXUH�DOJRULWP�LGHQWLILHU

,VVXHU�;��QDPH

9DOLG�SHULRG

6XEMHFW�;��QDPH

6XEMHFW�SXEOLF�NH\�LQIRUPDWLRQ

,VVXHU�8QLTXH�,GHQWLILHU

6XEMHFW�8QLTXH�,GHQWLILHU

Identifica la versione del formato

Identifica univocamente il certficato

Identificatore dell’algoritmo utilizzato dalla CA per firmare il certificato

Nome della CA nella forma X.500

Periodo di validità del cerificato

Nome del possessore nella forma X.500

Valore della chiave pubblica

Stringa di bit aggiuntivi, opzionali nel caso che nella struttura ad albero dei nomi X.500 ci siano due CA omonime


&$�VLJQDWXUH

NoninVer.1

23

Alla luce di queste motivazioni, è stata definita la versione 3 dei certificati

X.509; tale versione ha lo stesso formato della versione 2 ad eccezione di

estensioni aggiuntive finalizzate a rispondere ai requisiti sopra elencati.

)LJ��formato dei certificati X.509 versione 3

Il campo delle estensioni prevede tre sottoinsiemi: l'identificatore del tipo

di estensione, un indicatore di criticità e il valore effettivo dell'estensione;

l'indicatore di criticità facilita l'interoperabilità tra sistemi che non utilizzano

certificati con determinate estensioni e sistemi che, invece, interpretano tutte le

estensioni definite a livello di standard; l'indicatore di criticità è semplicemente

un flag che stabilisce se l'estensione è critica o non critica; se l'estensione non è

critica, significa che il sistema che deve elaborare il certificato può

eventualmente ignorare l'estensione in questione se non è in grado di

interpretarla.

Le estensioni standard definite nella versione 3 dei certificati X.509, si

suddividono fondamentalmente in quattro gruppi:

• estensioni contenenti informazioni sulla chiave pubblica; un'estensione ad

esempio specifica il tipo di utilizzo per cui è stata emessa una certa chiave;

&HUWLILFDWH�IRUPDW�YHUVLRQ


6LJQDWXUH�DOJRULWP�LGHQWLILHU

,VVXHU�;��QDPH

9DOLG�SHULRG

6XEMHFW�;��QDPH

6XEMHFW�SXEOLF�NH\�LQIRUPDWLRQ

,VVXHU�8QLTXH�,GHQWLILHU

6XEMHFW�8QLTXH�,GHQWLILHU

Identifica la versione del formato

Identifica univocamente il certficato

Identificatore dell’algoritmo utilizzato dalla CA per firmare il certificato

Nome della CA nella forma X.500

Periodo di validità del cerificato

Nome del possessore nella forma X.500

Valore della chiave pubblica



([WHQVLRQ

&$�VLJQDWXUH

([WHQVLRQ�7\SH &ULW��1RQ�FULW ([WHQVLRQ�)LHOG�9DOXH

una coppia di chiavi, infatti, può essere utilizzata per scopi differenti: per la

firma di certificati da parte dell'autorità di certificazione, per la firma digitale

da parte di utenti finali, per la cifratura dei dati, per il trasferimento di chiavi

simmetriche o per effettuare lo scambio di chiavi di cifratura tramite Diffie-

Hellmann;

• estensioni contenenti informazioni aggiuntive relative all'autorità di

certificazione e all'utente possessore del certificato (ad esempio nomi

alternativi per la CA e per l'utente, quali indirizzo di e-mail o identificativo

URL);

• estensioni contenenti informazioni sulle politiche di emissione e sulle finalità

di utilizzo dei certificati; l'estensione "certificate policy", infatti, specifica la

politica sotto cui un certificato è stato emesso; ogni certificato può avere

definite una o più politiche di certificazione; l'estensione "policy mapping",

invece, si applica quando un'autorità di certificazione crea una relazione di

fiducia con un'altra autorità di certificazione; l'estensione "policy mapping"

fornisce il meccanismo con cui controllare la compatibilità tra le politiche

differenti di autorità di certificazione;

• estensioni contenenti informazioni sui vincoli di spazio dei nomi o di politica

da imporre durante il ritrovamento o la verifica di un certificato appartenente

ad un dominio di fiducia esterno.

25

&DSLWROR��,1)5$67587785(�$�&+,$9(

38%%/,&$

�� ,QWURGX]LRQH

Le infrastrutture a chiave pubblica (Public Key Infrastructure o PKI)

forniscono il supporto necessario affinché la tecnologia di crittografia a chiave

pubblica sia utilizzabile su larga scala. Le infrastrutture offrono servizi relativi

alla gestione delle chiavi, dei certificati e delle politiche di sicurezza. Le autorità

di certificazione e la gestione dei certificati elettronici costituiscono, infatti, il

cuore delle infrastrutture a chiave pubblica. Quando, tuttavia, si cercano di

applicare i concetti relativi alla gestione dei certificati in un contesto ampio e di

elevata complessità, emergono problematiche sottili per la cui risoluzione si

rende necessaria l'adozione di servizi di infrastruttura di natura sia tecnologica

che legale aggiuntivi rispetto a quelli esaminati nelle sezioni precedenti. In uno

scenario di infrastrutture costituite da molteplici autorità di certificazione, le

problematiche da esaminare riguardano le modalità con cui trovare e validare un

cammino di certificazione5 tra autorità di certificazione, con cui organizzare e

strutturare le relazioni di fiducia tra autorità di certificazione e con cui associare

politiche di sicurezza e vincoli ai diversi cammini di certificazione.

Un'infrastruttura a chiave pubblica introduce il concetto di WKLUG�SDUW\

WUXVW, che si verifica quando due generiche entità si fidano implicitamente l'una

dell'altra senza che abbiano precedentemente stabilito una personale relazione di

fiducia.

5 I cammini di certificazione sono i mezzi attraverso cui è possibile verificare l'integrità dei certificatielettronici degli attori di una comunicazione sicura appartenenti a domini di sicurezza distinti; vedremo inseguito cosa si intende esattamente

Questo è possibile perché entrambe le entità condividono una relazione di

fiducia con una terza parte comune.

)LJ��:�7KLUG�SDUW\�WUXVW

7KLUG�SDUW\� WUXVW [CUR95] è un requisito fondamentale per qualsiasi

implementazione su larga scala che utilizzi crittografia a chiave pubblica e in una

PKI viene realizzata attraverso l'autorità di certificazione.

�� 5HTXLVLWL�GL�XQD�3.,

L'implementazione di un'infrastruttura a chiave pubblica deve tener conto

di una serie di requisiti progettuali che si possono sintetizzare nei seguenti:

• scalabilità;

• supporto per applicazioni multiple; a beneficio degli utenti finali in

termine di convenienza, sicurezza ed economia, una stessa infrastruttura

deve garantire il supporto per molteplici applicazioni (posta elettronica

sicura, applicazioni Web, trasferimento di file sicuro); il modello di

gestione della sicurezza deve essere consistente e uniforme per tutte le

applicazioni;

• interoperabilità tra infrastrutture differenti; non è certo una soluzione

praticabile quella di implementare un'unica infrastruttura rispondente alle

necessità di sicurezza di un dominio di utenti su scala globale; è evidente

27

che si deve ricorrere a domini di sicurezza distinti, ognuno amministrato

da un'infrastruttura specifica. L'interoperabilità, tuttavia, di tali

infrastrutture distinte deve essere assicurata ed è richiesta per garantire il

raggiungimento di un buon livello di scalabilità;

• supporto per una molteplicità di politiche; cammini di certificazione

considerati appropriati per un'applicazione, possono non essere considerati

altrettanto validi per un'altra applicazione; ci si potrebbe ad esempio fidare

di un'autorità di certificazione che certifica web server relativamente a

transazioni commerciali di bassa entità, ma non relativamente a

transazioni di elevato valore; per rispondere, quindi, ad entrambi i

requisiti di scalabilità e supporto per applicazioni multiple, è necessario

implementare meccanismi che permettano da un lato di attribuire politiche

differenti ai vari cammini di certificazione dall'altro di associare ad ogni

applicazione una politica di sicurezza specifica;

• conformità agli standard; una vera interoperabilità tra PKI distinte è

ottenibile soltanto con l'adozione di standard che definiscono i protocolli

funzionari e di comunicazione relativi ai componenti costitutivi di

un'infrastruttura a chiave pubblica.

�� &RPSRQHQWL�GL�XQD�3.,

Vediamo quali sono i componenti fondamentali di un'infrastruttura a

chiave pubblica [L97], dalla cui interazione deriva il corretto funzionamento

della PKI:

• DXWRULWj� GL� UHJLVWUD]LRQH� �5$�: l'accertamento dell'identità

dell'utente richiedente un certificato elettronico, deve precedere l'effettiva

emissione del certificato; è indispensabile procedere a tale verifica dato che con

l'emissione di un certificato elettronico si rende pubblicamente valida

l'associazione tra una certa chiave pubblica e una certa entità. Una volta attestata

la validità dell'identità dell'utente attraverso una serie di procedure definite

nell'ambito di una precisa politica di sicurezza, l'autorità di registrazione ha il

compito di abilitare l'utente come appartenente ad uno specifico dominio di

fiducia; la funzionalità di autorità di registrazione può essere espletata

dall'autorità di certificazione stessa oppure delegata ad altre entità; in uno

scenario ampio è consigliabile ricorrere ad una molteplicità di autorità di

registrazione distribuite su scala geografica;

• DXWRULWj�GL�FHUWLILFD]LRQH��&$�: costituisce la componente chiave

di una PKI; la sua principale funzione consiste nel creare certificati elettronici

per quegli utenti precedentemente abilitati nella fase di registrazione al dominio

di fiducia di cui la CA è garante; un'autorità di certificazione non si deve limitare

esclusivamente alla generazione dei certificati, ma deve poterne gestire l'intero

ciclo di vita. Deve quindi occuparsi anche delle fasi di aggiornamento (nel caso

in cui il certificato stia per perdere validità temporale), sostituzione (nel caso di

scadenza della validità temporale) e revoca (nel caso in cui le condizioni di

emissione del certificato non siano più valide). Un ulteriore compito dell'autorità

di certificazione è stabilire relazioni di fiducia con altre CA.

• VLVWHPD� GLVWULEXLWR� GL� GLUHFWRU\: costituisce un elemento

fondamentale per la distribuzione su larga scala delle chiavi pubbliche utilizzate

nella cifratura e nella firma dei dati. Il sistema di directory contiene i certificati a

chiave pubblica, reperibili dagli utenti quando necessario, e le liste contenenti i

certificati a chiave pubblica sottoposti a revoca; l'obiettivo che si intende

raggiungere disponendo di directory pubbliche è facilitare la gestione e la

distribuzione di certificati elettronici su larga scala;

• 3.,� GDWDEDVH: oltre al sistema di directory, di solito c'è un'altra

struttura dedicata alla memorizzazione delle chiavi è il database gestito

esclusivamente dalla CA nel quale viene fatto un backup delle chiavi e vengono

archiviate le chiavi scadute. Questo database, a differenza della directory, è

privato ad è accessibile solo dalla CA.

• XWHQWL� ILQDOL� ��gli utenti finali sono dotati di software in grado di

interagire con la PKI in tutte le fasi in cui sia richiesta un'interazione tra le

applicazioni client e la CA o la directory (ad esempio un'interazione

fondamentale interviene nella fase di inizializzazione dell'utente, fase nella quale

vengono creati i relativi certificati di cifratura o di firma) .

29

)LJ��: componenti di una PKI

�� 'HILQL]LRQH�GL�FDPPLQR�GL�FHUWLILFD]LRQH

Se si potesse disporre di un'unica autorità di certificazione su scala

globale, il problema della distribuzione, del reperimento e della verifica della

validità delle chiavi pubbliche non sussisterebbe; tuttavia una tale soluzione non

è praticabile per motivi di scalabilità, flessibiltà e sicurezza. Diventa, quindi,

inevitabile ricorrere ad un modello costituito da autorità di certificazione multiple

tra loro concatenate secondo differenti modelli organizzativi, detti anche modelli

di fiducia.

In uno scenario costituito da una molteplicità di autorità di certificazione

su larga scala, strutturate secondo un certo modello organizzativo, non è

pensabile che ogni utente abbia diretta conoscenza delle chiavi pubbliche di ogni

potenziale interlocutore, sotto forma di certificato elettronico, o delle chiavi

pubbliche delle corrispondenti autorità di certificazione competenti. Occorre,

quindi, disporre di un meccanismo corretto di ritrovamento dei certificati

elettronici degli interlocutori appartenenti a domini di sicurezza esterni. Il

modello generale su cui si basano tutti i sistemi di distribuzione su larga scala,

delle chiavi pubbliche sotto forma di certificati elettronici, utilizza le cosiddette

catene di certificazione, altrimenti conosciute come cammini di certificazione.

Il problema del ritrovamento di una catena di certificazione consiste

sostanzialmente nel trovare, se esiste, una serie di certificati che permetta di

verificare l'autenticità del certificato elettronico di uno specifico utente remoto a

partire da un insieme di chiavi pubbliche, assunte come radici del cammino, di

cui si ha diretta e sicura conoscenza. La risoluzione del problema, quindi, assume

per assegnate certe condizioni iniziali che si identificano nelle chiavi di

specifiche autorità di certificazione.

Supponiamo che Alice sia stata certificata dall'autorità di certificazione A

ed abbia conseguentemente diretta fiducia nella chiave di firma di tale autorità di

certificazione; Alice vuole comunicare in modo sicuro con Bob certificato

dall'autorità C; deve pertanto reperire il certificato di Bob e verificarne

l'autenticità, ossia deve verificare la firma apposta dall'autorità C sul certificato di

Bob; Alice dispone solo della chiave pubblica della propria autorità di

certificazione, cioè di A, e non della chiave pubblica di C; si pone, quindi, il

problema di come ritrovare in modo sicuro la chiave pubblica di C in modo da

poterla utilizzare nel processo di verifica della firma del certificato di Bob; il

problema si risolve se è possibile ritrovare una catena di certificati verificabili a

partire dalla chiave pubblica dell'autorità di certificazione A.

)LJ��esempio di catena di certificati

Facendo riferimento alla figura 3.3, la catena è costituita dai certificati 1, 2

e 3; la presenza del certificato 1 garantisce Alice dell'autenticità della chiave

pubblica dell'autorità di certificazione B; Alice può, quindi, utilizzare la chiave

pubblica di B per verificare l'autenticità del certificato 2; la presenza del

31

certificato 2 garantisce ora Alice dell'autenticità della chiave pubblica

dell'autorità di certificazione C; ora Alice può utilizzare la chiave pubblica

dell'autorità di certificazione C per verificare l'autenticità della chiave pubblica di

Bob; se fosse mancato il certificato 2, Alice non avrebbe potuto verificare

l'autenticità del certificato elettronico di Bob e conseguentemente avviare con

Bob una comunicazione sicura.

�� )XQ]LRQDOLWj�GL�XQD�3.,

Ogni implementazione di infrastruttura a chiave pubblica rispecchia

specifici requisiti funzionali; il requisito funzionale che dovrebbe essere, tuttavia,

garantito in qualunque implementazione è quello relativo alla trasparenza; gli

utenti finali devono poter usufruire delle tecniche crittografiche di cifratura e

firma digitale con assoluta semplicità e devono essere mantenuti il più possibile

all'oscuro delle problematiche relative sia alla gestione del cielo di vita delle

chiavi e dei certificati elettronici sia ai processi di cifratura o verifica di una

firma digitale.

Le funzionalità che un'implementazione completa ed efficace di

infrastruttura a chiave pubblica deve fornire si possono classificare nei seguenti

punti:

• funzionalità relative alla gestione delle chiavi e dei certificati; si tratta delle

operazioni di emissione, revoca, distribuzione ed aggiornamento automatico

e trasparente dei certificati, e recupero delle chiavi di decifratura (si tratta del

cosiddetto "key recovery" che si rende necessario nella maggior parte delle

realtà lavorative, costituisce uno strumento di recupero di informazioni

precedentemente cifrate a beneficio del legittimo possessore delle

informazioni; risponde principalmente ad esigenze aziendali e commerciali;

il meccanismo di recupero delle chiavi di decifratura è diverso da quello

impiegato per fare "key escrow"; il "key escrow" risponde, invece, ad

esigenze di controlli da parte di autorità governative; il "key escrow"

costituisce un argomento di acceso dibattito, rappresenta un campo in cui le

esigenze di controllo governativo entrano nettamente in contrasto con i diritti

di libertà individuale e tutela della privacy del singolo cittadino);

• funzionalità atte a garantire il supporto al non ripudio della firma digitale;

• funzionalità atte a garantire il supporto affinché una PKI stabilisca relazioni

di fiducia con PKI esterne (in questo caso si parla di cosiddetta "cross

certification") e le applicazioni client siano in grado di verificare la

correttezza e l'autenticità dei cammini di certificazione che si vengono a

creare in presenza di cross-certification;

• funzionalità atte a garantire un'interazione trasparente tra le applicazioni

client che utilizzano l'infrastruttura per i servizi di sicurezza e l'infrastruttura

stessa; la PKI deve fornire sul lato client il software necessario affinchè tutte

le applicazioni interagiscano con la PKI in modo consistente relativamente ai

servizi di gestione delle chiavi crittografiche e dei certificati elettronici; al

fine di soddisfare il requisito di trasparenza, il software sul lato client deve

garantire:

� il controllo sia della validità della firma digitale dell'autorità di

certificazione sui certificati a chiave pubblica che della loro validità

temporale;

� la generazione delle chiavi di firma da parte del software sul lato client per

sopportare il non ripudio della firma digitale;

� il completamente di un processo di recupero di dati precedentemente

cifrati;

� l'avvio del processo di aggiornamento delle chiavi crittografiche e dei

corrispondenti certificati se risulta ancora confermata la validità delle

condizioni iniziali di registrazione; l'operazione di aggiornamento è

realizzata in conformità alle politiche di sicurezza definite nell'ambito

della PKI e in modo consistente e trasparente per tutte le applicazioni che

utilizzano cifratura e firma digitale;

� la verifica dello stato di ogni certificato elaborato; in modo trasparente, sia

in fase di cifratura che in fase di verifica di una firma digitale, il software

sul lato client deve controllare che il certificato da elaborare non sia stato

revocato; il controllo dello stato del certificato non può essere delegato

all'arbitrio dell'utente finale visto la criticità dell'operazione;

� la verifica dello stato di ogni certificato presente su un cammino di

certificazione in presenza di cross-certification; lo stato di ogni certificato

33

relativo ad un'autorità di certificazione, presente nella catena di fiducia

deve essere controllato accuratamente; la validazione di un certo cammino

di certificazione fallisce in presenza anche di un solo certificato revocato o

di un certificato emesso secondo politiche non compatibili;

Solo una PKI rispondente a tutte le caratteristiche sopra descritte è in

grado di stabilire e mantenere la sicurezza di un ambiente distribuito in modo

consistente, garantendo un sistema di gestione delle chiavi e dei certificati

utilizzabile in modo automatico e trasparente.

�� /D�UHYRFD�GL�XQ�FHUWLILFDWR

Ogni PKI deve garantire contromisure efficaci per gli usi fraudolenti o

illeciti di un certificato. Il certificato elettronico deve poter essere revocato in

presenza delle seguenti condizioni:

• compromissione rilevata o semplicemente sospettata della chiave privata

corrispondente alla chiave pubblica contenuta nel certificato;

• cambiamento di una qualsiasi delle informazioni contenute nel certificato

elettronico o delle condizioni iniziali di registrazione.

La revoca del certificato elettronico è effettuata dall'autorità di

certificazione, generalmente viene avviata su richiesta dello stesso utente finale;

in questo caso, data la criticità e le implicazioni dell'operazione di revoca, è

indispensabile predisporre, un sistema di autenticazione della richiesta di revoca.

La difficoltà legata al processo di revoca sta nel garantire una corretta

notifica su larga scala dell'avvenuta revoca di un particolare certificato;

ogniqualvolta un utente finale intende utilizzare un certificato o per cifrare dati o

per verificare una firma, deve essere informato sullo stato di quel certificato.

Il meccanismo più comunemente utilizzato per la notifica su larga scala di

avvenute revoche fa uso delle cosiddette liste di revoca dei certificati (Certificate

Revocation List o CRL); la gestione di tali liste è delegata alla CA nell'ambito

del dominio amministrato, ogni CA pubblica periodicamente una struttura dati

contenente l'elenco dei certificati revocati, chiamata lista di revoca dei certificati

(CRL); una CRL è appunto una lista, firmata digitalmente dall'autorità di

certificazione, che riporta i certificati revocati, la data temporale in cui è

avvenuta la revoca ed eventualmente il motivo della revoca; i motivi per cui

anche la CRL deve essere firmata digitalmente sono analoghi a quelli descritti

nel caso dei certificati elettronici.

La CRL, al pari dei certificati, deve essere pubblicata in modo che sia

consultabile da qualunque utente. La frequenza di pubblicazione di una CRL

dipende fortemente dalla politica di sicurezza definita all'interno

dell'organizzazione; una determinata politica potrebbe richiedere la

pubblicazione di una nuova CRL ogniqualvolta si richiede una revoca; tale

procedura risulta, tuttavia, molto dispendiosa dal punto di vista amministrativo.

Generalmente, la CA rilascia liste di revoca dei certificati su base periodica, con

intervalli di periodicità definibili a livello di politica di sicurezza.

)LJ��formato delle CRL secondo lo standard X.509

Le liste di revoca giocano un ruolo di fondamentale importanza in tutti i

processi crittografici, in quanto devono essere consultate sia in fase di cifratura

che in fase di verifica di una firma. Prima di cifrare un messaggio, va verificato

che la chiave pubblica che si deve usare appartenga ad un certificato valido.

Analogo discorso vale la verifica di una firma, che può essere ritenuta valida solo

se il certificato del firmatario, oltre ad essere autentico e integro, non è stato

revocato; l'autenticità e l'integrità del certificato si controlla verificando la firma

,VVXHU�1DPH

&5/�,VVXH�7LPH�'DWH


5HYRFDWLRQ�7LPH�'DWH

«

«

«


5HYRFDWLRQ�7LPH�'DWH

&$�VLJQDWXUH

35

della CA che ha emesso il certificato, lo stato di revoca si controlla verificando

che il certificato in questione non compaia nella lista di revoca emessa dalla CA

competente.

La dimensione di una CRL è di fondamentale importanza nelle prestazioni

del processo di verifica dato che sia in fase di cifratura che in fase di verifica di

una firma si deve comunque elaborarne una; se la dimensione di una CRL è

considerevole, è evidente che si introducono overhead sia di traffico di rete che

di elaborazione.

Il problema della crescita illimitata delle CRL è stato risolto con

l'introduzione dei cosiddetti punti di distribuzione delle CRL (definiti nella

versione2 dello standard X.509 relativo alle CRL); è, infatti, possibile dividere in

modo arbitrario il numero di certificati revocati da una CA in partizioni, ognuna

delle quali associata ad un punto di distribuzione; in questo modo la massima

dimensione che può raggiungere una singola partizione è controllata dall'autorità

di certificazione grazie all'utilizzo di metodi di riallocazione dinamica delle

partizioni [AZ98]; i punti di distribuzione facilitano, pertanto, l'elaborazione

delle CRL e ne riducono i tempi di reperimento.

Il metodo di distribuzione della notifica di revoca attraverso CRL

distribuite periodicamente dall'autorità di certificazione è detto di tipo SXOO�� il

nome del metodo deriva, infatti, dal fatto che sono gli stessi utenti finali a

reperire le CRL dal sistema di distribuzione quando necessario.

Il limite legato al metodo di distribuzione delle notifiche delle revoche

tramite CRL, è quello della latenza introdotta. Esistono transazioni in cui è

necessario garantire revoca in tempo reale e che non possono tollerare finestre

temporali in cui le CRL non sono perfettamente allineate; il metodo sopra

descritto presenta proprio la limitazione che la latenza introdotta nelle notifiche

delle revoche dipende dalla periodicità di emissione delle CRL. Se, ad esempio,

viene revocato un certificato nell'intervallo di tempo tra due emissioni periodiche

previste, la revoca viene effettivamente comunicata alla successiva emissione di

CRL prevista; il tempo di latenza può, quindi, essere non tollerabile. È evidente

che l'autorità di certificazione può forzare l'emissione di una CRL fuori

sequenza; se, tuttavia, viene avviato un attacco attivo finalizzato ad impedire la

pubblicazione di tale lista di revoca fuori sequenza, non c'è un meccanismo

affidabile che permetta di rilevare con assoluta certezza la mancata pubblicazione

di tale CRL.

Per ridurre il consumo di risorse di rete richiesto da una pubblicazione di

una nuova CRL sono state introdotte le Delta CRL che rappresentano

un'integrazione alle CRL. Viene definita una CRL base che è pubblicata con

stabilita frequenza, a cui viene associata una Delta CRL che contiene gli

aggiornamenti alla CRL base. Date le dimensioni abbastanza ridotte le Delta

CRL possono essere pubblicate con maggiore frequenza senza comportare un

eccessivo consumo di risorse di rete. Ogni certificato conterrà oltre ad un

identificativo del frammento di CRL che lo riguarda anche un riferimento alla

Delta CRL relativa, oppure questo riferimento sarà incluso nello stesso

frammento di CRL[AZ98].

L'utilizzo delle Delta CRL riduce il periodo di aggiornamento delle CRL,

ma non risolve il problema della revoca in tempo reale che può essere affrontata

solo con metodi alternativi.

Un primo approccio è quello che utilizza un metodo di tipo SXVK� in cui è

l'autorità di certificazione ad inviare in modalità "broadcast" le CRL non appena

sopravviene una nuova revoca. Se, da un lato, questo metodo garantisce tempi di

distribuzione delle CRL estremamente veloci, tuttavia, dall'altro lato presenta

alcuni svantaggi che lo rendono non diffusamente impiegato; innanzitutto

metodo richiede un sistema di distribuzione sicuro che garantisca che le CRL

effettivamente raggiungano i sistemi degli utenti finali previsti, in secondo luogo

può dar luogo ad un incremento considerevole di traffico sulla rete, in terzo

luogo tale metodo non presenta né uno standard, né una proposta di definizione

che ne permetta un'implementazione diffusa.

Il programma MISSI del Dipartimento della Difesa americano (Multi-

level Infonnation System Security Initiative) che fornisce un'infrastruttura per il

sistema di messaggeria della Difesa presenta un esempio del metodo push.

Un altro metodo di notifica delle revoche, alternativo a quelli precedenti,

consiste nell'effettuare una transazione RQ�OLQH di verifica dello stato del

certificato; è basato sul protocollo OCSP, "Online Certificate Status Protocol"

[RFC2560].

37

L'autorità di certificazione deve mettere a disposizione un server on-line

dedicato a questo servizio che garantisca disponibilità ed accessibilità continua

del servizio.

Questo metodo, sicuramente molto dispendioso data la presenza di un

server dedicato, rappresenta la soluzione più affidabile e tempestiva per la

gestione delle revoche e viene sempre più adottata per garantire gli utenti più

importanti o critici. La revoca dei certificati degli altri utenti sarà gestita con la

classica CRL e le sue varianti, in modo da non appesantire troppo il server.

L'utilizzo del protocollo OCSP risolve, così, il problema della revoca in

tempo reale; richiede però l'utilizzo di un canale sicuro di collegamento con il

server o, in alternativa, la possibilità da parte del server stesso di firmare le

risposte alle richieste OCSP.

�� 0RGHOOL�RUJDQL]]DWLYL�GL�3.,

Nella costruzione di infrastrutture a chiave pubblica scalabili su larga

scala, una delle difficoltà principali consiste nell'individuare e successivamente

validare cammini di certificazione sufficientemente brevi; dipendentemente dal

modello organizzativo di infrastruttura (o anche detto modello di fiducia) che si

adotta, il cammino di certificazione è più o meno ottimizzato.

La convenienza in termini di prestazioni ed efficienza dei cammini di

certificazione non è, l'unico fattore che determina l'adozione di un particolare

modello di fiducia; nella scelta, e nella successiva implementazione, incidono

anche il modello di politica di sicurezza definito e il modello di propagazione di

tale politica di sicurezza che si intende imporre attraverso i vari componenti

dell'architettura organizzativa adottata.

�� 6WUXWWXUD�JHUDUFKLFD

Per costruire cammini di certificazione di lunghezza accettabile si fa

riferimento alla teoria dei grafi da cui si vede che le strutture organizzate ad

albero o gerarchiche forniscono una soluzione efficiente al problema.

Nel modello gerarchico stretto la certificazione è realizzata solo dalle

autorità superiori nei confronti di quelle gerarchicamente inferiori, come indicato

nella figura 3.5. Tutti i cammini di certificazione partono dal vertice, tutti gli

utenti devono quindi fidarsi della radice e conoscere la relativa chiave pubblica. I

vantaggi di tale struttura sono principalmente due:

1) Esiste un unico cammino di certificazione per tutti gli utenti e la scoperta di

tale cammino è abbastanza semplificata.

2) Data la sua struttura ad albero è particolarmente adatto per tutte quelle

organizzazioni internamente gestite in modo gerarchico.

)LJ��: struttura strettamente gerarchica

Lo svantaggio è che tutti i cammini di certificazione coinvolgono la radice

e quindi la fiducia è completamente riposta nella sicurezza della radice.

Un esempio di implementazione di infrastruttura a chiave pubblica

conforme al modello gerarchico è la PEM (Privacy Enhancement for Internet

Electronic Mail) [RFC 1421-1424].

Una variante al modello gerarchico stretto prevede che nella struttura ad

albero le autorità di certificazione si fidano l'una dell'altra e si siano rilasciate

reciprocamente dei certificati elettronici. Questo è il modello gerarchico

generale.

Con riferimento alla figura 3.6, l'autorità di certificazione CA1 ha

certificato la chiave pubblica dell'autorità di certificazione CA2 e viceversa;

Alice è stata, invece, certificata da CA4, Bob da CA5.

39

)LJ��: struttura gerarchica generale

In tale struttura, risulta relativamente semplice costruire dei cammini di

certificazione tra coppie di interlocutori appartenenti a domini di fiducia

differenti (per singolo dominio di fiducia s’intende un dominio di utenti gestito da

una specifica autorità di certificazione), indipendentemente da quale autorità di

certificazione si assume quale radice del cammino. Supponiamo ora che Alice

assuma come radice la CA4; dato il tipo di architettura, Alice è in grado di

trovare sistematicamente un cammino di certificazione per qualunque

interlocutore; se Alice vuole verificare l'autenticità della chiave pubblica di Bob,

Alice deve verificare il cammino costituito dai seguenti certificati:

• il certificato contenente la chiave pubblica dell'autorità di certificazione CA2

emesso dalla CA4;

• il certificato contenente la chiave pubblica dell'autorità di certificazione CA5,

emesso dalla CA2;

• il certificato di Bob emesso dalla CA5

Il modello gerarchico generale è caratterizzato da un buon livello di

scalabilità ed efficienza. Il fattore non soddisfacente relativo a tale modello

riguarda la propagazione della fiducia attraverso il cammino dei certificati.

Ogni utente finale, quando verifica una determinata catena di certificati,

deve necessariamente fidarsi di ogni autorità di certificazione presente sul

cammino; si deve, cioè, fidare dell'accuratezza delle politiche di sicurezza di tutte

le autorità di certificazione presenti sul cammino, anche di quelle con cui

probabilmente non ha alcuna relazione diretta. In aggiunta, la maggior parte dei

cammini di certificazione passano comunque attraverso la radice della gerarchia

(la radice nella figura 3.7 è l'autorità di certificazione CA1); virtualmente, quindi,

tutti gli appartenenti all'infrastruttura a chiave pubblica devono necessariamente

fidarsi ancora della radice; se un intrusore riuscisse a compromettere la chiave

privata della radice, la sicurezza dell'intera infrastruttura sarebbe

irrimediabilmente minata. E' di fondamentale importanza, quindi, implementare

sistemi sofisticati di protezione della chiave privata della radice della gerarchia.

Un modello derivante da quello precedente consiste in una struttura

gerarchica generale con connessioni aggiuntive tra i vari nodi; per tali

connessioni, non previste nel modello gerarchico generale, si parla di

certificazione incrociata (FURVV��FHUWLILFDWLRQ).

)LJ��struttura gerarchica con collegamenti addizionali

La presenza di connessioni aggiuntive, quale quella in figura tra la CA2 e

la CA6, accorcia ulteriormente le lunghezze dei cammini di certificazione; le

connessioni aggiuntive possono essere sia unidirezionali sia bidirezionali, quale

quella tra CA5 e CA6. Si sottolinea che lo standard X.509 non impone alcun tipo

di struttura organizzativa; tuttavia, il modello gerarchico generale con

connessioni aggiuntive è implicitamente suggerito.

L'utilizzo del modello gerarchico o di una sua variante è consigliato nei

casi in cui la struttura organizzativa stessa dell'organizzazione è gerarchica.

�� 6WUXWWXUD�GLVWULEXLWD

Il problema principale legato al modello di fiducia gerarchico è che non

sempre tutti i fruitori di un'infrastruttura a chiave pubblica condividono l'assunto

41

di doversi fidare di un'unica autorità di certificazione radice per qualunque

finalità. Tale considerazione si rafforza soprattutto negli ambiti commerciali e

finanziari.; è, infatti difficile trovare una singola autorità di cui tutte le

organizzazioni commerciali si fidano per la gestione delle loro informazioni

critiche.

Se, quindi, in un ambiente governativo, un modello gerarchico può essere

adeguato alle politiche operative e di sicurezza, in ambienti aziendali, finanziari o

commerciali è preferibile adottare modelli di fiducia cosiddetti distribuiti.

Un modello distribuito prevede la presenza di infrastrutture a chiave

pubblica distinte che a discrezione, secondo accordi reciprocamente pattuiti, si

certificano vicendevolmente. Ogni singola infrastruttura gestita autonomamente

da una o più organizzazioni che partecipano all'infrastruttura in questione, può

essere strutturata al suo interno secondo il modello di fiducia ritenuto più

adeguato alle esigenze interne.

)LJ��: struttura distribuita

Il vantaggio è l'assenza di un'unica autorità di certificazione radice di cui

doversi completamente fidare. Lo svantaggio è che la struttura che ne deriva non

ha più una topologia ben definita che individui univocamente un cammino di

certificazione tra due utenti.

I due modelli organizzati di PKI visti sono i casi più estremi, esistono

varie realizzazioni intermedie in cui si cerca di mediare tra l'esigenza di una

struttura efficiente e una struttura sicura ed indipendente. Un esempio è il

modello semplificato di ICE-TEL [YCC96] in cui la cross-certification non può

essere transitiva e quindi la ricerca di un cammino di certificazione si può

interrompere in presenza di due cross-certification.

43

&DSLWROR��6,67(0,�',�',5(&725<

�� ,QWURGX]LRQH

I mezzi di comunicazione al giorno d’oggi sono basati sull’utilizzo di reti,

basti pensare alla rete postale, alla rete telefonica, ad Internet; per poter utilizzare

tali reti l’utente deve essere a conoscenza di alcune informazioni fondamentali

come ad esempio l’indirizzo o il numero di telefono della persona che vuole

contattare.

Ricordare questa informazione per un ristretto numero di amici non è un

grande problema basta gestire un'agendina personale, invece ci sono più

difficoltà quando si cerca di contattare una persona per la prima volta, di cui

probabilmente si conosce il nome, ma non il suo indirizzo postale o elettronico.

Nello stesso tempo anche se abbiamo già contattato qualcuno nel passato è

possibile che tale persona possa aver cambiato indirizzo e che non ci abbia

informato.

La soluzione a questo problema nel mondo telefonico è stata quella di

creare gli elenchi telefonici che vengono aggiornati una volta l'anno.

Comunque anche questa tecnica inizia a mostrare i suoi limiti in quanto

sono sempre più le persone che telefonano al di fuori del loro dominio. Per

questo motivo alcune compagnie telefoniche, come ad esempio la France

Telecom, hanno già prodotto elenchi telefonici elettronici.

Sarebbe utile che nel futuro tutte queste informazioni potessero essere

unite e si potesse creare un elenco globale in cui poter trovare il numero

telefonico, l'indirizzo di e-mail ed anche l'indirizzo postale delle persone.

La parola inglese Directory non è altro che l'equivalente italiano di elenco.

Avere un database centralizzato per questa guida elettronica non è utile

principalmente per due motivi:

• una base di dati che copre tutte le informazioni delle reti del pianeta sarebbe

troppo grande e di conseguenza molto lenta nell'accedere ad una entry

individuale;

• chi dovrebbe mantenere questo database? Mantenimento e caricamento dei

dati sarebbero dispendiosi e poco efficienti.

Per queste ed altre ragioni un'organizzazione distribuita e localmente

amministrata è la soluzione migliore. Ogni elemento locale avrà cura del

caricamento dei dati, del loro mantenimento, delle istanze di sicurezza e della

gestione del servizio delle richieste degli utenti locali.

Inoltre sarà possibile fornire un servizio di informazione anche per tutti gli

utenti le cui richieste non possono essere soddisfatte nel loro dominio.

�� $OFXQL�HVHPSL�GL�'LUHFWRU\�6HUYLFH�H�ORUR�OLPLWD]LRQL�

Analizzeremo di seguito due servizi basati sui sistemi di directory per

comprendere meglio i loro limiti ed introdurre, successivamente, una possibile

soluzione.

Il servizio WHOIS [RFC954] è mantenuto dalla DDN NIC (Defence Data

Network, Network Information Center) e per la porzione Ip di Internet è

attualmente mantenuta dal GSI.

Contiene informazioni relative alle reti IP, ai managers di rete IP e relative

in modo specifico ai sistemi MILNET.

Il database WHOIS è grande abbastanza per mostrare i difetti di un

database centralizzato. In primo luogo la locazione centralizzata del database

WHOIS causa una risposta molto lenta durante i periodi in cui il numero delle

richieste è elevato, portando a limitazioni di memorizzazione dei dati; inoltre

l'intero servizio è inutilizzabile se il link al GSI è bloccato.

In secondo luogo l'amministrazione del database è centralizzata e questo

comporta che ogni cambiamento al database debba essere apportato a mano, in

modo da non rendere immediata la propagazione delle modifiche ed inoltre

45

introduce un’altra possibile causa di errore nell’accuratezza delle informazioni.

Questo in particolare è un problema che affligge la maggior parte dei sistemi che

tentano di realizzare delle Directory Service con un database centralizzato.

Analizziamo ora il servizio DNS [RFC1034-5] (Domain Name Service)

che contiene informazioni sul mapping host tra nome di dominio, ad esempio

"deis.unibo.it", ed il relativo indirizzo numerico IP. Il sistema è stato realizzato

in quanto è molto più facile ricordare nomi di macchine piuttosto che stringhe di

numeri.

Il tutto viene mantenuto in modo distribuito: ogni server DSN fornisce il

nameservice solo per un numero limitato di domini. Inoltre nameservice

secondari possono essere identificati per ogni dominio, cosicché una rete fuori

portata non sarà necessariamente tagliata fuori dal nameservice. D'altra parte

nonostante il DNS sia eccellente nel fornire tali servizi, ci sono dei problemi che

lo caratterizzano.

Il DNS ha una capacità di ricerca molto limitata ed in secondo luogo

supporta solamente un piccolo numero di tipi di dati ed aggiungere nuovi tipi di

dati implicherebbe dei cambiamenti molto rilevanti.

�� /D�VROX]LRQH�DWWUDYHUVR�OD�GHILQL]LRQH�GL�XQRVWDQGDUG�;��

CCITT (Comite Consultatif International Telegrafic et Telephonique) e

ISO (International Standard Organization) hanno congiuntamente sviluppato

degli standard per i servizi di directory. La versione del CCITT è stata

pubblicata nel 1988 attraverso l'insieme di raccomandazioni che va da X.500 a

X.521; la versione equivalente ISO è stata approvata nel 1990 con il nome di ISO

9594 ed è composta di otto parti [DIR]. Questi standard sono stati ampliati nel

1993 per supportare la replicazione delle informazioni.

&&,77 ,62 7,7/(

X.500 9594-1 Overview of Concepts, Models and Services

X.501 9594-2 Models

X.509 9594-8 Authentication Framework

X.511 9594-3 Abstract Service Definition

X.518 9594-4 Procedures for Distributed Operation

X.519 9594-5 Protocol Specifications

X.520 9594-6 Selected Attribute Types

X.521 9594-7 Selected Object Classes

X.525 9594-9 Replication

Tabella 4.1

La definizione dell'X500 data dal CCITT è:

�XQD�FROOH]LRQH�GL�VLVWHPL�DSHUWL�FKH�FR�RSHUDQR�SHU�PDQWHQHUH�XQ

GDWDEDVH�ORJLFR�GL�LQIRUPD]LRQL�VX�XQD�VHULH�GL�RJJHWWL�GHO�PRQGR�UHDOH�

*OL�XWHQWL�GHOOD�'LUHFWRU\�SRVVRQR�OHJJHUH�R�PRGLILFDUH�OLQIRUPD]LRQH��R

SDUWH�GL�HVVD��VROR�VH�KDQQR�L�SULYLOHJL�QHFHVVDUL�

Il CCITT chiama la Directory in singolare per riflettere l'intenzione di

creare una Directory globale singola.

X.500 è un protocollo definito a livello application dello standard OSI

(Open System Interconnection), che specifica un modello per connettere

Directory Service locali per formare una Directory Service globale e distribuita. I

databases locali contengono e mantengono parte del database globale e la

directory di informazione è resa disponibile da un server locale. All'utente

sembra che l'intera directory sia accessibile dal server locale.

Mentre la maggior parte delle informazioni disponibili al giorno d'oggi

tramite X.500 sono sulle persone e sulle organizzazioni, il disegno della directory

X.500 permetterebbe anche di caricare dati su altre entità (o oggetti) come risorse

di rete, applicazioni o hardware.

47

Un servizio di Directory basato su X.500 offre i seguenti vantaggi:

• 'HFHQWUDOL]]D]LRQH� ogni sito in cui gira X.500 è responsabile solamente per

la sua parte locale della Directory, così il mantenimento e l'aggiornamento dei

dati può essere fatto istantaneamente.

• $ELOLWj� GL� ULFHUFD�� X.500 permette delle facilitazioni nella ricerca che

permettono all'utente di formulare richieste anche molto complesse.

• 1DPHVSDFH� RPRJHQHR�� X.500 permette un singolo namespace omogeneo

all'utente. Inoltre rispetto al DNS il namespace dell'X.500 è più flessibile ed

esteso.

• 'LUHFWRU\� 6HUYLFH� VWDQGDUGL]]DWD�� Fosì come X.500 può essere usato per

costruire una directory standardizzata, le applicazioni che richiedono

informazioni di directory (e-mail, allocatori di risorse automatizzati...)

possono accedere a tutto l'universo delle informazioni in modo uniforme, non

c'è problema dove esse girino in quel momento.

Grazie a tali caratteristiche X.500 è stato usato per fornire la struttura di

un servizio di White Pages globale. D'altra parte tale protocollo è basato su degli

standards e ci sono, quindi, pochissime incompatibilità tra le varie versioni di

servizi di directory basati su X.500. Inoltre il namespace è consistente e,

pertanto le informazioni nella directory possono essere facilmente individuate e

recuperate.

Ci sono comunque alcune limitazioni che si devono prendere in

considerazione. Sono legate alla tecnologia dell'X.500 così come è attualmente

realizzata. Un prezzo che si deve pagare per la flessibilità in ricerca è il declino

delle prestazioni. Questo poiché la ricerca in un namespace distribuito può dover

attraversare l'intera rete.

Un secondo problema con le implementazioni è che per ragioni di

sicurezza solo una piccola parte di tutte le informazioni sono fornite all'utente.

Inoltre se una ricerca comprende parecchie entries solo un piccolo numero viene

ritornato all'utente.

�� ,O�0RGHOOR�,QIRUPDWLYR

L’X.500 chiama il completo database della Directory: Directory

Information Base� (DIB) e lo considera come un database singolo, logico e

globale; che può essere distribuito attraverso la rete.

La DIB immagazzina le informazioni sotto forma di oggetti, le cui

caratteristiche sono definite dai suoi attributi. Tutti gli oggetti sono identificati

da un entry.

Allo scopo di localizzare la corretta "entry" all'interno del DIB,

l'informazione contenuta deve essere definita senza ambiguità. Un modo

possibile per ottenere questo è utilizzare una struttura gerarchica ad albero.

L'X.500 definisce un albero logico per il DIB, chiamato Directory

Information Tree (DIT). Lo standard non definisce l'ordinamento degli oggetti

all'interno del DIT. Comunque, ci si aspetterà che i DIT seguiranno una struttura

dove le entries di livello più alto nell'albero rappresenteranno gli oggetti come

nazioni o organizzazioni, mentre quelle di livello più basso saranno le persone.

)LJ��: Directory Information Tree, struttura gerarchica dei nomi

Root node

Country =AU Country=US Country=UK

Organization =ABC Ltd

Locality =New York

Organization =ABC Ltd

Org. Unit =Sales

Common Name= F. Jones

Org. Unit =Production

Common Name= A. Chew

Common Name= Fax Machine

Common Name= J. Smart

49

Le informazioni riguardanti un oggetto della Directory si recuperano

attraverso il Distinguished Name (DN) dell'entry. Il DN è la chiave dell'entry, in

quanto identifica univocamente e senza ambiguità l'oggetto in questione

all'interno del DIT.

Ad ogni entry è associato anche un Relative Distinguished Name (RDN),

il quale definisce univocamente un oggetto all'interno di un certo contesto.

Il modo più semplice per spiegare la differenza tra DN e RDN è di

utilizzare un'analogia con il telefono che analogamente usa una struttura ad

albero per il suo indirizzamento. Ad esempio, numeri telefonici uguali in aree

diverse sono contraddistinti dai rispettivi prefissi del distretto e del paese.

Per esempio, la Trattoria al Ponte di Bologna ha il numero 242223 che

viene distinto all'interno del distretto di Bologna, il numero 051-242223 è

distinguibile all'interno dell'Italia, infine il numero +39-051-242223 identifica la

trattoria nel mondo intero.

)LJ��: Esempi di DN e RDN

Il DN è formato dall'unione della sequenza di RDN, ripercorrendo il DIT

dalla posizione dell'oggetto fino alla radice.

�� ,O�0RGHOOR�)XQ]LRQDOH

La struttura complessiva della Directory X.500 è schematizzata nella

figura 4.3 che segue.

)LJ��: Struttura di un sistema di Directory

L’idea di base consiste nel fatto che le informazioni locali di una

organizzazione, come ad esempio una università, siano mantenute localmente in

una o più DSA (Directory System Agents). È importante sottolineare che

"localmente" assume un significato flessibile in questo contesto in quanto è

possibile che un DSA mantenga informazioni di più organizzazioni, od anche

l'opposto che la Directory dei dati di una grande organizzazione può risiedere in

DSA multipli.

Un DSA è essenzialmente un database con due caratteristiche

fondamentali:

• le informazioni sono caricate in accordo con il modello dell'X.500

• è possibile, se necessario, scambiare dei dati con altri DSA attraverso l'uso

del protocollo DSP (Directory System Protocol) dell'X.500.

Gli utenti vedono la Directory come unica e non ci interagiscono

direttamente, ma tramite un DUA (Directory User Agent). I DUA richiedono

servizi ai DSA nell'interesse degli utenti della Directory.

51

I DSA sono i soli che accedono e mantengono il database della Directory.

Ogni DSA mantiene una parte separata della Directory. Naturalmente la

Directory potrà essere composta anche da un solo DSA, in tal caso la Directory è

centralizzata.

Nella maggior parte dei casi, la Directory sarà distribuita e composta da

numerosi DSA.

Tutte le DSA nella Directory X.500 sono interconnesse in accordo con il

modello predefinito DIT (Directory Information Tree); i dati caricati nelle DSA

hanno una struttura ad albero che contiene parte del DIT globale.

Ogni DSA per poter rispondere correttamente alle richieste del DUA e

comunicare con gli altri DSA deve possedere due tipi di informazioni: la

directory information che è l’insieme di entry che lui ha memorizzato e la

knowledge information che è l’insieme di conoscenze necessarie per individuare

la sua posizione all’interno del DIT ed è espressa in termini di riferimenti interni

o esterni.

Queste informazioni sono descritte nel DSA Information Model [CHA96

par. 2.13] e sono contenute nelle speciali entry DSA (DSE). Il nome e l’indirizzo

di un remoto DSA è chiamato Access Point ed è contenuto nel Knowledge

references [CHA96 par. 4.2].

Sono stati definiti otto tipi di Knowledge reference: superior reference,

subordinate reference, non-specific subordinate reference, cross reference,

immediate superior reference, supplier reference, consumer reference e master

reference [CHA96 par. 9.2]. Grazie a queste informazioni è possibile navigare

all'interno della Directory.

Un esempio di Knowledge Information è indicato in figura 4.4.

)LJ��: Knowledge information

�� ,O�3URWRFROOR�GL�FRPXQLFD]LRQH�'$3

La Directory User Agent rappresenta il primo livello di astrazione e permette

all’utente di accedere ai servizi di Directory. Questi servizi sono stati

standardizzati, e comprendono una serie di operazioni che possono essere

compiute sulla Directory dall’utente. Esiste un protocollo che regola tali

DIRECTORY INFORMATION TREE

D S A 2 DSA3

DSA4 DSA1

Root node

Country=USCountry=AU

Organization= ABC Ltd

Org. Unit =Production

Org. Unit =Sales

Common Name= John Smith

Common Name= Wendy Smart

Locality =Victoria

Locality =New York

Org. Unit =Marketing

Common Name= Frank Jones

KNOWLEDGE INFORMATION FOR DSA3

Context prefix: C=AU, O=ABC LtdSuperior reference: DSA2, PSAP address

Internal reference: O=ABC Ltd, PTR

Internal referenceOU=ProductionPTR

Internal referenceOU=SalesPTR

Non-specfic subordinatereference: DSA4, PSAPaddress

Internal referenceCN=John SmithPTR

Internal referenceCN=Wendy SmartPTR

53

operazioni ricavato da due servizi OSI: il Remote Operation Service (ROSE) e il

Association Central Service (ACSE).

Il protocollo risultante è conosciuto come Directory Access Protocol (DAP) ed è

usato dal DUA per trasmettere la richiesta al DSA.

Le operazioni che possono essere richieste sono di bind, di interrogazione, di

abbandono e di modifica.

L'operazione di Bind è la prima da effettuare, in quanto, permette di stabilire una

connessione con un DSA.

Le operazioni di interrogazione possono essere, così, classificate:

• di lettura: forniscono all'utente il valore di un particolare attributo tenuto in

una specifica entry della Directory. Gli argomenti in input sono i nomi e le

indicazioni delle informazioni che si vogliono consultare. Il risultato di questa

operazione è dato dal nome dell'entry, e dai tipi e valori degli attributi

richiesti;

• di comparazione: sono usate per confrontare un valore di un attributo con

quello già esistente nell'entry. Gli argomenti in input consistono di un valore

di un attributo ed il corrispondente nome. L'output è dato dal valore di

Vero/Falso indicante la presenza dell'attributo;

• di List: elencano tutte le entries nel livello sottostante nell'albero gerarchico;

• di ricerca: sono usate per ricercare particolari porzioni del DIT e ritornano le

informazioni riguardanti le entries selezionate. L'argomento di input identifica

l'entry base dalla quale far partire la ricerca e la parte del DIT dove

effettuarla.

L'operazione di abbandono permette all'utente di chiudere la sessione.

Le operazioni di modifica offrono la possibilità di modificare un nome,

aggiungere, rimuovere e modificare un'entry.

�� 0HWRGL�SHU�OD�ULFHUFD�GHOOH�LQIRUPD]LRQL�

Analizziamo ora come una richiesta viene inoltrata all’interno della Directory. Le

tecniche utilizzate sono due, la prima conosciuta con il nome di FKDLQLQJ prevede

che quando una richiesta arriva ad un DSA quest’ultimo esegue le operazioni di

cui è responsabile e, se necessario, richiede ad un altro DSA di completare la

richiesta. Per non ripetere più volte la stessa operazione, il DSA aggiunge delle

informazioni utili per notificare quali parti della richiesta sono state processate.

Queste informazioni sono generate dal primo DSA e gradualmente modificate

dagli altri DSA ed infine ritornate all'utente.

Si forma quindi una FDWHQD tra DSA che viene ripercorsa due volte prima che la

risposta sia inoltrata all'utente.

)LJ��: Chaining

L'altra tecnica utilizzata è chiamata UHIHUUDO e prevede che il DUA inoltra la

richiesta al suo DSA di riferimento che, allorché non possieda l'informazione

invia la domanda ad un altro DSA. Qualora i dati richiesti non siano presenti

nell'ultimo DSA, questi ritorna la risposta al primo DSA con l'indicazione di un

DSA referente a cui chiedere l'informazione. A questo punto il primo DSA invia

la richiesta al DSA referenziato e ottiene la risposta.

55

)LJ��: Referral

�� 8Q�SURWRFROOR��OHJJHUR��GL�DFFHVVR�DOOH�GLUHFWRU\�SHU,QWHUQHW�/'$3

La comunità di Internet ha definito una versione semplificata del protocollo

DAP, chiamato Lightweight Directory Access Protocol (LDAP) che si posiziona

come uno standard universale per l'accesso alle directory attraverso la rete

Internet [RFC1777]. Un aspetto chiave del LDAP è proprio quello di porsi

direttamente sopra il TCP/IP.

LDAP utilizza la stessa struttura di base del DAP, ma fa circolare i dati sulla rete

sotto forma di catene di caratteri.

Il modello di comunicazione utilizzato da LDAP è il classico client-server. Il

client trasmette la sua richiesta al server tramite LDAP. Il server che è l'unico che

può accedere alla directory elabora la richiesta ed invia la risposta al client

sempre tramite LDAP.

L'idea di LDAP è stata quella di semplificare il lato client in modo da rendere

accessibili a tutti i servizi di directory.

Le operazioni che possono essere richieste attraverso il protocollo LDAP sono

quelle classiche di collegamento, ricerca, modifica e abbandono definite dal

DAP.

I servizi di directory è considerato il miglior sistema per pubblicare certificati e

CRL, quindi LDAP è il protocollo ideale per recuperarli.

Una descrizione su come usare LDAP per recuperare certificati e CRL è riportata

in [RFC2559]; sono state proposte anche delle estensioni al protocollo per

supportare meglio le PKI basate sui certificati X.509 [LDAPv3].

57

&DSLWROR��6,67(0,�',675,%8,7,�(�02%,/,7$

'(/�&2',&(

�� ,QWURGX]LRQH

I sistemi distribuiti sono da tempo oggetto di studio, e un’attenzione

particolare è stata dedicata loro negli ultimi anni, soprattutto per il crescente

sviluppo di quella che può essere considerata la rete geografica per eccellenza:

Internet. Questa tendenza è certamente connessa all'importanza assunta da

numerosi servizi di rete, che inducono ad un sempre crescente interesse del

mercato verso la "interconnessione globale".

I modelli progettuali che erano stati concepiti per sistemi distribuiti

convenzionali, formati da piccole reti locali, risultano non ottimizzati e quindi

inefficienti per una distribuzione su larga scala, evidenziando problemi legati alla

flessibilità, alla scalabilità e alla tolleranza ai guasti.

Questi problemi hanno portato alla ricerca di nuove soluzioni e nuovi

modelli, in cui non è necessariamente presente un livello di trasparenza delle

risorse, che risulta spesso di inefficiente realizzazione. In questo contesto nasce

l'idea della mobilità del codice, che consente di cambiare dinamicamente il

collegamento tra un frammento di codice e la locazione della sua esecuzione.

�� ,�VLVWHPL�GLVWULEXLWL

I primi sistemi informatici erano caratterizzati da strutture imponenti e

molto costose, che solo importanti centri di ricerca potevano permettersi: le

grosse risorse di calcolo erano rappresentate dai mainframe. Queste macchine

imponenti non erano certo progettate per essere facilmente collegate tra loro,

quindi lavoravano tipicamente in modo indipendente l'una dall'altra.

I progressi elettronici e le innovazioni tecnologiche hanno portato notevoli

miglioramenti di prestazioni e di dimensioni nell'ambito informatico, offrendo

sul mercato macchine accessibili, economicamente, anche a livello di piccole

aziende. Questa novità ha rivoluzionato l'atteggiamento nei confronti dei sistemi

informatici: nella tecnologia a mainframe, si doveva comprare la macchina più

grande che ci si potesse permettere, perché con una spesa maggiore si ottenevano

prestazioni notevolmente migliori [T94]. Con la nuova tecnologia dei

microprocessori, la soluzione più efficace rispetto al costo è quella di

raggruppare un numero maggiore di CPU (Central Process Unit) in un singolo

sistema: con lo stesso investimento si può ottenere un rapporto prezzo prestazioni

più favorevole rispetto ai grandi sistemi centralizzati, che può portare ad una

potenza di calcolo teoricamente infinita, raggruppando un numero sempre

crescente di microprocessori.

La diffusione di massa degli elaboratori ha spinto velocemente all'acquisto

di più computer da affiancare sia per trarre benefici dall'incremento di prestazioni

che ne consegue, sia per la natura intrinsecamente distribuita di alcune

applicazioni. Da qui la creazione di reti locali, LAN (Local Area Network), per

collegare i calcolatori e quindi in generale tutte le risorse utilizzabili, hardware e

software. Queste reti offrono la possibilità di accedere da ogni macchina a tutte le

risorse disponibili, come le stampanti, le unità di memorizzazione o altre

periferiche, indispensabili durante lo svolgimento delle attività lavorative, ma

componenti costosi che utilizzati da più macchine, aumentando l'efficienza totale

del sistema.

I collegamenti di rete, consentono una distribuzione efficiente del carico

su tutte le macchine disponibili, costruendo un sistema flessibile, affidabile e

aperto: le scelte di gestione si adattano alle risorse disponibili, gli eventuali guasti

non causano la totale caduta del sistema, e le aumentate esigenze sono soddisfatte

con l'inserimento di nuovi elementi, che permettono una crescita incrementale

della rete.

Il numero sempre crescente di macchine collegabili e la distanza sempre

più elevata che li separa, ha introdotto la terminologia di VLVWHPL�GLVWULEXLWL��per

evidenziarne la contrapposizione alla tecnologia classica dei sistemi centralizzati.

I sistemi distribuiti sono una “FROOH]LRQH� GL� FDOFRODWRUL� DXWRQRPL�� FROOHJDWL

WUDPLWH�XQD�UHWH�GL�LQWHUFRQHVVLRQH�H�GRWDWL�GL�VRIWZDUH�FKH�KD�OR�VFRSR�GL�FUHDUH

VHUYL]L�LQWHJUDWL” [CDK94].

59

Con il termine servizi integrati si intendono servizi che possono essere

implementati tramite la coordinazione di vari nodi del sistema ma che sono

percepiti dall’utente come un unico servizio.

Per poter parlare di sistema distribuito, non è sufficiente avere dei

calcolatori collegati in retedamentale, è necessario che questi sistemi abbiano un

obiettivo comune da raggiungere, come ad esempio la condivisione di un insieme

di risorse ubicate in vari punti della rete.

Per ricavare un vantaggio reale e completo dall'utilizzo di sistemi

distribuiti, si devono rispettare ed ottenere alcune caratteristiche:

• &RQGLYLVLRQH�GHOOH�ULVRUVH�� i vari componenti di un sistema distribuito sono

dotati di risorse di vario tipo (CPU, file, basi di dati , stampanti, ecc.). La

condivisione di queste risorse da parte dei nodi del sistema consente di ridurre

i costi complessivi, evitando un’inutile replicazione.

• $SHUWXUD�� indica l’estendibilità del sistema, cioè la sua capacità di accettare

nuove risorse sia di tipo fisico (nuovo hardware, nuovi nodi, ecc.) che logico

(nuovi protocolli di comunicazione, nuovi servizi, ecc.), in maniera dinamica.

Ciò è possibile adottando interfacce standard di comunicazione tra i

componenti del sistema.

• &RQFRUUHQ]D� la presenza di diverse unità computazionali e di una

molteplicità di applicazioni e servizi crea la possibilità di esecuzione

concorrente (in cui più processi si contendono l’uso della stessa CPU) e

parallela (in cui più processi eseguono contemporaneamente su CPU diverse).

• 6FDODELOLWj� indica la capacità del sistema di funzionare mantenendo le

proprie caratteristiche peculiari (in particolare l’efficienza delle applicazioni e

dei servizi) indipendentemente dalla dimensione del sistema (intesa

principalmente come numero di nodi interconnessi).

• 7ROOHUDQ]D�DL�JXDVWL� permette al sistema di funzionare correttamente anche

in presenza di guasti ad uno o più componenti. Viene ottenuta tramite

ridondanza e procedure di ripristino (recovery).

• 7UDVSDUHQ]D� indica la possibilità per l’utente di vedere il sistema come

un’unica entità anziché come un insieme di calcolatori interconnessi. Si

applica in vari contesti. I principali tipi di trasparenza a cui si è interessati

sono:

� 7UDVSDUHQ]D� QHOO¶DFFHVVR�� permette di accedere nel medesimo modo a

risorse locali e remote.

� 7UDVSDUHQ]D� QHOO¶DOORFD]LRQH� permette di accedere alle risorse senza

sapere dove queste sono allocate.

� 7UDVSDUHQ]D� QHOOD� FRQFRUUHQ]D�� permette a più processi di eseguire

concorrentemente ed utilizzando le stesse risorse senza che vi sia

interferenza reciproca.

� 7UDVSDUHQ]D� QHOOD� UHSOLFD]LRQH�� permette di avere più copie di una

medesima risorsa (con obiettivi di tolleranza ai guasti e/o migliori

prestazioni) senza che ciò sia visibile agli utilizzatori della risorsa.

� 7UDVSDUHQ]D� QHL� JXDVWL� permette alle applicazioni di funzionare

correttamente anche in presenza di malfunzionamenti o guasti.

� 7UDVSDUHQ]D�QHOOD�PLJUD]LRQH� permette il movimento di risorse senza che

l’utente ne abbia conoscenza.

� 7UDVSDUHQ]D� QHOOH� SUHVWD]LRQL� permette di variare la configurazione del

sistema per far fronte a variazioni di carico computazionale o di altro tipo.

� 7UDVSDUHQ]D� QHOOH� GLPHQVLRQL� permette al sistema e alle applicazioni di

variare in dimensioni senza che la struttura del sistema e gli algoritmi

delle applicazioni ne risentano.

• 6LFXUH]]D�� la possibilità di poter accedere alle informazioni disponibili su

tutto il sistema consente ad ogni utente di reperire qualsiasi tipo di dato,

anche quello che non si vorrebbe diffondere. Le informazioni private, inserite

in un sistema distribuito, devono, quindi, essere protette da accessi

indesiderati, per evitare di farle consultare o modificare.

61

�� 0RGHOOR�&OLHQW�6HUYHU

La comunicazione nei sistemi distribuiti è un aspetto molto importante.

Essa permette infatti di coordinare i componenti del sistema per raggiungere

l’obiettivo comune.

Il tradizionale modello di comunicazione su cui si basano i sistemi

distribuiti è il Client-Server, nella sua definizione si è cercato di garantire tutte le

caratteristiche delineate nel paragrafo precedente. In questo modello esistono due

tipi di entità il cui ruolo è ben distinto: il servitore che è in grado di erogare

servizi (in generale accesso e manipolazione delle risorse del sistema), ed il

cliente che interagisce con il servitore per ottenere i servizi di cui ha bisogno.

I servitori hanno accesso diretto alle risorse e offrono un’interfaccia

tramite la quale interagire con esse. I clienti utilizzano le risorse invocando i

servizi della suddetta interfaccia. In questo modo è possibile ottenere un accesso

controllato e trasparente alle risorse.

La comunicazione tra clienti e servitori avviene tramite precisi protocolli

che stabiliscono come invocare i servizi e come si riceveranno le relative

risposte. In ogni caso clienti e servitori scambiano tra loro esclusivamente dati.

L'impiego di questo modello comporta i seguenti vantaggi:

• Le interazioni dirette con le risorse avvengono generalmente in ipotesi di

località (il servitore è locale alle risorse che gestisce) e in modo controllato

(attraverso una rigida interfaccia).

• Non è necessario conoscere l’allocazione delle risorse ma solo un nome

(globale) che le identifica: si raggiunge l’obiettivo di trasparenza alla

allocazione adottando un servizio di risoluzione dei nomi.

• E’ possibile implementare meccanismi di fault tolerance attraverso l’uso di

server multipli, gestiti anche in modo trasparente.

• L’eterogeneità è superata adottando protocolli standard di comunicazione (si

trasmettono solo dati e dunque è sufficiente accordarsi per uno standard sulla

loro rappresentazione).

D’altra parte al modello sono state poste diverse critiche, legate al

sovrautilizzo delle risorse di interconnessione (accettabile in un ambiente locale,

dove le reti sono tipicamente a larga banda e bassa latenza, ma non più in

ambiente geografico) e alla scarsa flessibilità e dinamicità dei servizi offerti.

L’elevato traffico di rete si riscontra in quei servitori che forniscono solo

servizi di basso livello, costringendo i clienti a trasferire grosse moli di dati da

elaborare poi localmente.

Si pensi al caso in cui si voglia ottenere la media di una serie di valori

presenti in una tabella gestita da un apposito servitore: se il servitore è in grado

solo di leggere e scrivere una determinata riga della tabella l’unico modo per

ottenere l’elaborazione voluta è trasferire tutta la tabella sul cliente ed eseguire lì

i dovuti calcoli.

Una possibile soluzione è di implementare sul servitore tutte le

funzionalità (anche di alto livello) di cui i possibili clienti potranno avere

bisogno, rendendo però così inutilmente complesso il servitore. In genere è

necessario individuare il giusto trade off tra traffico generato e complessità.

I tentativi di superare questi limiti si sono mossi nella direzione della

programmabilità dei server, introducendo la possibilità di inviare assieme alle

richieste di servizio, anche il codice che esegue il servizio stesso.

�� 0RELOLWj�GHO�FRGLFH

Per superare i limiti di flessibilità del modello cliente/servitore sono nati

una serie di approcci basati sulla mobilità del codice. La mobilità del codice è la

capacità di cambiare dinamicamente il collegamento tra frammenti di codice e la

locazione in cui sono eseguiti [CPV97]. Dalla definizione emerge che l'ambiente

di azione naturale della mobilità del codice sono i sistemi distribuiti.

Le tecniche che si basano sulla mobilità del codice tentano di risolvere i

principali problemi che caratterizzano il tradizionale approccio ai sistemi

distribuiti: l'obiettivo ultimo è di offrire direttamente al programmatore forme di

controllo sullo spostamento di ogni entità tra i vari nodi, inserendo un supporto

run-time che implementi tutti i meccanismi necessari per la ricerca e la mobilità

dei componenti, e che sia capace di adattarsi alla particolare politica di gestione

scelta dall'amministratore di sistema.

63

Questa nuova visione del sistema appesantisce il ruolo del programmatore,

che in prima persona deve saper sfruttare le caratteristiche ed i vantaggi della

mobilità del codice. Infatti la mobilità permette di modificare GLQDPLFDPHQWH� il

collegamento tra un frammento di codice e la locazione in cui eseguirlo,

scegliendo la locazione in funzione delle esigenze attuali. Per trarre benefici, si

può decidere di spostare l'esecuzione sul nodo meno carico, su quello in cui

risiede la risorsa con cui interagire, su quello attualmente più stabile o su quello

che offre i collegamenti più affidabili.

�� &RQWUROOR�VXOOD�ORFD]LRQH�GHOOH�ULVRUVH

L'obiettivo tradizionale dei sistemi operativi distribuiti era quello di non

fornire all'utente alcuna informazione sulla locazione delle risorse, anzi di non

fare neppure trasparire l'esistenza stessa di nodi remoti. Le funzionalità di alto

livello messe a disposizione da un sistema operativo realmente distribuito,

consentono l'astrazione della posizione fisica degli oggetti nella rete, per cui tutte

le risorse sono utilizzate come se fossero locali (Figura 5.2). Questo consente al

programmatore di sviluppare applicazioni con facilità referenziando le risorse

locali e remote con gli stessi meccanismi, indipendentemente dal nodo in cui

risiedono.

)LJ��: Nei sistemi distribuiti tradizionali la locazione deicomponenti è trasparente per l'utente.

Nei sistemi distribuiti che supportano la mobilità, al contrario di quanto

appena visto, è consentita la rilocazione dinamica dei i componenti, intesi sia

come unità di esecuzione (ad esempio un 'frammento di codice) sia come risorse

utilizzate o condivise dalle unità appena citate (ad esempio un file).

Il codice mobile stravolge il tradizionale approccio verso i sistemi

distribuiti: l'utente deve conoscere in modo esplicito la posizione fisica in cui le

varie entità sono allocate nella rete, per poterle referenziare direttamente (Figura

5.3). Al programmatore è affidato il compito di sfruttare la conoscenza della

locazione dei componenti per mettere in pratica i vantaggi della mobilità del

codice. Per esempio l'utente deve sapere dove risiedono le risorse da utilizzare

per trasferire, nella stessa macchina, il frammento di codice interessato

all'interazione con la risorsa, per il beneficio di realizzare una esecuzione locale.

)LJ��:�I sistemi basati sulla mobilità permettono la rilocazionedinamica dei componenti, per cui si deve avere conoscenza

esplicita della posizione di ognuno di essi.

�� /LQJXDJJL�D�FRGLFH�PRELOH

Sono stati proposti numerosi linguaggi di programmazione finalizzati ad

un uso su Intemet, con la caratteristica comune di fornire aspetti legati alla

mobilità del codice, che a differenza i dell'approccio tradizionale client-server,

integrano una mobilità su reti a larga scala.

Prima di confrontare i linguaggi tradizionali e quelli a codice mobile,

definiamo alcuni concetti chiave indispensabili per proseguire [FPV98]:

• DPELHQWH� GL� HVHFX]LRQH (&(: &RPSXWDWLRQDO� (QYLURQPHQW): rappresenta

l'identità della locazione in cui si svolge l'esecuzione.

• XQLWj�GL�HVHFX]LRQH�((8: ([HFXWLRQ�8QLW): rappresenta un flusso sequenziale

di esecuzione, che comprende oltre al codice, lo i stato di esecuzione e lo

65

spazio dei dati; esempi di EU sono un singolo Thread in un sistema multi-

Thread o un qualunque processo sequenziale.

• ULVRUVD: rappresenta un entità che può essere condivisa tra più unità di

esecuzione, per esempio una variabile, un file o un oggetto in un sistema

object-oriented.

Nei linguaggi tradizionali, come il C o il Pascal, ogni unità di esecuzione

si svolge totalmente in un unico ambiente, ed il collegamento al suo codice è

generalmente di tipo statico. Nei linguaggi basati sulla mobilità del codice

[CGPV97], invece, le parti fondamentali di una unita di esecuzione, cioè il

segmento di codice, lo stato di esecuzione e lo spazio dei dati, possono spostarsi

dall'ambiente di esecuzione in cui risiedono ad un altro, in modo autonomo.

Distinguiamo i linguaggi di programmazione in funzione del tipo di

mobilità che supportano [CPV97], per evidenziare il livello di spostamento

consentito.

♦ 0RELOLWj�IRUWH (6WURQJ�0RELOLW\):�un linguaggio supposta la mobilità forte se

consente alle sue unità di esecuzione di ,spostarsi dall'ambiente in cui

eseguono ad un altro, trasportando ile loro parti caratteristiche: codice, stack e

spazio dei dati. Prima della trasmissione, il flusso di esecuzione viene

bloccato per essere poi ripristinato nell'ambiente di destinazione. Questo

permette al flusso di esecuzione di bloccarsi non appena si esegue l'istruzione

di trasferimento e di riprendere l'esecuzione nell'ambiente di destinazione

esattamente dall'istruzione successiva: questa proprietà consente al linguaggio

di essere più efficiente rispetto al caso successivo.

♦ 0RELOLWj�GHEROH (:HDN�0RELOLW\): un linguaggio supposta la mobilità debole

se consente lo spostamento di codice (ed eventualmente del suo spazio dei

dati), o di oggetti nel caso di un linguaggio object-oriented. Le unità di

esecuzione, al contrario del caso precedente, non hanno la capacità di

spostarsi: all'interno dell'ambiente di esecuzione destinatario si effettua un

collegamento dinamico tra un'unità di esecuzione dell'ambiente stesso e il

codice proveniente da un altro ambiente o scaricato dalla rete. L'unità di

esecuzione che si associa al codice in arrivo può essere creata appositamente,

su necessità ("by need"), oppure se ne può sfruttare una preesistente.

Affinchè un linguaggio sia adatto per lo sviluppo di agenti deve essere

dotato di alcune proprietà:

• 3RUWDELOLWj��i sistemi ad agenti mobili sono tendenzialmente sistemi aperti, è

essenziale dunque che gli agenti siano in grado di eseguire su qualunque

piattaforma. Per questo motivo vengono preferiti i linguaggi interpretati,

dotati di macchine virtuali portabili.

• 6LFXUH]]D�� dal punto di visto della protezione dell’ambiente rispetto alle

azioni degli agenti. Sono preferibili linguaggi dotati di controllo stretto sui

tipi, incapsulamento, accesso controllato alla memoria.

• 5DSLGD� SURWRWLSD]LRQH� la possibilità di scrivere agenti velocemente è una

caratteristica importante. Per questo molti dei sistemi reali si basano su

linguaggi di scripting oppure su linguaggi object oriented. I primi però

soffrono di una scarsa modularità. Nel modello object oriented gli agenti sono

oggetti di prima classe, ed incapsulano sia lo stato che il codice.

�� 3DUDGLJPL�GL�SURJHWWD]LRQH�EDVDWL�VXOOD�PRELOLWj�GHOFRGLFH

Un paradigma di progettazione è la specifica configurazione dei

componenti e delle loro interazioni all'interno di un sistema, cioè la

configurazione che il progettista usa per definire l'architettura di una applicazione

[FPV98].

La progettazione di applicazioni software richiede la scelta di un adeguato

linguaggio di programmazione; quando si parla di mobilità del codice e

l'ambiente di esecuzione è distribuito su larga scala, è anche importante

considerare da subito quale paradigma di progettazione utilizzare. Preferire un

paradigma piuttosto che un altro, è assolutamente indipendente dal linguaggio

utilizzato e dalla architettura su cui l'applicazione sarà eseguita, mentre può

influenzare notevolmente le prestazioni finali o provocare conseguenze non

irrilevanti in termini di affidabilità.

67

I sistemi che usano la mobilità consentono ai componenti di modificare

dinamicamente la loro posizione tra le macchine della rete: i concetti

fondamentali quindi diventano la locazione e la distribuzione delle risorse nel

sistema; per esempio, l'interazione tra due componenti che risiedono su host

remoti è molto più .onerosa del caso in cui la stessa interazione avvenga

localmente.

Si fornisce di seguito, una classificazione concettuale dei paradigmi di

progettazione basati sulla mobilità del codice, secondo i criteri descritti in

[CPV97]: una particolare attenzione deve essere rivolta alla locazione delle

risorse, ai componenti responsabili dell'esecuzione del codice e a dove realmente

il codice viene eseguito.

�� 5HPRWH�(YDOXDWLRQ

Nel modello client-server, il cliente può richiedere un servizio, solo se

appartenente a quelli messi a disposizione dal server. Infatti non è possibile

eseguire un codice arbitrario, poiché ad ogni servizio è associato un programma

prestabilito, con cui non si può interagire.

Il paradigma Remote Evaluation permette ad un programma di sfruttare

una entità remota, fornendo il codice da eseguire al sito in cui essa risiede. Così

si rende più flessibile l'utilizzo delle risorse, lasciando al programma la scelta di

come sfruttarle, attraverso una esecuzione più veloce, perché svolta localmente,

ed eventualmente bloccandosi in attesa di un risultato.

Se si presenta la necessità di creare un nuovo servizio, o di modificarne

uno esistente, non si deve riorganizzare il servitore (cioè la macchina in cui

risiede la risorsa), impedendo ad altri clienti di sfruttare le sue funzionalità

durante la fase di riorganizzazione, ma e sufficiente realizzare un frammento di

codice che soddisfi le nuove specifiche.

Il paradigma Remote Evaluation permette di realizzare un VHUYLWRUH

HODVWLFR�� cioè aperto e disponibile ad eseguire ogni tipo di codice,� GLQDPLFR�

poiché interagisce con le sue risorse in funzione dei cambiamenti e delle nuove

esigenze dei clienti che gli si rivolgono, ed anche JOREDOH��perché può eseguire

tutti i programmi presenti nel sistema.

Un semplice esempio di questo modello è la richiesta di stampa di un file

postscript su una periferica remota: il documento in questione rappresenta il

codice da eseguire, sempre diverso ad ogni richiesta.

�� &RGH�RQ�GHPDQG

Anche questo paradigma ha come obiettivo lo svolgimento di un servizio,

sfruttando la mobilità del codice, ma a differenza di prima, l'esecuzione avviene

all'interno della macchina che fa la richiesta.

La situazione iniziale è duale rispetto alla precedente: le risorse necessarie

sono già presenti localmente, e manca la conoscenza di come sfruttarle. L'host

remoto spedisce il codice in conseguenza di una esplicita richiesta che è eseguito

localmente sulla macchina richiedente. Così, le entità in esecuzione si rendono

dinamicamente estensibili, poiché possono ampliare la loro capacità di

esecuzione, avvalendosi di qualunque codice disponibile sulla rete. Anche in

questo caso, si realizza un HQWLWj GLQDPLFD� IOHVVLELOH� H� JOREDOH�� che esegue i

programmi dinamicamente disponibili nell'intero sistema.

Un'applicazione molto diffusa che sfrutta questo paradigma, è utilizzata

ogni volta che un utente richiede al proprio browser di visualizzare una pagina

web in cui è inserita una applet: il server riceve la richiesta e spedisce, alla

macchina dell'utente, il codice Java necessario da applicare alle risorse locali per

visualizzare gli effetti dell'applet.

�� $JHQWL�PRELOL

Gli agenti mobili sono unità di esecuzione (EU) che agiscono in nome di

un utente e che sono in grado di muoversi in modo autonomo all'interno di una

rete.

Questo paradigma è molto differente dai precedenti: in Remote Evaluation

e Code on Demand l'attenzione è rivolta allo spostamento di codice tra

componenti in esecuzione; ora invece è il componente stesso che si sposta,

trasportando anche i suoi dati, il suo codice e il suo stato di esecuzione.

Questo paradigma, che sarà affrontato in modo più approfondito nel

prossimo paragrafo, riduce al minimo lo scambio di messaggi sulla rete, per

69

evitare eventuali congestioni, e si avvantaggia della velocità delle esecuzioni

locali.

�� $JHQWL�0RELOL

Possiamo definire un DJHQWH� come una unità di esecuzione (EU che

comprende oltre al codice, lo stato di esecuzione e lo spazio dei dati) che agisce

autonomamente per conto di una persona o di una organizzazione [CHK95]. Il

termine "agente" deriva proprio dalla capacità di agire in nome dell'utente, per

raggiungere l'obiettivo finale, scegliendo in modo autonomo quali operazioni

intraprendere. Ogni agente ha il proprio flusso di esecuzione, in modo da

eseguire su propria iniziativa i compiti assegnatigli.

Un agente è� VWD]LRQDULR se agisce esclusivamente sul nodo su cui ha

iniziato la sua esecuzione; un agente, invece, è PRELOH� se ha l'abilità di

trasportare se stesso all'interno di una rete da una macchina ad un'altra, senza

essere vincolato a quella in cui ha iniziato la sua esecuzione; si sposta nel sistema

in cui si trova l'oggetto con cui vuole interagire, per trarre il beneficio di eseguire

operazioni locali [KT98].

In realtà, nel campo della "Intelligenza Artificiale" si definisce anche un

altro tipo di agenti, gli agenti intelligenti, che sono caratterizzati dalla capacità di

inferire nuova conoscenza durante il loro tempo di vita. Gli agenti intelligenti

sono tipicamente agenti stazionari, perché, a causa della loro natura, rischiano di

avere dimensioni elevate; gli agenti mobili, invece, essendo trasferiti

frequentemente devono essere snelli ("light weight"), per evitare di subire

spostamenti lenti, che congestionano la rete. Spesso i termini agenti mobili e

agenti intelligenti sono usati come sinonimi e ci si riferisce ad essi in generale col

termine agenti.

Le caratteristiche computazionali più importanti degli agenti possono

essere riassunte in questi termini:

• $XWRQRPL: ogni agente ha la capacità di scegliere, in funzione delle sue

informazioni, cosa fare, dove andare e quando spostarsi.

• $VLQFURQL: tutti gli agenti hanno un proprio flusso di esecuzione che possono

eseguire in modo asincrono.

• ,QWHUD]LRQL�ORFDOL: i loro spostamenti sono finalizzati ad eseguire interazioni

locali, per ridurre il costo, da effettuare con altri agenti mobili o in generale

con oggetti stazionari che risiedono localmente.

• (IILFLHQWL: l’uso degli agenti consente di ridurre il traffico di rete, soprattutto

nel realizzare interazioni remote complicate.

• ,QGLSHQGHQWL�GDOOD�UHWH: gli agenti possono eseguire i loro compiti anche se

la connessione di rete è al momento disattiva, interagendo con le risorse

locali. Qualora sia necessario uno spostamento, si attende che il

collegamento con la macchina remota si ripristini.

• (VHFX]LRQH�SDUDOOHOD: la distribuzione degli agenti su più macchine permette

di eseguire in parallelo i compiti intermedi che conducono al risultato finale,

riducendo i tempi di attesa.

• 2EMHFW�SDVVLQJ: la tecnologia più comoda per realizzare un agente mobile è

quella object-oriented, in modo che quando deve essere spostato, si trasferisce

l'intero oggetto, che comprende i dati, il codice e lo stato di esecuzione

dell'agente.

Queste caratteristiche permettono di ottimizzare ed ampliare i servizi

disponibili sulla rete, riducendone il traffico e quindi il rischio di congestione.

Per avere una visione più completa delle proprietà generali di un agente

mobile, analizzeremo le sue prerogative più interessanti, rappresentate dalla

capacità di migrare su macchine remote, dalla possibilità di comunicare con altri

agenti e dalle garanzie di sicurezza che deve fornire e che deve ricevere

dall'ambiente di esecuzione.

��0LJUD]LRQH

La caratteristica degli agenti mobili è di agire in modo autonomo, avendo

conoscenza degli interessi dell'utente e cercando di soddisfarli, attraverso lo

spostamento tra le macchine della rete. La migrazione è la conseguenza

dell'invocazione di un'istruzione, che provoca il trasferimento del codice

dell'agente e del suo stato di esecuzione.

71

L’attuazione del comando di spostamento si sviluppa seguendo queste fasi:

1) tutti i processi attivi dell’agente sono sospesi e insieme allo stato dell’agente

(cioè i dati, il codice e lo stato di esecuzione) sono elaborati per essere

incapsulati in un messaggio, espresso in una forma indipendente dalla

macchina;

2) il messaggio così creato, può essere indirizzato esplicitamente al destinatario

finale, o ad un nodo intermedio con funzioni di routing;

3) quando arriva nel sistema di destinazione, il messaggio deve raggiungere

l'ambiente di esecuzione a cui era destinato tra quelli presenti, e poi qui

l'agente viene ricomposto;

4) attraverso il suo stato di esecuzione e il valore dei suoi attributi, l'agente può

riprendere la sua esecuzione dall'istruzione successiva a quella della

migrazione.

Dopo la migrazione, l'agente può interagire con le funzioni applicative del

nuovo ambiente (servitore) e procedendo nella sua esecuzione potrebbe

intraprendere ancora una operazione di migrazione in modo analogo a quanto

appena descritto.

Quando si dice che raggiunto l'ambiente di destinazione l'esecuzione

dell'agente riprende dall'istruzione successiva a quella della migrazione, si

intende semplicemente che il flusso di esecuzione si riattiva in accordo con lo

stato e gli attributi che lo caratterizzano. E quindi una affermazione del tutto

generica che dovrebbe essere approfondita in considerazione del caso specifico

che il linguaggio considerato supporti un tipo di mobilità forte o debole.

Nel caso in cui la ripresa del flusso di esecuzione coincida esattamente

con l'istruzione successiva a quella dello spostamento, significa che la mobilità

supportata è di tipo forte. Se invece la ripresa necessita di una fase di preambolo,

che richiede la partenza da un punto prestabilito per consentire di ripristinare la

consistenza, allora il tipo di mobilità supportata è debole.

�� &RPXQLFD]LRQH�WUD�DJHQWL

In un sistema ad agenti, è necessario definire il modo in cui gli agenti

possono interagire tra loro per raggiungere il loro obiettivo. Gli stili di

comunicazione possono essere suddivisi in due categorie, in funzione del tipo di

interazione, stretta o lasca, che offrono:

♦ ,QWHUD]LRQH�VWUHWWD�� la comunicazione che si basa su una interazione stretta

tra due agenti, richiede una loro conoscenza esplicita. Si ottiene attraverso la

condivisione di oggetto o attraverso a diretta invocazione dì un metodo

remoto (per esempio, in 5HPRWH� 0HWKRG� ,QYRFDWLRQ�� 50, [RMI98], il

chiamante deve conoscere staticamente l'interfaccia del metodo remoto da

invocare [Java]). Questa è una comunicazione di alto livello e richiede una

conoscenza specifica degli oggetti o degli agenti remoti con cui interagire: per

inserire dinamicità, deve essere presente nel sistema un protocollo di

acquisizione di informazioni remote, che si mantenga aggiornato sulle ultime

modifiche e su eventuali spostamento, senza ricadere nella visione classica

dei sistemi distribuiti in cui si offre uno strato di trasparenza alla locazione.

La realizzazione di interazioni strette è abbastanza costosa ed è quindi da

utilizzare solo in casi realmente necessari.

♦ ,QWHUD]LRQH�ODVFD��la comunicazione che si basa su una interazione lasca, non

necessita di una conoscenza rigida tra gli agenti interessati. Un primo

meccanismo per realizzare una interazione lasca è lo VFDPELR�GL�PHVVDJJL, è

necessaria ancora una forma di conoscenza tra i due interlocutori, ma è meno

rigida, e può dipendere per esempio dal fatto di essere nati nello stesso

ambiente di esecuzione o di discendere dalla stessa famiglia.

Un altro metodo per realizzare interazione lasca, è costituito dalla

FRPXQLFD]LRQH�DQRQLPD��quando due agenti devono comunicare, ma non hanno

alcuna conoscenza reciproca, né hanno caratteristiche tali da potersi scambiare

messaggi, si può realizzare un supporto che permetta di conoscere facilmente il

nome di altri agenti, oppure è possibile realizzare astrazioni come la

"Blackboard" oppure uno "spazio delle tuple" [CG89].

�� 6LFXUH]]D

Il problema della sicurezza è molto importante in un sistema ad agenti

mobili, poiché questi si pongono l’obiettivo di spaziare su reti molto vaste, in cui

le risorse non sono direttamente amministrabili e controllabili.

73

I rischi esistono sia dal punto di vista dei nodi del sistema, che devono

essere protetti dagli attacchi di agenti non fidati, sia per quanto riguarda gli

agenti, che devono proteggere le informazioni sensibili trasportate dall’attacco di

ambienti ostili.

��5LVHUYDWH]]D�HG�LQWHJULWj

Gli agenti possono trasportare dati sensibili, che non devono essere

mostrati se non al corretto destinatario (si pensi ad esempio al numero di carta di

credito in un’applicazione di commercio elettronico). E’ dunque necessario che

lo stato dell’agente sia nascosto mediante tecniche crittografiche, almeno durante

il trasporto. E’ anche possibile che l’agente debba concedere la visione di parti

diverse dello stato a server diversi: deve dunque essere possibile nascondere

porzioni di stato.

Un altro problema consiste nel mantenere l’integrità dell’agente, cioè

nell’assicurare che nessuno possa modificare l’agente (il codice e/o lo stato)

durante il tragitto. In realtà questo è impossibile, ma ciò che si può fare è

individuare un’avvenuta modifica tramite l’uso di message digest.

��$XWHQWLFD]LRQH

Quando un agente si sposta su una nuova macchina, questa deve effettuare

l'autenticazione dell'utente, che è il mittente dell'agente, e viceversa l'agente deve

autenticare l'ambiente di esecuzione in cui si inserisce. Si parla di PXWXD

DXWHQWLFD]LRQH.

��$XWRUL]]D]LRQH�H�FRQWUROOR�GHJOL�DFFHVVL

Una volta che è avvenuta la mutua autenticazione è necessario garantire

che ad ogni agente siano concessi solo i diritti di accesso alle risorse stabiliti da

una precisa politica di autorizzazione.

Perché ciò avvenga è necessario associare ad ogni agente i permessi

adeguati (utilizzando meccanismi quali le Access Control List, le Capabilities o

le Sealed Labels) e assicurare che l’ambiente esegua un corretto controllo sugli

accessi.

Un problema più difficile da risolvere è quello opposto: garantire che il

sistema interagisca con l’agente secondo una politica stabilita. Una soluzione a

questo problema può derivare solo da un supporto hardware ad hoc. Uno di

questi sistemi è descritto in [WSB98].

�� -DYD�XQ�OLQJXDJJLR�DGDWWR�SHU�L�VLVWHPL�DG�DJHQWL

Java è un linguaggio object-oriented, progettato con lo scopo di fornire un

prodotto di piccole dimensioni, semplice, facile da imparare, portabile su diverse

piattaforme e adatto ad ogni dominio applicativo (general-purpose).

Java è un linguaggio, sintatticamente simile al C++, da cui derivano infatti

parte della sintassi e della struttura ad oggetti, ma nonostante la somiglianza, le

parti più complesse del linguaggio C++ sono state escluse, in modo da mantenere

la semplicità, senza sacrificare le potenzialità. Infatti in Java, a differenza del

C++, non è consentito l'uso dei puntatori a livello utente, ed è presente una

gestione automatica della memoria: in C++ è compito del programmatore

deallocare lo spazio di memoria nel momento in cui si elimina un puntatore,

mentre in Java questo avviene automaticamente, attraverso l'introduzione di uno

strumento detto �JDUEDJH�FROOHFWRU��che periodicamente libera dalla memoria gli

elementi non referenziati.

Nella programmazione ad oggetti, il meccanismo GHOOHUHGLWDULHWj

consente di specificare nella definizione di una classe solo le differenze rispetto

ad un'altra già esistente, considerando "ereditate" tutte le caratteristiche non

espressamente citate. Legato a questo aspetto, nel C++ esiste un meccanismo

non semplice da gestire, che è l'eredità multipla, cioè la possibilità per una classe

di ereditare le caratteristiche da più di una classe già esistente. Per semplificarne

la gestione, in Java questo strumento è disponibile solo per le LQWHUIDFFH� che

rappresentano le funzionalità disponibili in una classe senza la descrizione di

come siano realizzate.

Limitiamo a questi pochi esempi le differenze a livello di programmazione

tra Java e C++ (un confronto esaustivo è disponibile in [Nie98]) e soffermiamoci

invece sulla caratteristica che rende -DYD�XQ� OLQJXDJJLR�SDUWLFRODUPHQWH�DGDWWR

SHU�OD�UHDOL]]D]LRQH�GL�DSSOLFD]LRQL�GLVWULEXLWH��DYHQGR�OD�SRVVLELOLWj��VXSHUDUH

OHWHURJHQHLWj�LQWULQVHFD�GHL�VLVWHPL�DSHUWL. La realizzazione di una applicazione

in C++, o in qualunque altre linguaggio, prevede la fase di scrittura del codice e

75

di compilazione: il compilatore traduce il programma in un linguaggio

comprensibile alla macchina su cui si lavora (e a tutte quelle compatibili), ma per

eseguirlo su una architettura diversa si deve compilare nuovamente il codice

sorgente con un compilatore diverso dal precedente e adatto al nuovo sistema.

In Java, invece, il codice sviluppato dal programmatore passa attraverso

due componenti: un compilatore e un interprete. Il compilatore Java trasforma il

codice sorgente (invece che in linguaggio macchina) in una forma intermedia e

indipendente dalla piattaforma, il cosiddetto E\WH�FRGH��per riuscire ad eseguire il

programma, realizzato dall’utente, il byte code deve essere interpretato da una

macchina virtuale stack-based, detta -DYD 9LUWXDO� 0DFKLQH (JVM).

L’introduzione dell’innovativo codice intermedio indipendente dalla piattaforma,

permette a Java di essere un linguaggio altamente portabile, destinato ad essere

utilizzato con successo in tutti i sistemi con architetture eterogenee, che sono

l’ambiente di sviluppo naturale per le applicazioni ad agenti mobili.

Un fattore chiave del successo di Java è la totale LQWHJUD]LRQH FRQ� OD

WHFQRORJLD� :::: i browser web includono nelle loro estensioni la JVM e

questo permette sia di realizzare con estrema facilità pagine interattive, animate

con effetti speciali, da parte di programmatori principianti, sia progetti complessi

per utenti più esperti. Così il linguaggio Java è entrato nel mondo informatico,

sia a livello professionistico che dilettantistico, affermandosi come leader in tutte

le applicazioni distribuite.

Vediamo in dettaglio le caratteristiche che offre questo linguaggio e

verifichiamo se sono adatte per la realizzazione di un sistema ad agenti mobili.

Un primo vantaggio dell'utilizzo del byte code è OHOHYDWD SRUWDELOLWj�di

Java, come di ogni altro linguaggio interpretato, che può eseguire in tutte le

piattaforme per cui esista una JVM. Data la popolarità che ha acquistato in

questi anni, si può dire che praticamente tutti i tipi di macchina forniscano un

interprete Java, rendendo veritiero lo slogan che Sun usa a proposito di Java:

"write once, run anywhere". L'ambiente di esecuzione del paradigma ad agenti

mobili è un sistema distribuito in cui convivono diversi tipi di macchine: usare

Java come strumento di programmazione offre il beneficio di poter far migrare

gli agenti in tutti i siti remoti in cui sia presente una JVM, e questo implica una

elevata portabilità. E giusto sottolineare che i linguaggi interpretati offrono,

come svantaggio, una diminuzione delle prestazioni, rispetto ai linguaggi

compilati; per ottenere le stesse prestazioni, Java mette a disposizione un

compilatore di byte code, detto JIT (Just In Time), per sfruttare il linguaggio

macchina nativo.

Il secondo vantaggio deriva dalla possibilità di svolgere un SURFHVVR� GL

YHULILFD�sul codice prima dell'esecuzione, con il quale si eliminano le operazioni

che potrebbero scatenare un overflow dello stack, e si controlla che i metodi

degli oggetti referenziati siano invocati con il corretto numero e tipo di

argomenti. Questa verifica è agevolata dal fatto che in Java non è prevista

l'esistenza di tipi di dato, come i puntatori, che possono condurre all'accesso

indiretto di aree non consentite.

Se durante l'esecuzione di un programma, si presenta un riferimento al

nome non risolto di una classe, la JVM invoca a runtime il FODVV�ORDGHU��che è un

meccanismo di programmazione che ricerca e carica dinamicamente �G\QDPLF

OLQN�� le classi necessarie. Il class loader prima controlla che il frammento di

codice non sia una classe di sistema, poi verifica che non sia già in memoria,

altrimenti cerca di recuperarla da quale sito remoto; a questo punto il codice

scaricato comincia la sua esecuzione. L'aspetto interessante è che Java fornisce

al programmatore la possibilità di implementare un proprio class loader,

ereditando le caratteristiche fondamentali da quello di sistema; con questo

strumento possiamo caricare il codice di un agente da una qualunque macchina

della rete.

Una caratteristica relativamente nuova in Java (perché introdotta solo con

il jdk 1.1) è la possibilità di VHULDOL]]DUH�gli oggetti; questo permette a qualunque

oggetto di essere trasformato in modo reversibile in una rappresentazione adatta

per la memorizzazione su disco o per la trasmissione in rete. Con questo

meccanismo è possibile trasferire ad una macchina remota un Thread o un

qualunque oggetto creato dal programmatore; l'unica e semplice condizione è che

implementi l'interfaccia Serializable, cosa che tutte le classi possono fare. Nel

paradigma ad agenti, la serializzazione è sfruttata per trasmettere lo stato

dell'agente nel momento in cui vuole spostarsi.

Anche la gestione del QHWZRUNLQJ� q� affrontata in Java, offrendo al

programmatore un'interfaccia semplice e chiara, che facilita le operazioni su un

77

canale di comunicazione con macchine remote (per esempio, il pacchetto di

gestione delle VRFNHW�� q�più intuitivo rispetto ad altri linguaggi, come il C++).

Quando si progetta un sistema che implementa un paradigma basato sulla

mobilità, la gestione dei collegamenti di rete riveste un ruolo molto importante

per lo spostamento del codice.

Il vantaggio della programmazione distribuita è la possibilità di sfruttare

l'esecuzione concorrente e Java offre a questo riguardo caratteristiche di

VLQFURQL]]D]LRQH�a livello di linguaggio, cioè è possibile scrivere sezioni critiche

in modo pulito ed elegante, con istruzioni specifiche: la clausola �V\QFKURQL]HG�

permette di gestire la sincronizzazione tra thread o risorse, ricordando però che è

sempre compito del programmatore utilizzare in modo opportuno questo

strumento.

Un punto debole di molti linguaggi è il livello di VLFXUH]]D�che offrono;

Java nella jdk 1.2 ha introdotto un nuovo modello di sicurezza [Gong98],

ampliando quello assai limitato costituito dalla sand box presentata nella versione

iniziale del jdk 1.0, e già migliorato da una più efficiente granularità nella jdk 1.1

[Gong97]. In un sistema ad agenti mobili si devono prevedere meccanismi per

proteggere sia gli host che gli agenti in arrivo su nuovi ambienti.

Esiste anche un principale limite nell'utilizzo di Java per gli agenti mobili:

per ragioni di sicurezza non è possibile accedere allo stack di esecuzione di un

programmi, e quindi non è possibile ripristinarlo, per esempio, in seguito ad una

serializzazione. Questo significa che quando un agente decide di spostarsi, non è

possibile interrompere la sua esecuzione per farla riprendere dallo stesso punto

sulla macchina remota: dalle definizioni viste in precedenza, possiamo affermare

che Java non supporta la mobilità forte.

Se non si vuole comunque rinunciare alla "strong mobility", si deve

accedere allo stato interno della JVM, realizzando una di queste due soluzioni.

♦ &KHFNSRLQWLQJ� Si deve monitorare completamente l'esecuzione del codice,

per collezionare i dati necessari alla migrazione, dati che, quando l'agente si

sposta, si spediscono alla macchina remota. Nel sito remoto, durante la fase

di ripristino delle informazioni si devono sfruttare i FKHFNSRLQW� (inseriti dal

sistema su cui l'agente eseguiva precedentemente) che segnalano dei punti

stabili del codice da cui è possibile riprendere l'esecuzione. Per sfruttare

questa tecnica, è necessario realizzare un post-compilatore in grado di inserire

all'interno del byte code gli accorgimenti necessari per coordinare le due

macchine.

♦ 0RGLILFD�GHOOD�PDFFKLQD�YLUWXDOH��All'interno della macchina virtuale sono

già presenti tutti i dati relativi allo stato di esecuzione degli agenti, che

possono essere estratti con qualche modifica della stessa JVM. Ma questi

cambiamenti comportano, come grave conseguenza, la perdita della

portabilità.

Per non rinunciare comunque al vantaggio della portabilità che offre

questo linguaggio, è possibile implementare una mobilità debole: nel nuovo

ambiente gli agenti riprenderanno la loro esecuzione a partire da un punto

stabilito a priori.

Dopo un bilancio totale delle caratteristiche positive e negative che Java

offre allo sviluppo di sistemi ad agenti mobili, concludiamo affermando che, a

nostro parere, si tratta di un linguaggio molto adatto con cui sviluppare

applicazioni distribuite, realizzate con un qualunque paradigma di mobilità del

codice.

��6LVWHPL�HVLVWHQWL�DG�DJHQWL�PRELOL

La recente popolarità del codice mobile, ha portato alla nascita di un

numero elevato di sistemi ad agenti. Viene fornito di seguito un breve excursus

su alcuni dei sistemi più diffusi. In questa presentazione, in particolare, si è

cercato di sottolineare le caratteristiche di mobilità attribuite agli agenti e di

estrarre le proprietà peculiari più significative di ogni sistema.

�� 7HOHVFULSW

Telescript [Teles94], sviluppato dalla General Magic, è stato il primo

sistema commerciale ad agenti mobili e quindi lo citiamo per l'importanza storica

che riveste.

Telescript è realizzato con un linguaggio proprietario, chiamato /RZ

7HOHVFULSW��object-oriented e simile a Java e al C++. In ogni macchina della rete

79

sono implementati uno o più ambienti di esecuzione virtuali, detti SODFH. Gli

agenti si spostano tra le macchine del sistema attraverso il metodo JR,

riprendendo la loro esecuzione dal punto in cui avevano terminato nel nodo

precedente: la mobilità supportata è di tipo forte. L'interazione avviene in due

modi distinti: il comando PHHW�permette agli agenti di invocare metodi di altri

agenti che risiedano sullo stesso place, mentre il comando FRQQHFW�consente il

collegamento remoto tra agenti, per lo scambio di oggetti.

Questo sistema è stato considerato da subito un buon prodotto, anche per i

meccanismi di sicurezza che fornisce. Quando un agente si sposta, presenta al

place di destinazione delle informazioni, dette FUHGHQ]LDOL��che sono necessarie al

nuovo ambiente di esecuzione, per autenticare l'identità dell'utente creatore e in

funzione delle quali il sistema assegna all'agente stesso un adeguato grado di

fiducia; durante la migrazione, le credenziali sono protette da eventuali

manipolazioni esterne con l'uso di tecniche crittografiche. In più ad ogni agente

sono assegnati dei permessi che autorizzano all'uso delle risorse disponibili:

questi permessi sono concessi dai place, che in tal modo si proteggono da

eventuali comportamenti maligni.

Telescript offre anche un buon sistema di tolleranza ai guasti: in ogni

macchina è presente un server che con continuità memorizza su un supporto non

volatile lo stato di esecuzione di tutti gli agenti locali, così che diventi semplice il

ripristino dello stato consistente in caso di caduta del nodo.

Nonostante Telescript sia un prodotto con una buona tolleranza ai guasti,

sicuro ed efficiente, la General Magic ha subìto una battuta d'arresto sul mercato

a causa della rapida e sempre crescente attenzione dedicata a Java dal mondo

informatico e a causa della mancanza di apertura del sistema, basato su un

linguaggio proprietario.

�� 2GLVVH\

Odissey [Odi98] è il sistema che la General Magic ha sviluppato per

sostituire Telescript: in generale offre le stesse caratteristiche, a parte il fatto che

il linguaggio utilizzato è Java. Questo cambiamento influisce anche sul tipo di

mobilità sopportato; come si è già notato, Java non fornisce le caratteristiche

necessarie per catturare lo stato completo di un programma in esecuzione,

fornendo, di default, una mobilità di tipo debole. Per mantenere la compatibilità

con tutte le JVM, l'istruzione go non può più presentare le stesse caratteristiche

offerte in Telescript. La General Magic ha imposto che gli agenti Odissey

possano scegliere solo tra queste due alternative: la prima semplicemente

consente di ricominciare da capo l'esecuzione dopo lo spostamento su un nodo

remoto, mentre la seconda permette di creare, prima di iniziare a navigare per la

rete, una lista di compiti da svolgere sulle determinate macchine che si intende

visitare, lista che può essere anche modificata dinamicamente.

Odissey non è un prodotto commerciale, a differenza di Telescript, ed è

usato dalla General Magic per svolgere la realizzazione di servizi ed applicazioni

interni alla società.

�� $JOHWV

Aglets è il sistema realizzato da Ibm, che oggi sembra riscuotere il

maggiore interesse tra quelli disponibili sul mercato [IBM96]. Il termine $JOHWV

deriva dalla fusione di DJHQW�H�DSSOHW��per il fatto che le API riprendono concetti

e terminologia propri delle applet [LC96].

L'ambiente di esecuzione degli agenti, il FRQWH[W�� è indipendente dal

sistema su cui si lavora e per trasferire gli agenti sulla rete si utilizza O$JHQW

7UDQVIHU� 3URWRFRO� (ATP) [LA97]. Questo protocollo è stato progettato per un

uso su Intemet, è uniforme e indipendente dalla piattaforma e permette quindi di

trasferire agenti tra qualunque tipo di macchina. L'ATP cerca di porsi come

punto di connessione tra i tanti sistemi presenti, ciascuno con le proprie scelte

implementative e con i propri linguaggi di programmazione: un passo importante

per raggiungere un primo livello di standardizzazione nel campo della mobilità.

Il sistema di Ibm è totalmente scritto in Java e supporta solo una mobilità

di tipo debole: dopo ogni spostamento l'agente deve ricominciare l'esecuzione da

un punto prestabilito, pur mantenendo i valori delle interazioni avvenute in

precedenza.

Il trasferimento degli Aglet può avvenire secondo due modalità differenti

[MKO98]. La primitiva GLVSDWFK� sposta un frammento di codice o

un'applicazione stand-alone sulla macchina il cui nome è fornito come

argomento, in modo asincrono e immediato. Al contrario, la primitiva UHWUDFW

81

impone all’agente di ritornare nel contesto di origine, in cui ha iniziato la sua

esecuzione.

�� 9R\DJHU

Voyager è il tool di sviluppo proposto da ObjectSpace [OBJ97], realizzato

in Java, con mobilità debole, e compatibile con lo standard proposto da Corba

[CORBA].

Voyager permette dì costruire oggetti remoti, di spedire loro messaggi e di

spostarli tra le applicazioni secondo necessità. Un agente è visto come un

particolare tipo di oggetto e quindi, sfruttando la sintassi standard di Java, è

possibile creare agenti remoti. Un'altra novità introdotta da Voyager è un

servizio di nomi integrato, che associa ad ogni oggetto (e quindi in particolare

anche agli agenti) un alias, con il quale in seguito è possibile referenziare

dinamicamente l'oggetto stesso anche se è stato mosso (l'associazione infatti non

si riferisce all'indirizzo della macchina in cui risiede l'elemento considerato).

Un agente per spostarsi si auto-spedisce il messaggio PRYH7R indicando la

meta del trasferimento e il metodo da eseguire una volta arrivato. La

destinazione può essere una locazione oppure un oggetto; questo gli permette di

raggiungere la risorsa con cui interagire, anche quando questa si muove. Il

tempo di vita degli agenti Voyager può essere determinato dall'utente, dando la

preferenza ad una delle cinque possibilità disponibili: un agente può vivere

finché ha riferimenti attivi (locali o remoti), per una certa quantità di tempo, fino

ad un particolare istante, finché non rimane inattivo per un tempo prestabilito

oppure per sempre. Di default, gli agenti Voyager vivono per un giorno.

83

&DSLWROR��620$�81�6,67(0$�$'�$*(17,

02%,/,

�� ,QWURGX]LRQH

Il sistema SOMA (Secure and Open Mobile Agent) è un ambiente di

sviluppo per applicazioni ad agenti mobili, realizzato presso il dipartimento di

elettronica, informatica e sistemistica (DEIS) dell'Università di Bologna;

progettato nell’ambito del "Project Design Methodologies and Tools of High

Performance Systems for Distributed Applications" fondato dal Ministero

dell’Università e della Ricerca Scientifica e Tecnologica (MURST). Al sistema è

dedicato un sito web [SOMA], costantemente aggiornato da parte dei

responsabili del progetto, in cui è possibile reperire tutte le informazioni più

recenti, insieme al codice, che è distribuito liberamente.

SOMA è stato sviluppato materialmente da studenti della Facoltà di

Ingegneria dell’Università di Bologna nell’ambito delle loro Tesi di Laurea, che

descrivono accuratamente l’evoluzione del progetto nelle sue fasi successive

[Tar98] [Ten98] [Chi98] [Coc98] [Cav98] [Pro98].

Il sistema è realizzato interamente tramite il linguaggio Java e sfrutta

dunque le caratteristiche che rendono questo linguaggio adatto per la

realizzazione di applicazioni ad agenti mobili.

L'architettura su cui lavorano gli agenti SOMA, presenta tutte le

caratteristiche di un sistema ad agenti descritte nel capitolo precedente. In

particolare le proprietà principali dell’ambiente sono:

♦ VLFXUH]]D: è realizzata la protezione sia dal lato degli agenti che da quello

degli ambienti in cui eseguono. L'accesso al sistema è protetto da password,

così che solo utenti autorizzati possono creare agenti SOMA in grado di

viaggiare nel sistema;

♦ DSHUWXUD: il sistema aderisce alla standardizzazione proposta da OMG, cioè è

prevista l'interazione di agenti SOMA con applicazioni CORBA-compliant e

con gli agenti degli altri sistemi che aderiscono allo stesso standard;

♦ GLQDPLFLWj: esistono strumenti per la gestione delle modifiche dinamiche della

configurazione e dell'inserimento dinamico di nuovi utenti;

♦ SRUWDELOWj: attraverso l’uso del linguaggio Java, l’ambiente può essere

utilizzato su un vasto numero di piattaforme eterogenee;

♦ VFDODELOLWj: è disponibile a vari livelli, dalla configurazione del sistema, la cui

topologia può essere estesa a piacimento, alla gestione degli utenti e al

numero di agenti in esecuzione, assolutamente non limitati;

♦ SUHVWD]LRQL: l’uso degli agenti mobili consente di migliorare le performance di

una applicazione, rispetto al tradizionale paradigma cliente-servitore; la

gestione della sicurezza è configurabile in maniera flessibilità permettendo di

raggiungere il compromesso prestazioni/sicurezza desisderato;

♦ IDXOW� WROHUDQFH: i nodi del sistema possono non essere tutti attivi in un

determinato momento, il sistema gestisce la possibilità di avere nodi attivi e

non attivi sistema;

♦ WRRO� JUDILFL: tutte le operazioni utente (es., l'attivazione di un agente) sono

accompagnate da una interfaccia grafica chiara ed intuitiva.

�� $UFKLWHWWXUD�JHQHUDOH�GHO�VLVWHPD

L’architettura di SOMA nasce dall’imitazione della struttura di un sistema

complesso come Internet. E' caratterizzato da una serie di località organizzate in

gerarchia, ognuna con le proprie caratteristiche, dal punto di vista

dell’amministrazione, della gestione e della sicurezza. Le varie località sono

connesse tra loro in maniera dinamica, con una topologia variabile nel tempo.

SOMA cerca di modellare una simile struttura, introducendo diverse

astrazioni di località, che descrivono le tipiche località di Internet e forniscono

nel contempo un ambiente in cui sia possibile sviluppare applicazioni secondo il

modello degli agenti mobili.

85

Le astrazioni di località introdotte sono:

• 3ODFH�� rappresenta l’ambiente di esecuzione degli agenti (il CE), come

astrazione del concetto di nodo. Al suo interno gli agenti possono interagire

con le risorse locali e cooperare con altri agenti residenti sul place. Ogni place

è caratterizzato da un nome (classe 3ODFH1DPH). Ogni nodo può contenere

più place, mentre ogni place deve essere confinato all’interno di un nodo.

• 'RPLQLR� rappresenta un’aggregazione di place, come astrazione del concetto

di rete locale, che presentano caratteristiche comuni di tipo fisico

(appartenenza alla medesima LAN) o logico (amministrazione e politiche

comuni). Ogni dominio è caratterizzato da un nome (classe 'RPDLQ1DPH).

I place di un dominio sono strettamente correlati tra loro, si conoscono a

vicenda e sono in grado di comunicare direttamente. Le interazioni che

coinvolgono due diversi domini sono invece mediate da un particolare place,

detto “*DWHZD\” o “'HIDXOW�3ODFH”. I Gateway hanno conoscenza uno dell’altro e

sono in grado di comunicare direttamente. Il Gateway rappresenta dunque l’unico

punto di accesso verso l’esterno di un dominio; può essere visto come

un’astrazione dei Gateway (eventualmente con funzioni di Firewall) che

collegano le diverse reti locali in ambiente Internet.

�� $JHQWL�0RELOL

Un agente mobile in SOMA è implementato come istanza di una classe

derivata dalla classe astratta di base “Agent.java”, che definisce le proprietà e le

caratteristiche comuni di tutti gli agenti.

Ogni agente ha un identificatore unico ($JHQW,') nel sistema composto

dai nomi del Dominio e del Place dove è stato creato e da un numero progressivo

unico locale al place. Possiede una Mailbox, per gestire lo scambio di messaggi,

un set di preferenze e un set di credenziali; il campo “Traceable” che indica se

l'agente è rintracciabile o meno, ossia se è possibile spedirgli dei messaggi.

All'agente ha dei metodi pubblici per gestire la fase di avvio, per la migrazione

intra ed inter dominio, per ottenere l'identificatore, per aggiungere preferenze e

per richiedere credenziali ad un place.

L’agente è un oggetto passivo, su ogni place è gestito da un thread, detto

":RUNHU", che ha il compito di associare all'agente un flusso di esecuzione. Ciò è

indispensabile perché la JVM non permette la migrazione di un'EU (un thread),

ma solo di oggetti passivi, implementando esclusivamente la mobilità debole.

Quando un agente nasce viene subito affidato ad un Worker che fa partire

la sua esecuzione dal metodo specificato nel campo Start, che di default coincide

con il metodo run(), e poi attende la sua terminazione. Nel momento in cui

l'agente decide di spostarsi, il suo Worker è sostituito con un altro appositamente

creato sull’ambiente di destinazione: anch’esso si limita a lanciare il metodo

specificato come argomento nel comando go(), in questo modo si riesce a

simulare il controllo di flusso tipico della mobilità forte. Per inserire un agente

nel sistema, l’utente può utilizzare il tool grafico “AgentLauncher”.

�� 0RELOLWj

La migrazione degli agenti è implementata attraverso il comando go(), che

può essere invocato dagli agenti in un qualunque momento.

L’effetto di questa invocazione è il seguente: l’esecuzione dell’agente è

sospesa, l’oggetto in cui è implementato è serializzato e spedito all’ambiente di

destinazione. Il comando go() prevede due argomenti: il primo rappresenta la

località di destinazione, mentre il secondo, specifica il nome del metodo da cui

riprendere l’esecuzione.

La destinazione di uno spostamento può essere espressa in termini di

nome del Place su cui spostarsi oppure di nome del Dominio da raggiungere. Il

primo caso segnala al sistema la volontà dell’agente di effettuare una migrazione

interna al Dominio, che rientra nella gestione intra Dominio. Il secondo caso,

invece, specifica che il trasferimento coinvolge un Dominio diverso da quello

attuale e quindi si impone il passaggio attraverso il Gateway. Infatti, nella

gestione inter Dominio, ogni tipo di interazione con entità esterne al Dominio

deve essere sottoposta al controllo del Gateway.

Un agente che desidera cambiare il Dominio di esecuzione deve invocare

il comando go(), specificando come destinazione il nome del Dominio da

raggiungere: come conseguenza, l’agente è affidato dal Place attuale al suo

87

Gateway, che lo consegna al Default Place del Dominio remoto. Nel nuovo

Dominio poi l’agente può scegliere su quale Place riprendere la sua esecuzione.

Se durante uno spostamento si verifica un problema che non consente all’agente

di raggiungere il suo obiettivo, il sistema segnala all’agente stesso una situazione

anomala attraverso l’eccezione “CantGoException”.

L’invocazione del comando go() può segnalare un evento imprevisto,

come per esempio, il fatto che, in una transizione intra Dominio, il Place da

raggiungere non sia attivo oppure che, durante una migrazione inter Dominio, si

segnali la disattivazione del Gateway locale. Quando è sollevata l’eccezione

CantGoException, è possibile eseguire delle azioni alternative che consentano

all’agente di aggiornare le sue scelte: per fare questo è sufficiente gestire

l’eccezione attraverso i meccanismi messi a disposizione da Java.

Quando l’agente è arrivato a destinazione, si consulta il nome del metodo

da cui ripartire, che è specificato come secondo argomento del comando go(). La

mobilità debole di Java, impone di ricominciare l’esecuzione da un punto preciso

e in SOMA si è scelto di farlo corrispondere con l’inizio di un metodo: come

conseguenza di questa decisione, è bene che il comando go() risulti l’ultima

istruzione di ogni metodo.

�� &RPXQLFD]LRQH

Nel progettare i meccanismi di comunicazione di SOMA è stato seguito

un criterio molto rigido: i meccanismi di LQWHUD]LRQH�VWUHWWD sono ammessi solo

fra agenti che si trovano nello stesso place. Questo criterio è fondato su uno dei

principi base del paradigma ad agenti mobili, che prevede la non trasparenza

della località delle risorse e degli agenti sulla rete. In quest'ottica non ha senso

prevedere forte accoppiamento fra agenti che si trovano su place diversi, quindi i

meccanismi di interazione stretta vanno riservati alle comunicazioni nell'ambito

dello stesso place.

�� &RPXQLFD]LRQH�WUD�$JHQWL�VLWXDWL�VX�SODFH�GLYHUVL

SOMA fornisce un solo meccanismo di comunicazione tra agenti che si

trovano in place diversi: lo scambio di PHVVDJJL.

Un messaggio è un oggetto composto da 3 elementi:

1) L’identificatore dell’agente mittente.

2) L’identificazione dell’agente destinatario.

3) Il contenuto del messaggio, un oggetto di qualsiasi tipo, che possa essere

trasferito da un place all’altro.

Un agente può spedire un messaggio ad un altro agente indipendentemente

dal place in cui si trova il destinatario. Il mittente non è neanche tenuto a

conoscere la posizione attuale dell’agente destinatario, che potrebbe anche essere

in una fase di spostamento. L’unica informazione necessaria per la spedizione è

l’identità del destinatario.

Spedito un messaggio, l’agente non riceve alcuna conferma di ricezione da

parte del destinatario, ma il sistema garantisce il recapito del messaggio, se il

destinatario si trova su un place raggiungibile.

Ogni agente dispone di una Mailbox, che conserva i messaggi ricevuti e

non ancora letti. È possibile vedere in maniera nonbloccante se sono presenti

messaggi nella mailbox, oppure attenderli in maniera bloccante.

Non tutti gli agenti dispongono del servizio di messaggeria. Infatti, per

poter recapitare un messaggio a un agente, il sistema deve sempre tenere traccia

dei suoi spostamenti, e questo comporta un certo overhead, soprattutto in termini

di utilizzo della rete. Si è quindi deciso di poter creare agenti QRW�WUDFHDEOH��non

rintracciabili, e quindi privi di Mailbox, per migliorare l’efficienza di

applicazioni che non necessitano di questo servizio. In ogni caso, a default ogni

agente è WUDFHDEOH.

�� &RPXQLFD]LRQH�WUD�$JHQWL�VLWXDWL�VXOOR�VWHVVR�SODFH

Per quanto riguarda invece la comunicazione fra agenti che si trovano

nello stesso place, oltre lo scambio di� PHVVDJJL si possono utilizzare altri due

meccanismi di comunicazione di tipo LWHUD]LRQH�VWUHWWD:

• La FRQGLYLVLRQH�GL�RJJHWWL: oggetti di qualsiasi tipo possono essere depositati

in uno speciale contenitore, ricevendo in cambio un identificatore con il quale

sarà possibile accedere di nuovo all’oggetto da parte dello stesso o di un altro

agente.

89

• La EODFNERDUG�� una lavagna su cui lasciare messaggi del tipo �FKLDYH�

FRQWHQXWR�, dove FKLDYH�è una stringa di descrizione e PHVVDJJLR�un oggetto

qualsiasi.

La differenza è che la FKLDYH�della EODFNERDUG�è di tipo stringa, e fornisce

una descrizione “in chiaro” del contenuto, a differenza dell’identificatore del

caso precedente che, invece, viene fornito dal sistema. Così, affinché un altro

agente possa aver accesso ad un oggetto condiviso, deve essergli fornito

l’identificatore da colui che lo ha depositato, mentre nel caso della blackboard è

sufficiente accordarsi sul “nome” (FKLDYH) da dare ad un certo tipo di

informazione.

In sostanza la blackboard è l’unico dei tre meccanismi visti che permette

di comunicare con agenti di cui non si conosca già l’identificatore (LQWHUD]LRQH

DQRQLPD), e può essere utilizzato proprio per mettere in contatto agenti che

altrimenti non si potrebbero conoscere.

�� 6LFXUH]]D

SOMA fornisce sistemi di sicurezza sia per la protezione dell'ambiente

che degli agenti.

La definizione di differenti astrazioni di località consente di assicurare

politiche di sicurezza nelle quali le azioni sono controllate sia a livello di place

che a livello di dominio. Il dominio definisce una politica di sicurezza globale

che impone autorizzazioni e proibizioni generali; ogni place può solo applicare

restrizioni ai permessi consentiti a livello di dominio.

�� 3URWH]LRQH�GHOODPELHQWH

Gli agenti entranti in un dominio o in un place sono autenticati sulla base

di una serie di informazioni: il nome del place e del dominio di origine, i nomi

delle classi che implementano gli agenti, e il nome degli utenti per i quali gli

agenti lavorano.

In funzione di questa autenticazione viene assegnato all'agente un certo

grado di fiducia che si traduce nei diritti di accesso ed uso di un numero limitato

e predefinito di risorse del place in accordo alla politica di sicurezza; ogni risorsa

ha una sua specifica access control list per tutti i SULQFLSDO che potenzialmente

possono accedervi.

Inoltre i place sono protetti grazie al fatto che gli agenti possono accedere

alle risorse di un nodo solo per mezzo di interfacce.

�� 3URWH]LRQH�GHJOL�DJHQWL

Senza un supporto hardware adeguato, non è possibile evitare che

l'ambiente di esecuzione di un place faccia quello che vuole su un agente. Quello

che si può fare, è cercare di scoprire, in un place di fiducia, le eventuali

manomissioni subite da un agente quando torna da un place non fidato.

In SOMA, vengono protetti l’integrità del codice e la riservatezza dei dati

di un agente quando questo è trasmesso su un canale di comunicazione.

L’integrità si garantisce sottoponendo l’agente al processo della firma con la

chiave privata del 3ULQFLSDO creatore. Mentre la riservatezza si raggiunge

sottoponendo l’agente a cifratura, prima che questi sia spedito sulla rete. In

realtà, in SOMA, è possibile cifrare ogni tipo di oggetto scambiato tra due

Places.

91

&DSLWROR��6,67(0,�3(5�,/�5(&83(52�'(,

&(57,),&$7,

�� ,QWURGX]LRQH

Il recupero di un certificato per un possibile interlocutore appartenente a

un dominio di fiducia diverso richiede la determinazione e la convalida di un

cammino di certificazione. Uno standard per la convalida non è stato definito

[L97 pag. 45], la procedura di convalida può essere realizzata in vari modi

[RFC2459 cap. 6]. L’importante è che il risultato sia lo stesso qualsiasi

procedimento si adotti.

Il metodo più utilizzato per controllare la validità di un singolo certificato

è vedere se è contenuto nella Certificate Revocation List (CRL) che può essere

recuperata dal sistema di directory a cui si appoggia la CA responsabile.

Le autorità di certificazione possono anche mettere a disposizione un

server on-line dedicato per notificare lo stato di revoca dei certificati. In questo

caso la verifica della validità dei certificati può essere richiesta direttamente

attraverso delle query OCSP [RFC2560].

Questo secondo metodo di verifica è preferibile, sempre che sia

disponibile, in quanto garantisce la massima certezza sulla validità dei certificati,

come evidenziato nel paragrafo 3.6.

Le tecniche di ricerca e validazione che si possono realizzare dipendono

fortemente dalla struttura delle PKI.

�� 5LFHUFD�H�FRQYDOLGD�GHL�FDPPLQL�GL�FHUWLILFD]LRQH

Per costruire cammini di certificazione di lunghezza accettabile si fa

riferimento alla teoria dei grafi da cui si vede che le strutture organizzate ad

albero o gerarchiche forniscono una soluzione efficiente al problema.

�� 3.,�FRQ�VWUXWWXUD�JHUDUFKLFD

Nel modello gerarchico stretto la certificazione è realizzata solo dalle

autorità superiori nei confronti di quelle gerarchicamente inferiori. Tutti i

cammini di certificazione partono dal vertice, ogni utente deve quindi fidarsi

della radice e conoscere la relativa chiave pubblica.

Il vantaggio di tale struttura è che per ogni utente esiste un unico cammino di

certificazione e la sua determinazione è abbastanza semplificata.

Lo svantaggio è che tutti i cammini di certificazione coinvolgono la radice

e quindi la fiducia è completamente riposta nella sicurezza della radice.

Un esempio di implementazione di infrastruttura a chiave pubblica

conforme al modello gerarchico è la PEM (Privacy Enhancement for Internet

Electronic Mail) [RFC 1421-1424]. Questa infrastruttura prevede che quando un

utente spedisce un messaggio firmato ad un altro utente includa al messaggio

anche il cammino dal vertice della gerarchia a se stesso [RFC 1422 pag. 24]. Il

cammino di certificazione è così già conosciuto, visto che ogni utente si fida

della radice e possiede la relativa chiave. Quando invece un utente vuole spedire

un messaggio crittografato ad un altro utente non conosce il cammino di

certificazione, ma data la struttura gerarchica, può essere determinato con

algoritmi di ricerca in un albero. In PEM sono disponibili servizi che lo

determinano, ma la cui implementazione è lasciata ad un sistema di directory.

Trovare il cammino più corto tra due punti in una struttura ad albero è un

problema già affrontato e risolto da vari ricercatori con diverse metodologie.

Algoritmi applicabili sono quelli classici dell’ottimizzazione combinatoria

[CMT79] per determinare un cammino dalla radice ad un nodo; in questo caso

una foglia che rappresenta il certificato del destinatario del messaggio.

In assenza di informazioni si può applicare solo una strategia in avanti o

"forward", partendo dalla radice si cercherà di raggiungere il nodo foglia

corrispondente al certificato da trovare. La ricerca può avvenire in due modi

differenti: in profondità (depth first) o in ampiezza (breadth first). Nella prima si

cerca di raggiungere rapidamente una soluzione visitando ad ogni passo sempre il

nodo più lontano dalla radice, viceversa nella tecnica in ampiezza dove il nodo

scelto per la visita è il più vicino alla radice. La ricerca in profondità è più

93

efficiente nel caso di struttura strettamente gerarchica, ma in presenza di cross-

certification (connessione aggiuntiva di due nodi) tra due diverse CA può

generare dei loop, al contrario della ricerca in ampiezza che è completa.

Spesso il sistema di PKI mette a disposizione una funzione di ricerca dei

certificati (ad esempio PEM e ICE-TEL) per gli utenti e le CA, tramite servizi di

directory globale od altri meccanismi. Questa funzione ha, nel caso generale,

come input l’entità di cui ricerchiamo un certificato e fornisce come output tutti i

certificati pubblicati per quell’entità. Se si ha a disposizione questa funzione si

può applicare anche un algoritmo di ricerca del cammino di certificazione con

strategia all'indietro o "backward". Prima si ricerca un certificato per il

destinatario, si vede la CA che lo certifica se è fidata si termina altrimenti si

cerca un certificato per questa CA e si prosegue, nel peggiore dei casi ci si arresta

alla radice. Si può notare quest’algoritmo è applicabile anche in presenza di

cross_certification.

�� 3.,�FRQ�VWUXWWXUD�GLVWULEXLWD

Prevede la presenza di PKI distinte che a discrezione, secondo accordi

reciprocamente pattuiti, si certificano vicendevolmente. Ogni singola

infrastruttura è gestita autonomamente e può essere strutturata internamente

secondo il modello di fiducia ritenuto più idoneo. Il vantaggio è l’assenza di

un’unica autorità di certificazione radice di cui doversi completamente fidare.

Lo svantaggio è che la struttura che ne deriva non ha più una topologia ben

definita che individui univocamente un cammino di certificazione tra due utenti.

Possibili algoritmi di ricerca del cammino di certificazione sono, in questo

caso, quelli che determinano un cammino in un grafo, citiamo ad esempio lo

Shortest Path [AMO93] con il quale in tempo polinomiale nella dimensione dello

spazio di ricerca (che è formato da tutti i possibili nodi) si ottiene una soluzione.

La ricerca deve essere esaustiva, perché ci possono essere più cammini e bisogna

cercare quello più breve, spesso si rinuncia a questo tipo di ricerca perché ha

complessità esponenziale e ci ferma al primo cammino trovato.

In assenza di informazioni si può applicare solo una strategia forward con

ricerca in ampiezza in quanto la ricerca in profondità potrebbe generare

facilmente dei loop. L’algoritmo partirà dalla CA del mittente cercherà tra tutti i

certificati da essa pubblicati quello del destinatario, se lo trova si fermerà,

altrimenti lo cercherà nelle CA di cui ha trovato un certificato; proseguirà così in

avanti finché non lo troverà oppure avrà esaminato tutte le CA certificate.

Se il sistema di PKI mette a disposizione una funzione di ricerca dei

certificati (ad esempio ICE-TEL) per gli utenti e le CA, tramite servizi di

directory globale od altri meccanismi, si può applicare anche un algoritmo di

ricerca del cammino di certificazione con strategia backward. Prima si ricercano

tutti i certificati per il destinatario, si vedono le CA che lo certificano, se almeno

una è fidata si termina, altrimenti si cercano tutti i certificati per queste CA e si

prosegue finché o si trova un certificato firmato da una CA di fiducia oppure non

si hanno a disposizione più certificati da verificare. Quest’algoritmo è usato da

ICE-TEL [YCC96].

�� &RQIURQWR�WUD�OH�GXH�RUJDQL]]D]LRQL�GL�3.,

L'adozione di un particolare modello organizzativo delle infrastrutture a

chiave pubblica influenza il processo di individuazione di un cammino di

certificazione e ne determina i tempi di recupero.

La struttura distribuita è quella più penalizzata perché, proprio per le sue

peculiari caratteristiche, richiede un processo di ricerca non ben definito,

variabile a secondo delle informazioni reperite durante l'esecuzione. La durata

della ricerca non quindi è prevedibile e potrebbe essere inaccettabile.

I due modelli organizzativi di PKI visti sono i casi estremi, esistono varie

realizzazioni intermedie in cui si cerca di mediare tra l’esigenza di una struttura

efficiente e una struttura sicura ed indipendente. Gli algoritmi di ricerca dei

cammini di certificazione in questi casi risultano modifiche degli algoritmi

proposti per i due modelli, nei quali si cerca di sfruttare le informazioni sulla

struttura organizzativa delle PKI. Un esempio è il modello semplificato di ICE-

TEL in cui la cross_certification non può essere transitiva e quindi la ricerca di

un cammino di certificazione si può interrompere in presenza di due

cross_certification.

95

�� 6LVWHPD�&OLHQW�6HUYHU��L�SURWRFROOL�/'$3�H�2&63

Tutte le informazioni necessarie alla ricerca e convalida di un cammino di

certificazione possono essere richieste ai Directory Server attraverso il protocollo

LDAP basato sul classico modello cliente-servitore; le motivazioni della scelta di

questo protocollo e il modo di utilizzarlo per recuperare certificati e CRL sono

indicato in [RFC2559].

L’applicazione utente che si occupa del recupero e della convalida dei

certificati elettronici dovrà aprire una connessione con il Directory Server

effettuare una richiesta LDAP, attendere la risposta, analizzarla e di conseguenza

interrogare un altro sistema di directory se il certificato non è stato trovato, o

passare alla fase di convalida nel caso il certificato sia stato recuperato.

Il processo di convalida di un certificato elettronico comporta a sua volta

una connessione con il Directory Server dell'autorità di certificazione che ha

pubblicato il certificato per recuperare la lista di revoca CRL. In alternativa la

convalida del certifica comporta una connessione con il server on-line OCSP

dell'autorità di certificazione competente per richiedere direttamente lo stato di

revoca del certificato.

�� 8Q�VLVWHPD�DG�DJHQWL�PRELOL�SHU�OD�ULFHUFD�H�FRQYDOLGD�GHLFHUWLILFDWL

�� 0RWLYD]LRQL

La nostra idea è quella di utilizzare il modello di comunicazione ad agenti

mobili, in modo da elaborare in locale le informazioni che man mano vengono

raccolte senza dover ritornare ogni volte al sito d'origine.

Le richieste LDAP dovranno comunque essere effettuate, in quanto

rappresentano l'unico accesso ai servizi di directory, ma la loro esecuzione

avverrà localmente nel sito della directory stessa in cui precedentemente un

agente si sarà portato.

L'esecuzione locale porterà ad una riduzione del tempo di elaborazione

della query. Anche l'utilizzo della rete di comunicazione diminuirà, infatti,

l'agente si sposterà solo una volta per eseguire una singola richiesta, mentre

l’esecuzione in remoto della query richiede prima la trasmissione della richiesta e

dopo la notifica della risposta.

Inoltre l'uso degli agenti mobili rende più flessibile il processo di ricerca

vista la loro capacità di elaborazione e la possibilità di generare dinamicamente

altri agenti. Grazie proprio a quest'ultima possibilità il modello ad agenti mobili

permette di realizzare la ricerca in maniera più efficiente rispetto all'uso del

classico modello cliente-servitore, utilizzando più agenti che lavorano in

parallelo per recuperare le informazioni richieste.

�� $UFKLWHWWXUD

Vediamo un possibile sistema per la ricerca e la convalida di un cammino

di certificazione che sfrutti il paradigma ad agenti mobili.

)LJ��: Architettura del sistema

97

La figura mostra come il sistema sia organizzato per componenti

interagenti. Ogni componente è un agente. Gli agenti possono essere statici (GL

VHUYL]LR) o mobili (GL� ULFHUFD). Gli agenti di servizio stazionano in un place e

sono in grado di svolgere un particolare compito. Gli agenti di ricerca sono in

grado di spostarsi di place in place (ed eventualmente di dominio in dominio),

interagendo con gli agenti di servizio per portare a termine i propri obiettivi.

�� $JHQWL�GL�VHUYL]LR�H�VHUYL]L�UHDOL]]DWL

Gli agenti di servizio consentono l’accesso a specifiche funzionalità

rintracciabili nel place in cui sono situati. Ad esempio gli $JHQWL� 5LVRUVD

consentono di accedere alle informazioni contenute in una particolare directory.

Vediamo brevemente quali sono gli agenti di servizio del sistema:

• $JHQWH�5LVRUVD��consente di accedere al servizio di directory e al servizio

OCSP, estrapolandone le informazioni che interessano. Nasconde

completamente la struttura, l’organizzazione fisica e i metodi di accesso ai

dati.

• $JHQWH� 5HSRVLWRU\�� un repository memorizza e consente di individuare

oggetti di varia natura, utili ai vari componenti del sistema. Tutti gli agenti

possono inserire e recuperare oggetti dal repository.

�� 8WLOL]]R�GHL�YDUL�DJHQWL

L’ DSSOLFD]LRQH crea un DJHQWH� ULFHUFD che si può muovere tra i diversi

place e domini e può generare altri agenti ricerca.

L’agente ricerca inserisce sull’DJHQWH�UHSRVLWRU\ tutti i certificati delle CA

che andrà a visitare direttamente o tramite i suoi figli.Nell’agente repository si memorizzano tutti i certificati delle CA in

esplorazione, in modo da non esplorarle più di una volta. Un DJHQWH� ULFHUFD

prima di esplorare una nuova CA verifica che non ci sia nessun certificato ad

essa associata nel repository.

Si può pensare ad un unico agente repository, ubicato in un particolare

place, od a più di uno, replicati in maniera opportuna anche in ogni place.

�� 7HFQLFD�GL�ULFHUFD�H�FRQYDOLGD�GHO�FDPPLQR�GL�FHUWLILFD]LRQH

Illustriamo gli algoritmi utilizzando i classici interlocutori, noti in

letteratura, Alice e Bob. Alice non dispone della chiave pubblica di Bob e, per

poter comunicare in sicurezza con lui, ha bisogno di un cammino di

certificazione che li leghi.

Gli algoritmi sono descritti con riferimento al sistema ad agenti mobili,

visto precedentemente. Tratteremo separatamente i due modelli organizzativi di

PKI.

��3.,�FRQ�VWUXWWXUD�JHUDUFKLFD

In una struttura gerarchica stretta Alice possiede la chiave pubblica della

radice della organizzazione di PKI a cui appartiene.

L’applicazione principale genera un agente di ricerca inviandolo nel place

dove risiede la directory della root ed aspetta il ritorno da parte dello stesso

agente o di un suo discendente. L’agente di ricerca una volta arrivato nel place di

destinazione (quello della root), controlla se tra i certificati contenuti nella

directory c'è quello di Bob; se lo trova richiede al rispettivo server OCSP lo stato

corrente del certificato. Ricevuta una risposta firmata l'agente ritorna con

successo al place d'origine di Alice riportando con sé il certificato di Bob e la

risposta firmata che ne indichi lo stato di revoca.

Nel caso il certificato di Bob non è presente nella directory della root

l'agente dovrà continuerà la ricerca nelle subordinate CA per ottenere il

certificato elettronico di Bob. Per avere disponibile un cammino di certificazione

che garantisca l'autenticità del certificato di Bob, l'agente recupera, sempre dalla

stessa directory della root, tutti i certificati relativi a subordinate CA. Per ognuno

di questi richiede lo stato di revoca al server OCSP e per ciascun certificato

valido genera un nuovo agente di ricerca che invia nel place dove è situata la

directory della CA cui il certificato è riferito (in realtà viene creato un agente in

meno, perché in un place si porterà lo stesso agente genitore).

Ad ogni agente è associato il rispettivo certificato pubblicato dalla root e

la relativa risposta OCSP firmata, in modo da aver disponibile alla fine tutta la

catena di certificazione.

99

Questi agenti controlleranno nelle rispettive directory di destinazione la

presenza del certificato di Bob se uno di essi lo trova allora verifica la sua

validità attraverso una richiesta OCSP al server competente ed lo ingloba al suo

interno (insieme alla risposta firmata) e ritorna al place di Alice dove porterà con

se l’intero cammino di certificazione e le risposte firmate che ne assicurano

l'autenticità. Inoltre comunica a tutti gli altri agenti di ricerca collegati di

concludere la loro esecuzione.

Nel caso in cui il certificato di Bob non viene trovato, si procede

similmente con la generazione di nuovi agenti di ricerca per le CA subordinate di

cui si è ottenuto un certificato.

Data la struttura strettamente gerarchica il processo terminerà

correttamente o con il ritrovamento del certificato di Bob oppure con fallimento

quando non ci sono più CA subordinate da esplorare.

��*HVWLRQH�GHOOLQVXFFHVVR

Per comunicare il fallimento della ricerca è necessario che, quando un

agente di ricerca conclude la sua esplorazione senza trovare il certificato di Bob o

certificati relativi ad altre CA, comunichi il suo stato negativo di non trovato

all’agente che lo ha generato. Analogamente un agente di ricerca che non ha

trovato il certificato di Bob, ma ha recuperato dei certificati relativi ad altre CA

generando per ognuno di essi dei nuovi agenti e ricevuto da ognuno di loro

risposta negativa, dovrà comunicare il suo stato di non trovato all’agente

genitore.

L’ultimo agente a terminare l’esecuzione sarà l’agente di ricerca partito

dal place di Alice che lo comunicherà all’applicazione utente iniziale.


Una struttura distribuita non ha una topologia ben definita che individui

univocamente un cammino di certificazione tra due utenti.

Utilizzando una procedura di ricerca simile al caso dell’organizzazione

gerarchica c’è il rischio di controllare più volte una stessa CA, ed alcuni agenti di

ricerca potrebbero entrare in pericolosi loop. Nel caso la ricerca si conclude con

successo questi loop generati comportano solo uno spreco di risorse, ma nel caso

di insuccesso questi loop non faranno terminare il processo di ricerca. Da qui

l’impossibilità di usare un algoritmo simile al caso gerarchico.

Per ovviare al problema della generazione di pericolosi loop si può

pensare di mantenere una lista delle CA già controllate in modo che un agente

prima di effettuare una ricerca su una data CA vede se non sia già stata

controllata.

A tale scopo può essere utile l’utilizzo di un agente repository dove

depositare gli identificativi (p.e. il nome o un certificato) delle CA che si

andranno a controllare.

Vediamo ora come avviene il processo di ricerca e convalida del cammino

di certificazione.

Alice ha a disposizione sicuramente la chiave pubblica della autorità di

certificazione di cui si fida. L'applicazione principale inserisce nel repository un

identificativo per questa CA, genera un agente di ricerca inviandolo nel place

dove risiede la directory della CA fidata di Alice ed aspetta il ritorno da parte

dello stesso agente o di un suo discendente.

L'agente di ricerca una volta arrivato nel place di destinazione, controlla se

tra i certificati contenuti nella directory c'è quello di Bob; se lo trova richiede al

rispettivo server OCSP lo stato corrente del certificato, ricevuta una risposta

firmata l'agente ritorna con successo al place d'origine di Alice riportando con sé

il certificato di Bob e la risposta firmata che ne attesta lo stato di revoca.

Nel caso il certificato di Bob non è presente nella directory, per avere

disponibile un cammino di certificazione che garantisca l'autenticità del

certificato di Bob, l'agente recupera tutti i certificati relative a CA cross-

certificate, selezionando solo quelli non presenti nel repository. Per ognuno dei

selezionati richiede lo stato di revoca al server OCSP, per ciascun certificato

valido inserisce nel repository un identificativo per la CA cui è riferito, genera un

nuovo agente di ricerca che invia nel place dove è situata la directory della CA

(in realtà viene creato un agente in meno, perché in un place si porterà lo stesso

agente genitore).

Ad ogni agente è associato il rispettivo certificato pubblicato dalla CA di

Alice e la relativa risposta OCSP firmata, in modo da aver disponibile alla fine

tutta la catena di certificazione.

101

Questi agenti controllano nelle rispettive directory di destinazione la

presenza del certificato di Bob se uno di essi lo trova allora verifica la sua

validità attraverso una richiesta OCSP al server competente, lo ingloba al suo

interno (insieme alla risposta firmata) e ritorna al place di Alice dove porterà con

se l’intero cammino di certificazione e le risposte firmate che ne assicurano la

validità. Inoltre comunica a tutti gli altri agenti di ricerca collegati di concludere

la loro esecuzione.

Nel caso in cui il certificato di Bob non viene trovato, si procede

similmente con la generazione di nuovi agenti di ricerca per le CA di cui si è

ottenuto un certificato valido e non sono presenti nel repository.

Grazie proprio all'utilizzo del repository il processo terminerà

correttamente o con il ritrovamento del certificato di Bob oppure con insuccesso

quando non ci sono più CA da esplorare. Per gestire quest'ultima eventualità

vengono adottate le stesse tecniche del caso di struttura gerarchica.

�� &RQYDOLGD�GHO�FDPPLQR�LQ�DVVHQ]D�GHO�VHUYL]LR�2&63

La verifica della validità dei certificati dovrà passare attraverso il controllo

delle relative CRL.

Quando un agente si porta in un place e preleva un certificato che ritiene

utile può controllare subito la sua validità verificando che non sia presente nella

relativa CRL; per far questo l’agente deve avere con sé la chiave pubblica della

CA in cui sta cercando i certificati. Tale chiave è fornita dall’agente genitore, in

quanto è ottenuta nel passo precedente (dalla CA di provenienza sotto forma di

certificato) oppure fornita direttamente da Alice (la chiave della sua CA di

fiducia).

Utilizzando questo metodo di verifica istantanea dei certificati quando

l’agente avrà determinato un cammino di certificazione e lo ritornerà ad Alice si

è sicuri anche della sua validità.

Il problema è che il controllo della firma avviene in un place sconosciuto e

in assenza di garanzie sull’ambiente di esecuzione non si può essere sicuri del

risultato ottenuto e il processo di convalida del cammino di certificazione dovrà

recuperare le CRL associate ai certificati componenti il cammino e portarle nel

place sicuro di Alice, dove potranno essere controllate correttamente al fine di

convalidare il cammino di certificazione trovato.

Le CRL possono essere recuperate dagli agenti direttamente nel processo

di ricerca del cammino copiando al loro interno le CRL associate ad ogni

certificato reperito nei place delle varie CA. In questo modo quando l’agente

troverà il cammino di certificazione avrà con sé anche le CRL corrispondenti e

potrà verificare la validità del cammino una volta ritornato nel place di Alice.

Questo metodo, abbastanza semplice e veloce, ha però il difetto di

appesantire troppo l’agente date le dimensioni non troppo piccole delle CRL.

Un'altra soluzione è di recuperare le CRL solo dopo aver ottenuto un

cammino di certificazione, mandando un agente ad ogni CA che ha pubblicato

almeno un certificato del cammino, a recuperare le rispettive CRL in modo da

poterli verificare. In questo modo si evita che la dimensione dell’agente sia

troppo grande.

��2VVHUYD]LRQL�H�SRVVLELOL�HVWHQVLRQL

In presenza di informazioni aggiuntive su Bob si può semplificare la

ricerca, evitando a priori di visitare le directory associate a CA che non possono

pubblicare certificati per Bob. Per esempio, se conosciamo la nazionalità di Bob,

basterà controllare solo i certificati emessi da CA di quel paese; oppure se

conosciamo a quale organizzazione o gruppo di organizzazioni appartiene Bob

allora si consulteranno solo le directory con i certificati pubblicati da CA che

possono gestire queste organizzazioni, od ancora se conosciamo la CA di Bob

una volta recuperato un certificato per tale autorità non si genereranno altri

agenti, ma ci si porterà direttamente nel relativo place a prelevare il certificato di

Bob. Nel caso più favorevole in cui già si conosce il cammino di certificazione e

bisogna solo recuperare i certificati di cui è composto (p.e. in una struttura

gerarchica Bob può averlo comunicato ad Alice con un messaggio precedente), si

possono mandare degli agenti direttamente nelle directory delle CA interessate a

prelevare i certificati richiesti. L’algoritmo proposto per un’organizzazione

distribuita di PKI è il più generale e può essere applicato anche nel caso di

struttura gerarchica, con una perdita in termini di efficienza rispetto all’algoritmo

specifico, garantendo comunque la completezza e la correttezza della soluzione.

103

&DSLWROR��,03/(0(17$=,21(�(�5,68/7$7,

�� ,QWURGX]LRQH

Nel capitolo precedente abbiamo visto come possa essere realizzato un

sistema per il recupero dei certificati, in particolare abbiamo proposto

un’architettura basata sul modello di comunicazione ad agenti mobili. In questo

capitolo descriveremo l’implementazione del sistema e analizzeremo le sue

prestazioni.

Il processo di costruzione del sistema ad agenti per il recupero e la

convalida dei certificati elettronici si è svolto in diverse fasi distinte. In prima

fase abbiamo individuato un supporto ad Agenti Mobili sul quale realizzare il

sistema. Poi, in seconda fase, ci siamo occupati dell'interfaccia tra il sistema e i

server di Directory, decidendo di utilizzare le JNDI (Java Naming and Directory

Interface) API (Application Programming Interface). Infine, si è passati alla

programmazione dell'applicazione e degli agenti necessari. Una volta realizzato il

sistema si è svolta un'adeguata fase di testing e di analisi delle prestazioni.

�� /D�VFHOWD�GHO�VXSSRUWR

Il supporto ad Agenti Mobili sul quale abbiamo realizzato il nostro sistema

è l'ambiente SOMA descritto nel sesto capitolo. I motivi di tale scelta sono

molteplici: SOMA fornisce tutte le funzionalità di un sistema ad agenti, il codice

è distribuito liberamente [SOMA], è realizzato all'interno del DEIS il

dipartimento dove si è svolta questa tesi e questo ha permesso un continuo

scambio di informazioni con i progettisti di SOMA.

Inoltre SOMA è realizzato interamente tramite il linguaggio JAVA

introdotto nel paragrafo 5.9, gli agenti SOMA possono così utilizzare anche tutte

le funzionalità offerte da Java.

�� /LQWHUIDFFLD�WUD�LO�VLVWHPD�H�L�VHUYL]L�GL�'LUHFWRU\

Il linguaggio JAVA rende disponibile un API per l’accesso ai servizi di

Directory che prende il nome di JNDI (Java Naming and Directory Interface)

[JNDI].

Questa interfaccia è di basso livello e costituisce la base per la costruzione

di semplici applicazioni o interfacce di livello superiore che realizzano una

maggiore astrazione.

Le JNDI API sono indipendenti dal particolar tipo di servizio di directory

usato come LDAP, NDS o NIS. L'utilizzatore accede alle diverse directory in

maniera trasparente, sarà compito dell'interfaccia, attraverso appositi driver,

tradurre le chiamate JNDI standard nelle chiamate specifiche richieste per il

particolare server di directory.

Un'applicazione che usa le JNDI API potrà essere utilizzata per accedere a

diversi directory server, secondo la filosofia JAVA "write once, run anywhere";

l'applicazione rimane sempre la stessa e sono i driver a cambiare.

E' importante notare che un applicazione realizzata con JNDI potrà essere

utilizzata non solo con i servizi di directory attualmente disponibili, ma anche

con i futuri; basterà, infatti, che il produttore del nuovo directory server renda

disponibile un driver JNDI.

Le case produttrici di servizi di directory possono realizzare facilmente

questi driver JNDI attraverso l'utilizzo delle JNDI SPI (Service Provider

Interface).

L'importanza di avere un'interfaccia comune di accesso è stata recepita dai

maggiori produttori di directory server, come Netscape, Novell e Sun, che

forniscono i driver JNDI per tutti i loro sistemi.

�� ,O�VLVWHPD�SHU�LO�UHFXSHUR�H�OD�FRQYDOLGD�GHL�FHUWLILFDWL�DG$JHQWL�0RELOL

Il sistema si basa sull'architettura di fig. 7.1 descritta nel paragrafo 7.5. Il

recupero e la convalida dei certificati elettronici avviene attraverso la tecnica

proposta nel paragrafo 7.6.

105

Riportiamo di seguito i diagrammi di flusso del comportamento

dell’applicazione e dell’agente ricerca, distinguendo tra i due modelli

organizzativi di PKI e assumendo la presenza del servizio OCSP.

�� 3.,�FRQ�VWUXWWXUD�JHUDUFKLFD

L’applicazione utente principale genera il primo DJHQWH�ULFHUFD che inizia

il processo di recupero a partire dalla directory della root, come indicato in figura

8.1.

)LJ��: Diagramma di flusso dell’applicazione nel caso di organizzazione gerarchica delle PKI

L'applicazione resterà in attesa del ritorno di un agente, l'utente però in

questa fase si può scollegare dalla rete risparmiando sui costi di connessione;

quando si ricollegherà, raccoglierà e verificherà il risultato ottenuto dall'agente

ricerca. Questo è un altro dei vantaggi dell'utilizzo degli agenti mobili.

Le variabili 1),*/, e $*(17(,'3$'5( sono interne all'agente ricerca

ed indicano rispettivamente il numero di agenti figli creati e l'identificativo

dell'agente ricerca genitore, quest'ultima variabile per l'agente ricerca generato

direttamente dall'applicazione assume il valore di zero.

L'agente di ricerca una volta arrivato nel place di destinazione, controlla se

tra i certificati contenuti nella directory c'è quello di Bob; se lo trova richiede al

rispettivo server OCSP lo stato corrente del certificato. Ricevuta una risposta

firmata l'agente ritorna con successo al place d'origine di Alice riportando con sé

il certificato di Bob e la risposta firmata che ne indichi lo stato di revoca.

)LJ��: Diagramma di flusso del comportamento dell’agente ricerca una volta arrivato nel place di destinazione nel caso organizzazione gerarchica delle PKI

107

Nel caso il certificato di Bob non è presente nella directory l'agente dovrà

continuerà la ricerca nelle subordinate CA per ottenere il certificato elettronico di

Bob. Per avere disponibile un cammino di certificazione che garantisca

l'autenticità del certificato di Bob, l'agente recupera, sempre dalla stessa

directory, tutti i certificati relativi a subordinate CA. Per ognuno di questi

richiede lo stato di revoca al server OCSP e per ciascun certificato valido genera

un nuovo agente di ricerca che invia nel place dove è situata la directory della

CA cui il certificato è riferito; nell'ultimo place individuato si porterà lo stesso

agente genitore. Lo schema di principio è indicato nelle figure 8.2 e 8.3.

Per gestire correttamente il processo di recupero dei certificati elettronici

l'agente ricerca deve memorizzarsi gli identificativi degli agenti ricerca da lui

generati.

)LJ��: Diagrammi di flusso di procedure necessarie al corretto funzionamento dell’agente ricerca


Nel caso di organizzazione distribuita delle PKI vengono utilizzati gli

DJHQWL�UHSRVLWRU\, nei quali come indicato nel paragrafo 7.6.2 si inseriscono gli

identificativi delle CA che man mano si esplorano.

L’applicazione utente principale, come indicata in figura 8.4, inserisce

nell’DJHQWH�UHSRVLWRU\ un identificativo per la prima CA che si andrà a visitare e

genera il primo DJHQWH�ULFHUFD che inizia il processo di recupero a partire dalla

directory di questa CA. L'applicazione resterà in attesa del ritorno di un agente.

Le variabili 1),*/, e $*(17(,'3$'5( hanno lo stesso significato del caso di

organizzazione gerarchica delle PKI.

Come indicato in figura 8.5, l'agente di ricerca una volta arrivato nel place

di destinazione, controlla se tra i certificati contenuti nella directory c'è quello di

Bob; se lo trova richiede al rispettivo server OCSP lo stato corrente del

certificato, ricevuta una risposta firmata l'agente ritorna con successo al place

d'origine di Alice riportando con sé il certificato di Bob e la risposta firmata che

ne attesta lo stato di revoca.

109

)LJ��: Diagramma di flusso dell’applicazione nel caso di organizzazione distribuita delle PKI

Nel caso il certificato di Bob non è presente nella directory, per avere

disponibile un cammino di certificazione che garantisca l'autenticità del

certificato di Bob, l'agente recupera tutti i certificati relative a CA cross-

certificate, selezionando solo quelli non presenti nel repository. Per ognuno dei

selezionati richiede lo stato di revoca al server OCSP, per ciascun certificato

valido inserisce nel repository un identificativo per la CA cui è riferito, genera un

nuovo agente di ricerca che invia nel place dove è situata la directory della CA;

nell'ultimo place individuato si porterà lo stesso agente genitore. Lo schema di

funzionamento è indicato in figura 8.5.

Le procedure RITROVATO, FINISCI ESECUZIONE e RISULTATO

RICERCA sono le stesse del caso di organizzazione gerarchica delle PKI,

indicate in figura 8.3.

)LJ��: Diagramma di flusso del comportamento dell’agente ricerca una voltaarrivato nel place di destinazione nel caso organizzazione distribuita delle PKI

111

Nella realizzazione del sistema si è assunto che tutte le Autorità di

Certificazione coinvolte pubblicano i certificati elettronici secondo lo standard

X.509 v3. In particolare, come indicato in [RFC2459 pag.40 e pag32], per ogni

certificato elettronico riportano nell'estensione Private Internet Extensions

l'indirizo IP del server OCSP dove richiedere lo stato di revoca; inoltre per i

certificati elettronici relativi a CA riportano nell'estensione Subject Alternative

Name l'indirizzo LDAP della directory dove la CA pubblica i suoi certificati.

�� /D�VLFXUH]]D�GHJOL�DJHQWL�ULFHUFD

Gli agenti ricerca possono essere sottoposti ad attacchi passivi ed attivi6

nella rete di comunicazione e nei place di esecuzione.

Le informazioni trasportate dall'agente (certificati elettronici e stati di

revoca) sono pubbliche e quindi la protezione da attacchi passivi, può essere

trascurata.

La protezione dagli attacchi attivi deve, invece, essere considerata;

analizziamo separatamente i rischi possibili a seconda in cui il pericolo proviene

dalla rete di trasmissione o dai place di esecuzione.

�� 3URWH]LRQH�VXOOD�UHWH�GL�FRPXQLFD]LRQH

Tutte le informazioni reperite nei vari place (certificati elettronici e stati di

revoca) sono firmate dalla CA responsabile e quindi ogni possibile alterazione

viene individuata all'atto del controllo della firma. Inoltre in SOMA è garantita

l'integrità dell'agente nello spostamento.

�� 3URWH]LRQH�QHL�SODFH�GL�HVHFX]LRQH

Qualora le informazioni reperite nei vari place vengono alterate dopo che

la relativa CA li ha firmati allora il problema viene individuato in fase di verifica

della firma.

6 Si definisce attacco passivo un attacco con cui un intrusore intercetta semplicemente un flusso diinformazioni, senza apportare alcun genere di modifiche; con un attacco attivo, invece, l’intrusoreintroduce alterazioni al flusso di dati che possono comprendere modifica del contenuto informativo,eliminazione di tutto o solo di alcune parti del messaggio o trattenimento del messaggio per poi replicarloin tempi successivi.

Allorché l'alterazione viene effettuata prima della firma della CA o la

stessa CA fornisce delle informazioni sbagliate è impossibile accorgersi del

problema, bisogna comunque notare che è la CA firmataria a prendersi la

responsabilità di quest'errore.

�� /H�YDULDELOL�LQWHUQH

Le variabili NFIGLI, AGENTEIDPADRE e AGENTEIDFIGLIO sono

necessarie al corretto funzionamento del processo di ricerca ed una loro possibile

alterazione o cancellazione può non far terminare correttamente il processo di

ricerca.

E' importante osservare che se il processo di ricerca termina con

insuccesso questo potrebbe essere dovuto ad un decremento o cancellazione

fraudolenta della variabile NFIGLI, viceversa se il processo di ricerca termina

con successo siamo sicuri del risultato anche in presenza di manomissioni delle

variabili interne.

Una modifica delle variabili interne può portare, in caso di successo, ad

una mancata eliminazione di agenti ricerca non più utili, ma non influenza il

risultato della ricerca.

Garantire l'integrità delle variabili interne è, comunque, auspicabile.

Attualmente non è previsto nessun tipo di protezione per queste variabili e ci si

affida completamente ai meccanismi di sicurezza di SOMA.

�� ,�WHVW�GHOODSSOLFD]LRQH�H�ODQDOLVL�GHOOH�SUHVWD]LRQL

Per verificare la bontà del nostro progetto abbiamo effettuato alcune

sessioni di test, per comprendere le reali prestazioni del sistema realizzato.

Per prima cosa ci siamo dovuti costruire un ambiente per le prove.

All'interno del Centro di Calcolo (CCIB) e del LAB2 della Facoltà di Ingegneria

si sono installate diverse e distinte Infrastrutture a chiave pubblica (PKI) per

simulare un'organizzazione multipla di PKI.

L'organizzazione di PKI costruita può essere vista come una struttura

gerarchica di PKI con radice la PKI1 e le altre subordinate in sequenza.

113

L'applicazione test scelta è stata quindi quella per organizzazioni gerarchiche di

PKI.

Il servizio OCSP non era disponibile ed è stato per questo simulato

attraverso un server che ad ogni richiesta fornisce una risposta secondo il formato

nel draft OCSP [RFC2560].

)LJ��: Organizzazione delle PKI, realizzata per la fase di test

Per valutare meglio l'efficienza del sistema progettato abbiamo realizzato

altre tre applicazioni di confronto:

• Un sistema client-server che effettua le stesse operazioni della nostra

applicazione, ma invece di richiedere le informazioni alle PKI tramite

Agenti Mobili, effettua delle richieste remote LDAP o OCSP.

• Un sistema ad Agenti Mobili che non effettua delle richieste OCSP,

ma recupera la relativa lista di revoca CRL di ogni certificato utile.

• Un sistema client-server che recupera le liste di revoca CRL e non

effettua richieste OCSP.

L'ambiente di prova descritto in figura 8.6 è così configurato:

♦ la postazione di Alice, da dove partirà l'esecuzione dell'applicazione, è

su un PC Pentium 133 Mhz dotato di 32 Mb di RAM;

♦ la PKI1 è installata su un PC Pentium II 233 Mhz dotato di 128 Mb di

RAM;

♦ la PKI2 è installata su un PC Pentium II 233 Mhz con 64 Mb di RAM;

PKI1 PKI2 PKI3 PKI4

♦ la PKI3 è installata su un PC Pentium II 233 Mhz dotato di 128 Mb di

RAM;

♦ la PKI4 è installata su un PC Pentium II 233 Mhz con 64 Mb di RAM;

Tutti i PC sono connessi mediante una LAN di tipo Ethernet a 10

Mbit/sec. Il supporto ad agenti mobili SOMA è stato configurato su tutti i PC

definendo per ognuno un place di esecuzione.

Il certificato di Bob è stato inserito inizialmente nella PKI1 si sono

effettuati i test delle quattro applicazioni e raccolti i risultati; poi si è eliminato il

certificato di Bob dalla PKI1 ed inserito nella PKI2 misurando le prestazioni

delle diverse applicazioni in questa situazione; successivamente si è spostato il

certificato di Bob nella PKI3 testando nuovamente le quattro applicazioni; infine

si è spostato il certificato di Bob nella PKI4 misurando le nuove prestazioni delle

diverse applicazioni. Come ultima situazione di test per le quattro applicazioni

non si è inserito il certificato di Bob in nessuna PKI simulando il caso in cui il

certificato di Bob non è presente e quindi non può essere recuperato.

Si è voluto in questo modo verificare le prestazioni dell'applicazione al

variare delle PKI visitate.

I risultati ottenuti dalle diverse applicazioni test sono riportati in tabella

8.1. Le misure indicano i tempi medi di recupero del certificato di Bob per

ciascuna delle quattro applicazioni al variare delle PKI visitate.

Da una prima analisi dei risultati osserviamo che tutti i tempi di recupero

per qualunque applicazione sono dell'ordine delle decine di secondi, quindi tempi

accettabilissimi per un utente umano. Questo dimostra l'effettiva bontà degli

algoritmi di ricerca utilizzati indipendentemente dal modello di comunicazione

adottato o dai servizi disponibili.

Riportando i risultati su di un grafico, possiamo osservare l'andamento dei

tempi di recupero al variare del numero di PKI visitate, per ciascuna applicazione

test.

115

Tempi di risposta in secondi

Certificato di BobPresente nella:

Applicazionead AgentiMobili conserver OCSP

ApplicazioneClient Servercon serverOCSP

AgentiMobili inassenza delserver OCSP

Client Serverin assenza delserver OCSP

PKI1 1,532 7,111 1,663 7,581

PKI2 2,674 9,183 2,874 9,664

PKI3 3,665 11,496 4,176 12,67

PKI4 4,696 13,798 5,496 15,824Non presentein nessuna PKI 4,607 12,234 4,987 13,966

7DE��: Risultati delle prove effettuate

)LJ��: Grafici dei tempi di esecuzione in funzione del numero di PKI coinvolte nella ricerca

Tali grafici mostrano come le soluzioni di tipo client-server abbia sempre

prestazioni nettamente inferiori rispetto a quella ad agenti mobili. Si può notare

come la pendenza delle rette nei casi client-server sia molto più accentuata

rispetto alle applicazioni ad Agenti Mobili. Ciò significa che le soluzioni client-

�

�

��

�

��

��

��

��

� � � �

1XPHUR�3.,�YLVLWDWH

7HP

SR��VH

F�

$JHQWL�0RELOLFRQ�2&63

&OLHQW�6HUYHUFRQ�2&63

$JHQWL�0RELOLVHQ]D�2&63

&OLHQW�6HUYHUVHQ]D�2&63

server sono molto dipendenti dal numero di PKI visitate, mentre quelle ad Agenti

Mobili ne dipendono in maniera più limitata.

In generale la presenza del server OCSP migliora le prestazioni del

sistema ed è quindi auspicabile un suo utilizzo, rispetto alle tradizionali CRL.

In conclusione l'applicazione che ha le migliori prestazioni è quella ad

Agenti Mobili che sfrutta i server OCSP.

117

&DSLWROR��&21&/86,21,

Il recupero e la convalida dei certificati elettronici rappresenta una delle

procedure più complesse nella progettazione e gestione di una infrastruttura a

chiave pubblica (PKI) su larga scala. Il problema è particolarmente evidente

quando gli interlocutori appartengono a domini di sicurezza differenti collegati

da un ampio cammino di certificazione. Occorre, quindi, disporre di un

meccanismo efficace per costruire e verificare cammini di certificazione in tempi

accettabili.

L’obiettivo principale di questa tesi è stato, pertanto quello di studiare,

progettare e realizzare delle soluzioni efficienti per costruire e convalidare

cammini di certificazione. In particolare, si è evidenziata l'utilità del modello di

esecuzione ad Agenti Mobili per il recupero e la verifica dei certificati elettronici

in ambienti distribuiti su scala globale. Le capacità degli agenti di interagire ed

elaborare le informazioni localmente alle risorse stesse riduce l'utilizzo della rete

rispetto alla soluzione classica basata sul modello client/server comportando una

diminuzione dei tempi di trasferimento e quindi di recupero e verifica dei

certificati.

Si è pertanto realizzato un’applicazione basata sugli agenti mobili per il

recupero di certificati e la si è confrontata in termini di efficienza con un’analoga

applicazione progettata sulla base del classico modello client/server per

confrontare. La realizzazione di entrambe le applicazioni, ad agenti e basata sul

modello client/server, ha esplorato la possibilità di utilizzare per la verifica dello

stato di revoca dei certificati sia le tradizionali liste di revoca (CRL) sia il

servizio di verifica on-line (OCSP).

I risultati sperimentali hanno mostrato che il modello ad agenti mobili è il

più efficiente ed hanno confermato l’utilità degli agenti per la ricerca e la

convalida dei cammini di certificazione. Inoltre i risultati hanno evidenziato che

l’utilizzo del servizio on-line di verifica comporta un incremento delle

prestazioni dell’applicazione ad agenti mobili. I vantaggi sono dovuti alle

dimensioni ridotte delle risposte OCSP rispetto alle CRL che determinano una

diminuzione dei tempi di trasferimento.

Il lavoro iniziato con questa tesi può essere esteso in varie direzioni. Un

primo possibile e importante sviluppo del nostro sistema potrebbe essere

rappresentato dall'introduzione della verifica della firma sui certificati all'atto del

loro reperimento e non più solo dall'utente finale. Questa estensione, tuttavia,

richiederebbe all'agente mobile di portare con sé le chiavi pubbliche di verifica e

gli algoritmi di controllo e questo sarebbe possibile solo se l'ambiente di

esecuzione dove avviene la verifica della firma fosse sicuro e fidato. Altre

eventuali estensioni derivano dalla possibilità di definire politiche di recupero dei

certificati a livello utente e dall'introduzione di un servizio di cache dove

memorizzare i cammini di certificazione più richiesti o parte di essi.

119

$SSHQGLFH��$&&(662�$�',5(&725<�(/,1*8$**,2�-$9$��-1',�

I servizi di directory vengono sempre di più usati in ambienti come

Internet e Intranet per accedere a informazioni di varia natura come utenti,

applicazioni, hardware, servizi ed altro.

Un linguaggio moderno che intenda proporsi come standard per la

programmazione di rete e la realizzazione di applicazioni per il Web deve quindi

consentire l'accesso ai sistemi di directory.

Il linguaggio Java risponde a questa esigenza e aggiunge alla gerarchia di

classi base una Application Programming Interface (API) per l'accesso ai sistemi

di directory che prende il nome di Java Naming and Directory Interface (JNDI).

L'API ha l'obiettivo di costituire un'interfaccia comune, uniforme e

trasparente per tutti i sistemi di Directory, secondo la ben nota filosofia del

linguaggio Java "write once, run anywhere".

Molti sviluppatori di applicazioni Java potranno beneficiare di JNDI API

che non solo è indipendente dal particolare Directory Server, ma fornisce gli

strumenti necessari per la gestione degli oggetti memorizzati.

L'interfaccia è di basso livello e costituisce la base per la costruzione di

semplici applicazioni o interfacce di livello superiore che realizzano una

maggiore astrazione.

L'indipendenza delle API dal particolare tipo di servizio di directory usato

(come LDAP, NDS o NIS) è dovuta a un gruppo di interfacce Java che vengono

implementate da un driver; questo driver si prende cura di tradurre le chiamate

JNDI standard in chiamate specifiche richieste dal Directory Server che supporta.

L'applicazione viene scritta una sola volta e poi viene inviata ai vari

driver; questo significa che l'applicazione rimane sempre la stessa, mentre sono i

driver a cambiare.

L'architettura base di JNDI è quella mostrata nella figura seguente.

L'indipendenza delle API dal particolare tipo di servizio di directory usato

(come LDAP, NDS o NIS) è dovuta a un gruppo di interfacce Java che vengono

implementate da un driver; questo driver si prende cura di tradurre le chiamate

JNDI standard in chiamate specifiche richieste dal Directory Server che supporta.

L'applicazione viene scritta una sola volta e poi viene inviata ai vari

driver; questo significa che l'applicazione rimane sempre la stessa, mentre sono i

driver a cambiare.

L'implementazione concreta dell'interfaccia si basa proprio su questi

driver specifici per i singoli sistemi di directory che vengono registrati presso il

JNDI Implementation Manager.

E' importante notare che un applicazione realizzata con JNDI potrà essere

utilizzata non solo con i servizi di directory attualmente disponibili, ma anche

con i futuri. Basterà infatti che il produttore del nuovo directory server renda

disponibile un driver JNDI che può realizzare facilmente attraverso le JNDI SPI

(Service Provider Interface).

121

Le JNDI API sono composte da due package:

• MDYD[�QDPLQJ

• MDYD[�QDPLQJ�GLUHFWRU\

Il JNDI Service Provider (SPI) è contenuto nel package:

• MDYD[�QDPLQJ�VSL

Il package MDYD[�QDPLQJ fornisce tutte le funzioni di naming e multiple

naming che consentono di guardare un oggetto a partire dal suo nome. Questo

package è fondamentale in quanto un sistema di directory deve includere al suo

interno delle funzioni di naming per permettere agli utenti di identificare le varie

entità disponibili.

Il package MDYD[�QDPLQJ�VSL fornisce tutti gli strumenti attraverso i quali i

diversi produttori di Naming/Directory Service possono sviluppare e rendere

disponibile i rispettivi driver JNDI. Questo permette ai loro servizi di essere

accessibili dalle applicazioni che usano JNDI, in maniera trasparente.

Il package MDYD[�QDPLQJ�GLUHFWRU\ permette di accedere ai diversi

Directory Service in maniera uniforme. Estende il package MDYD[�QDPLQJ

fornendo tutte le funzioni necessarie per interagire con le directory in aggiunta ai

servizi di naming. Permette alle applicazioni che lo utilizzano di recuperare gli

oggetti memorizzati nelle directory, esaminare e modificare i suoi attributi.

Fornisce funzioni per aggiungere o eliminare oggetti dalla directory e filtri per

ricerche su specifici attributi.

Attraverso l'interfaccia 'LU&RQWH[W si definisce il contesto della directory

necessario all'implementazione concreta.� 'LU&RQWH[W fornisce i metodi per

recuperare, aggiornare, cancellare e aggiungere attributi associati agli oggetti

memorizzati nella directory. In particolare il metodo JHW$WWULEXWHV�� restituisce gli

attributi associati con un oggetto contenuto nella directory.

La ricerca degli oggetti memorizzati è molto semplificata dall'utilizzo del

metodo VHDUFK�� che permette di elaborare da semplici e comuni ricerche base a

sofisticate e multiple ricerche complesse, attraverso l'indicazione di un filtro di

ricerca dove si specificano le caratteristiche che gli oggetti e i loro attributi

devono soddisfare.

L'integrazione tra JNDI e LDAP è totale, gli sviluppatori possono

produrre tutte le query disponibili da LDAP v3 attraverso l'interfaccia JNDI.

Tutte le operazioni LDAP sono mappate in funzioni JNDI, esiste inoltre una

corrispondenza tra le JNDI Exceptions e gli LDAP Status Code.

JNDI fornisce tutti gli strumenti di sicurezza richiesti da LDAP come ad

esempio i metodi di autenticazione.

123

%,%%/,2*5$),$

[AMO93] R.K. Ahuja, T.L. Magnanti, J.B. Orlin, "Network Flows",

Prentice-Hall, Englewood Cliffs, New Jersey, 1993

[AZ98] C. Adams & R. Zuccherato, "A General, Flexible

Approach to Certificate Revocation", Entrust

Technologies, Luglio 1998.

[CDK94] G.Coulouris, J.Dollimore, T.KindBerg, “Distribuited

Systems: Concepts and Design”, Addison-Wesley, 1994.

[CG89] N. Carriego, D. Gelernter: “Linda in Context”,

Comunication of ACM, vol. 32, n°4, April 1989.

[CGPV97] G. Cugola, C. Ghezzi, G.P. Picco, G. Vigna, “Analyzing

Mobile Code Languages”, 1997.

[CHA96] D.W. Chadwick, “Understanding X.500 - The

Directory”,

http://www.salford.ac.uk/its024/VersionWeb/Contents.htm,

1996.

[CHK95] D. Chees, C. Harrison, A. Kershenbaum, “Mobile

Agents: Are They a Good Idea?”, 1995

[Cav99]

[Coc98]

[Chi98]

[CMT79] N. Christofides, A. Mingazzi, P. Toth, C. Sandi, eds.,

"Combinatorial Optimization", Wiley, New York, 1979

[CORBA] R. Orfali and D. Harkey: “Client/Server Programming

with JAVA and CORBA” WileyComputer Publishing,

1997

[CPV97] A. Carzaniga, G.P. Picco, G. Vigna, “Designing

Distributed Applications with Mobile Code Paradigms”,

in Proc. of the 19th Int. Conf. on Software Engineerine

(ICSE’97), R. Taylor, Ed. 1997, pp. 22–32, ACM Press.

[CUR95] I. Curry, "The concept of trust in network security",

Entrust Technologies White Paper, Dicembre 1995.

[DH76] W.Diffie, M. Hellman, "New directions in

cryptography", in IEEE Transactions on Information

Theory, vol. 22 (1976), pp. 644-654, 1976.

[DIR] THE DIRECTORY. CCITT RECOMMENDATION

X.500-X.521 | ISO/IEC STANDARD 9594

X.500 | 9594.Part 1 Overview of Concepts, Models

and Services

X.501 | 9594.Part 2 Models

X.511 | 9594.Part 3 Abstract Service Definition

X.518 | 9594.Part 4 Procedures for Distributed

Operations

X.519 | 9594.Part 5 Protocol Specifications

X.520 | 9594.Part 6 Selected Attribute Types

X.521 | 9594.Part 7 Selected Object Classes

X.509 | 9594.Part 8 Authentication Framework

X.525 | 9594.Part 9 Replication.

125

[F94] W. Ford, "The need for separete key pairs for symmetric

key transfer and digital signature", Febbraio 1994.

[FAQC98] "Frequently asked questions about today’s cryptography",

RSA Laboratories, 1998.

[FPV98] A. Fuggetta, G.P. Picco and G. Vigna “Understanding

Code Mobility”, IEEE Transactions on Software

Engineering, 1998.

[Gong97] Li Gong, M. Mueller, H. Prafullchandra, R. Schemers:

“Going Beyond the Sandbox: An Overview of the New

Security Architecture in the Java Development Kit 1.2”,

in Proceedings of the USENIX Symposium on Internet

Technologies and Systems, Monterey, California,

Dicembre. 1997

[Gong98] Li Gong: “Java Security Architecture (jdk1.2)”, Ottobre

1998

[IBM96] D.B. Lange and Daniel T. Chang, “Programming Mobile

Agents in Java, A White Paper”, Settembre 1996

[KPS95] C. Kaufman, R. Perlman, M. Speciner, “Network

Security, Private Comunication in a Public World”, 1995

[KT98] N.M. Karnik, A.R. Tripathi: “Design Issues in Mobile-

Agent Programming Systems”, IEEE Concurrency, 1998

[LA97] D.B. Lange, Y. Aridor: “Agent Transfer Protocol –

ATP/0.1”, Draft 4, IBM Tokyo Research Laboratory,

Marzo 1997

[LC96] D.B. Lange, D.T. Chang: “IBM Aglets Workbench”,

Draft , IBM Corporation, Settembre 1996

[LDAPv3] D.W.Chadwick, "Internet X.509 Public Key

Infrastructure Operational Protocols - LDAPv3", PKIX

Working Group 'UDIW, Agosto 1999.

[JAVA]

[JNDI]

[MKO98] M. Oshima, G. Karjoth, K. Ono: “Aglets Specification

1.1”, Draft 0.65 , Settembre 1998

[Nie98] O. Nierstrasz, “An Introduction to Java”, Software

Composition Group Institut fur Informatik (IAM)

Universitat Bern, 1998

[OBJ97] “ObjectSpace Voyager Core Package Technical

Overwiew”, ObjectSpace press, Dicembre 1997

[OBJ97a] “Voyager Core Package Thecnical Overwiew”,

ObjectSpace press, Marzo 1997

[OBJ97b] “ObjectSpace Voyager, General Magic Odyssey, IBM

Aglets: a Comparison”, ObjectSpace press, Giugno 1997

[OBJ98] “ObjectSpace Voyager Core Technology 2.0”,

http://www.objectspace.com, 1998

[Odi98] “Introduction to the Odyssey API”, General Magic, 1998.

127

[Pro99]

[RFC1424] B. Kaliski, “ Privacy Enhancement for Internet Electronic

Mail - Part IV: Key Certification and Related Services”,

Request for Comments 1424, Febbraio 1993.

[RFC1777] W. Yeong, T. Howes, S. Kille, "Lightweight Directory

Access Protocol", Request for Comments 1777, Marzo

1995.

[RFC2459] R.Housley, W. Ford, W. Polk, D. Solo, "Internet X.509

Public Key Infrastructure - Certificate and CRL Profile",

Request for Comments 2459, Gennaio 1993.

[RFC2559] S. Boeyen, T. Howes, P. Richard, "Internet X.509 Public

Key Infrastructure Operational Protocols - LDAPv2",

Request for Comments 2559, April 1999.

[RFC2560] M. Myers, R. Ankney, A. Malpani, S. Galperin,

C.Adams, " X.509 Internet Public Key Infrastructure

Online Certificate Status Protocol - OCSP", Request for

Comments 2560, Marzo 1999.

[RFC954] K. Harrestein, M. Stahl, E. Feinler,

"NICNAME/WHOIS", Request for Comments 954,

Ottobre 1985.

[RMI98] “Remote Method Invocation for Java”, Javasoft

Corporation,

http://chatsubo.javasoft.com/current/rmi/index.html, 1998

[RSA78] R. L. Rivest, A. Shamir, L. Adleman, "A method for

obtaining Digital Signature and Public-Key

Cryptosystems", in Communications of the ACM, vol.

21, n.2, pp. 120-126, 1978.

[S96] B. Schneier, "Applied cryptography", John Wiley &

Sons, 1996.

[SOMA] Secure And Open Mobile Agent, Sito web:http://www-lia.deis.unibo.it/Software/SOMA/

[Tar98] F. Tarantino, Tesi di Laurea presso l’Università diBologna, Facoltà di Ingegneria, 1998.

[Ten98] L. Tenti, Tesi di Laurea presso l’Università di

Bologna, Facoltà di Ingegneria, 1998.

[T94] A. S. Tanenbaum “I moderni sistemi operativi”, Prentice

Hall International, Jackson Libri.

[Teles94] Jim White: “Telescript Tecnology: The Fondation for

Electronic Marketplace”, General Magic Inc. Mountain

View (CA), USA, 1994

[WSB98] U.G. Wilhelm, S. Staamann, L. Buttyan: “On the

Problem of Trust in Mobile Agent Systems”,1998

[YCC96] A. Young, N. K. Cicovic, D. Chadwick, “Trust Models in

ICE-TEL”, 1996

,QIUDVWUXWWXUHD&KLDYH3XEEOLFDH ... · 1,1752’8=,21(La sempre maggiore diffusione delle reti di...

Documents

Transcript of ,QIUDVWUXWWXUHD&KLDYH3XEEOLFDH ... · 1,1752’8=,21(La sempre maggiore diffusione delle reti di...