Sistemi di protezione della privacy per il discovery di servizi in ambienti mobili

diventano ancora più rilevanti. I sistemi presenti attualmente in letteratura al-
lo stato dell'arte non considerano il discovery un fase sensibile per la sicurezza
lasciando ai singoli servizi il compito di effettuare un controllo di autorizzazione
sull'utente. In ambienti pervasivi emerge invece la necessità di limitare la visibil-
ità delle informazioni su servizi ed utenti già durante la stessa fase di discovery
per proteggerne la privacy in maniera efficace.
Scopo di questa tesi è la progettazione di un sistema a supporto del discove-
ry di servizi sicuro in ambienti pervasivi. In particolare, il presente lavoro si è
concentrato sul problema di controllare l'accesso alla visibilità stessa dei servizi,
prima ancora che essi vengano acceduti.
Per la progettazione ci si è basati sul framework di discovery semantico MI-
DAS, sviluppato presso il Dipartimento di Elettronica Informatica e Sistemistica
dell'Università di Bologna. Il middleware MIDAS sfrutta le informazioni di con-
testo dell'utente per creare una lista personalizzata dei servizi disponibili, ricavata
sulla base di un matching semantico tra i servizi offerti e le richieste dell'utente.
Nella sua versione iniziale, MIDAS non implementa meccanismi a supporto
della sicurezza di utenti e servizi. Il presente lavoro di tesi ha realizzato una
estensione del sistema esistente, chiamata Secure MIDAS (S-MIDAS), a supporto
del controllo di accesso durante il discovery e della privacy di utenti e fornitori di
servizio.
La tesi è organizzata come segue. Nel capitolo 1 verrà fatta una panorami-
ca sul problema del discovery di servizi e sui sistemi di discovery più importanti
presenti in letteratura. Nel capitolo 2 si affronterà il problema della sicurezza nei
sistemi di discovery e verranno presentati alcuni sistemi presenti in letteratura
allo stato dell'arte che offrono supporto alla sicurezza nella fase di discovery. Nel
capitolo 3 verranno delineati i requisiti e gli obbiettivi del sistema sviluppato nel
presente lavoro di tesi. Dopo aver presentato il sistema MIDAS nella sua prima
versione, il capitolo 4 discuterà l'estensione proposta a supporto della sicurezza
durante il discovery (S-MIDAS). Il capitolo 5 tratterà la fase di progettazione ed
implementazione del prototipo secondo i requisiti emersi dalla fase di analisi e
di design dell'architettura logica esposta. Infine, nel capitolo 6 verranno presen-
tati e discussi i risultati dei test funzionali e dinamici che sono stati eseguiti sul
prototipo.
14
Parte I
Introduzione e stato dell'arte
15

Capitolo 1
Il Discovery di Servizi
In uno scenario globale in cui la diffusione di dispositivi mobili con capacità com-
putazionali sempre maggiori è in crescita costante, il Discovery di Servizi sta as-
sumendo un ruolo sempre più importante spostandosi dall'ambito dei laboratori di
ricerca universitari verso l'utilizzo nella vita di tutti i giorni. Esistono molteplici
definizioni di servizio ma, tra le tante, vale la pena di considerare quella fornita
da [1]:
Un servizio è un'entità software che compie delle azioni per conto
di un'altra entità.
Un servizio è quindi un'entità software fornita da un Service Provider che compie
azioni (basate su degli ingressi) per conto di un Richiedente e fornisce un risul-
tato (uscite). Esempi di servizi possono essere un'applicazione che permette di
controllare l'illuminazione di una stanza, una stampante, un fax e così via. Così
come ci sono al momento migliaia e migliaia di server Web, è lecito aspettarsi che
in futuro il numero di servizi disponibili sia dello stesso ordine di grandezza.
Prima di essere utilizzato, un servizio deve essere trovato. Questo è spesso un
compito difficile per un richiedente. I servizi, infatti, sono distribuiti ed eterogenei,
sono offerti da differenti service provider e utilizzano tecnologie di trasporto e
sistemi operativi differenti. Inoltre servizi simili possono avere differenti proprietà
complicando ulteriormente il compito dell'utente. Il Discovery di Servizi può
quindi essere definito come l'atto di trovare i servizi che soddisfino certi requisiti
specificati dall'utente. Con questo assunto, il problema fondamentale sarà quello
della ricerca (discovery) di quei servizi più appropriati (ad esempio in termini di
costo, locazione, accessibilità, etc.) per effettuare una determinata operazione,
17
tenendo presente che sarebbe desiderabile per un utente il dover intervenire il
meno possibile in modo manuale durante questa fase di ricerca.
Per capire meglio cosa intendiamo con il termine Discovery di Servizi risulta
utile presentare alcuni scenari esemplificativi [2] che evidenziano come la ricerca
di servizi può entrare a far parte della nostra quotidianità:
1. Immaginiamo di trovarci in un taxi e di accorgerci di aver scordato a casa
il portafogli. Fortunatamente siamo in possesso di un terminale di ultima
generazione configurato per il discovery di servizi e navigando tra i servizi
vediamo che la compagnia di taxi offre un servizio di pagamento elettronico
delle tariffe. Scarichiamo quindi sul nostro dispositivo l'applicativo di paga-
mento elettronico ed effettuiamo la transazione. Il sistema di pagamento
della compagnia riconosce che tutto è andato a buon fine e invia alla stam-
pante installata nel taxi la ricevuta. Prendiamo quindi il nostro scontrino e
possiamo andarcene tranquillamente.
2. Consideriamo un rappresentante assicurativo che si reca presso l'ufficio di un
cliente. Egli vuole esporre al cliente gli ultimi prodotti e le relative offerte
della sua compagnia che sono memorizzate sul suo palmare dotato di Win-
dows CE. Poiché il suo palmare è dotato di connettività wireless e supporta
il discovery di servizi, riesce automaticamente a trovare ed utilizzare una
stampante nell'ufficio collegata tramite Ethernet senza alcuna conoscenza o
configurazione preliminare della rete. Può quindi stampare ciò che desidera
in loco ed promuovere i suoi prodotti.
Questi due scenari di esempio sono tratti dai documenti di definizione di due tra i
protocolli esistenti per il Discovery di Servizi (nel seguito SDP, Service Discovery
Protocol). Esistono infatti numerosi SDP, ognuno con le proprie caratteristiche
ed il proprio bacino di utenza: trattano lo stesso identico problema da diversi
punti di vista evidenziando un aspetto piuttosto che un altro ed ognuno ha i suoi
pro ed i suoi contro.
1.1 Funzionalità di un Sistema di Discovery
Prima di entrare nel dettaglio delle specifiche realizzazioni è utile effettuare una
panoramica generale sulle funzionalità che un sistema di discovery deve offire ai
suoi utenti. Sulla base del lavoro presentato in [6] e visibile in figura 1.1 è possibile
18
Figura 1.1: Tassonomia dei sistemi di discovery
individuare alcune caratteristiche comuni dei sistemi di discovery. Una tale clas-
sificazione sistematica che astrae dalla specifica realizzazione aiuta ad analizzare i
vantaggi e gli svantaggi di ogni scelta progettuale adottata in relazione ai sistemi
pervasivi in cui i dispositivi wireless, di diversi tipi e grandezze, costituiscono parte
integrante dell'ambiente in cui sono immersi, ed interagiscono continuamente ed
in maniera trasparente con gli utenti che vi vivono o che lo attraversano.
Nomi di Servizi e Attributi Nel processo di discovery, un utente ricerca un
servizio specificandone il nome e gli attributi. Per fornire espressiv-
ità ed espandibilità per i servizi, molti sistemi di discovery adottano
un sistema di nomi basato su template cioè definiscono un formato
standard per nomi e attributi. Oltre a questo, molti offrono anche la
possibilità di appoggiarsi ad un insieme predefinito di nomi di servizi
e attributi utilizzati più di frequente. In ambito pervasivo, il problema
19
che emerge chiaramente è quello di come far interagire tra loro sistemi
che adottano convenzioni di nomi differenti.
Infrastruttura per il Discovery I modelli utilizzati per l'infrastruttura di
un sistema di discovery sono due e si differenziano per la presen-
za/assenza di una directory. Il modello basato sulla directory ha un
componente dedicato, la directory, che si occupa di mantenere le in-
formazioni sui servizi, gestire gli annunci e le query degli utenti. Il
modello non basato sulla directory non ha alcun componente dedica-
to. Quando arriva una query, ogni servizio la processa e in caso di
match positivo risponde all'utente. Quando un client riceve l'annun-
cio di un servizio lo può memorizzare per usi futuri. Il modello basato
su directory è più adatto a sistemi aziendali con centinaia o migliaia
di servizi in cui una directory risulta essere più efficiente nel proces-
sare le query. Per migliorare l'efficienza alcuni sistemi di discovery
consentono di instaurare una gerarchia di directory. Il modello privo
di directory, invece, si adatta bene ad ambienti domestici con pochi
servizi attivi.
Discovery e Registrazione Client, servizi e directory hanno due opzioni di
base per scambiarsi informazioni di discovery e registrazione. Nell'ap-
proccio basato su annunci le parti interessate si mettono in ascolto su
di un canale e quando un servizio annuncia la sua disponibilità tutte
le parti registrano l'informazione. Nell'approccio basato su query, una
parte riceve una risposta immediata ad una query e non deve proces-
sare gli annunci non correlati. A query differenti che richiedono la
stessa informazione si risponde separatamente.
Informazioni sullo Stato La maggior parte dei sistemi di discovery mantiene
lo stato dei servizi come un soft-state. L'annuncio di un servizio ne
specifica il tempo di vita e prima della scadenza il servizio stesso deve
rinnovare questo contratto (lease) altrimenti il servizio non sarà più
considerato valido. Il modello basato su directory rimuove automati-
camente i servizi scaduti dalla directory. L'approccio basato su hard-
state è meno utilizzato perché richiede un maggior lavoro a client e
directory che devono interrogare periodicamente il servizio per sapere
se è ancora attivo.
20
Scope di Discovery L'individuazione di un'appropriato scope di discovery min-
imizza il carico computazionale di client, servizi e directory. Gli scope
possono basarsi sulla topologia di rete, informazioni di contesto o una
combinazione dei due. Nel caso di scope basati sulla topologia direte
alcuni protocolli adottano la LAN come default mentre altri utilizzano
un hop per le reti wireless. Informazioni contestuali di alto livello come
ad esempio la locazione, l'ora e l'attività dell'utente possono aiutare a
definire uno scope di discovery. Un utilizzo appropriato di informazioni
contestuali semplifica la fase di ricerca di servizi da parte dell'utente.
Basandosi sulla tassonomia dei protocolli di discovery presentata in [6], verranno
ora dettagliati i principali SDP cercando di metterne in luce similitudini e differen-
ze. Se non specificato si fa riferimento a sistemi di discovery di servizi secondo la
definizione data nel primo paragrafo. Alcuni protocolli sono invece più orientati
al discovery di dispositivi: per questi sistemi sarà indicato esplicitamente lo scopo
del discovery.
1.2 Protocolli di Discovery promossi dalla comu-
nità di ricerca
In questa sezione verranno descritti due dei principali protocolli di Discovery
promossi dalla comunità di ricerca internazionale.
1.2.1 Intentional Naming System - INS
Il protocollo Intentional Naming System (INS) è stato sviluppato dal laboratorio
dell'MIT di Computer Science e Intelligenza Artificiale e rappresenta un nuovo
sistema di nomi inteso per nominare ed effettuare il discovery di una molteplicità
di risorse quali dispositivi e servizi [7]. Poiché le applicazioni in ambito distribuito
spesso non sanno dove siano localizzati i servizi che meglio soddisfano il loro
bisogno di informazioni o servizi, INS sfrutta un sistema di nomi Intenzionale in
cui le applicazioni descrivono cosa stanno cercando e non dove trovarlo [8]. In
figura 1.2 è presentato un esempio di nome intenzionale per un servizio pubblico di
fotografie in formato jpg e risoluzione 640x480 localizzato nella sala ovale dell'ala
ovest della Casa Bianca a Washington. I componenti incaricati di risolvere i nomi
nella rete instradano le richieste verso le appropriate destinazioni mantenendo
21
Figura 1.2: Un esempio di nome intenzionale per INS
una corrispondenza tra le descrizioni dei servizi e la loro locazione di rete. INS
ottiene espressività, la capacità di gestire un'ampia varietà di dispositivi e servizi,
utilizzando un linguaggio di nomi intenzionale basato su una gerarchia di valori e
attributi permettendo ai nodi che forniscono un servizio di descrivere precisamente
cosa offrono e dualmente consente ai client che richiedono un servizio di specificare
esattamente ciò di cui hanno bisogno. L'architettura di risoluzione dei nomi di INS
è stata progettata in modo da essere il più possibile indipendente dal linguaggio
in cui vengono formulate le query di ricerca.
Un'importante caratteristica di INS è la sua adattabilità agli ambienti mobili
in cui la locazione di rete (l'indirizzo IP) di un nodo finale può cambiare. Parliamo
di mobilità del nodo quando si ha mobilità fisica di un nodo o quando un nodo
cambia la rete utilizzata per comunicare, ad esempio da rete cablata a rete wireless.
Parliamo di mobilità per un servizio quando il suo indirizzo di rete non cambia,
ma cambia la corrispondenza nodo finale-servizio a causa di un cambiamento nei
valori delle variabili ricercate dai client.
In INS i client usano un nome intenzionale per richiedere un determinato
servizio senza specificare il nodo finale che in pratica serve la richiesta. Grazie a
questo livello di indirezione è possibile per le applicazioni continuare a comunicare
con i servizi anche quando la corrispondenza nome vs. indirizzo del nodo finale
cambia durante la sessione in maniera trasparente per il client.
INS, al contrario di quanto avviene di solito, integra la risoluzione dei nomi
con il routing dei messaggi. In questo modo è possibile ottenere adattabilità nei
confronti della mobilità, delle fluttuazioni delle performance e in generale di tut-
ti quei fattori che ci allontanano dalla configurazione ottimale. Questo sistema
prevede due modalità di base per la consegna dei messaggi: intentional anycast e
intentional multicast. Il primo consente ad un'applicazione di decidere che il mes-
saggio sia consegnato al nodo di servizio ottimale che soddisfa un determinato
nome intenzionale. Il secondo consente di consegnare il messaggio a tutti i nodi di
22
servizio che soddisfano un determinato nome, ad esempio il gruppo di sensori che
hanno rilevato una temperatura sotto lo zero. Con questi due meccanismi INS ot-
tiene anycast e multicast a livello di applicazione. E' importante notare come INS
non vada a modificare in nessun modo l'infrastruttura di routing IP sottostante
ma piuttosto si pone come una overlay network nei confronti dell'unicast di IP,
l'unico servizio cui fa affidamento.
INS utilizza una rete decentralizzata di risolutori per trovare i nomi e instradare
i messaggi. Per facilitare la configurazione, i risolutori di INS si auto-configurano
in una overlay network a livello di applicazione e i client possono collegarsi ad
uno qualunque di essi per risolvere le loro richieste e pubblicizzare servizi. Per
eliminare il bisogno di deregistrare manualmente un servizio, i risolutori utilizzano
soft-state con rinfreschi periodici per trovare i nomi e cancellare quelle entità che
non hanno effettuato il rinfresco.
Figura 1.3: Schema di funzionamento di INS
Nella figura 1.3 è presentata l'architettura di INS. Partendo dall'angolo in alto
a sinistra, un'applicazione invia un nome intenzionale (1) ad un INR (Intentional
Name Resolver, il risolutore) per la risoluzione, riceve la locazione di rete (2) e
invia i dati direttamente all'applicazione (3). A metà a sinistra si ha un client che
utilizza l'intentional anycast: l'applicazione invia un nome intenzionale e i dati ad
un INR che li invia (5) esattamente a una delle destinazione che combaciano con
i parametri selezionati. In basso a sinistra si ha un client che utilizza l'intentional
multicast: l'applicazione invia il nome intenzionale e i dati ad un INR che li
instrada attraverso la rete degli INR verso tutte le applicazioni di destinazione.
Sulla destra viene mostrata un'applicazione che annuncia un servizio con un nome
intenzionale presso un INR. Un applicazione che voglia effettuare un discovery sui
23
nomi invia la richiesta ad un INR (6) che gli restituisce l'insieme dei nomi che
fanno match con la query.
1.2.2 DEAPspace
Il protocollo DEAPspace è stato sviluppato dal gruppo di ricerca di IBM presso
il laboratorio di Zurigo ed è un sistema in cui i servizi possono essere condivisi
con dispositivi nelle vicinanze [9]. L'ambiente applicativo di riferimento per questo
protocollo è un sistema wireless a corto raggio con ampiezza massima di un hop: in
un sistema DEAPspace i dispositivi possono rilevare la presenza di altri dispositivi
nelle vicinanze (rete wireless ad-hoc a singolo hop) e condividere configurazioni e
servizi con questi dispositivi. Grazie a questo sistema i dispositivi che utilizzano
DEAPspace si accorgono di quando altri dispositivi non sono più disponibili e si
riconfigurano dinamicamente in base a questo.
Il primo passo per coordinare i dispositivi è renderli in grado di trovarsi a vi-
cenda [10]. Dopo aver valutato le soluzioni esistenti che si affidano spesso a server
centralizzati per mantenere le liste dei servizi disponibili per i client, il team IBM,
che aveva come obiettivo un ambiente altamente dinamico come le reti ad-hoc,
ha optato per una soluzione con un algoritmo di Discovery decentralizzato. L'al-
goritmo DEAPspace utilizza dei broadcast ad hop singolo di tipo proattivo per
condividere una vista del mondo con tutti i dispositivi nelle vicinanze. In un ap-
proccio distribuito, gli algoritmi di discovery possono essere di due tipi: il modello
push in cui i server inviano notifiche senza essere interrogati e il modello pull in
cui sono i client a iniziare la ricerca. Considerazioni in termini di tempo di rispos-
ta e consumo di energia, molto importante nel caso di dispositivi mobili, hanno
portato il team IBM ad adottare una soluzione di tipo push. In questo modello
è però necessario decidere quando un dispositivo debba emettere un messaggio in
broadcast.
Il broadcast in DEAPspace Per minimizzare i tempi di risposta ed il con-
sumo di energia, tutti i dispositivi sono in gara per aggiudicarsi uno slot di
trasmissione e una volta ottenuto trasmettono la loro intera vista del mondo. In
questo modo gli altri dispositivi che ricevono questa vista possono valutare quanto
sia aggiornata la loro conoscenza e prendere eventuali azioni correttive. I messag-
gi con cui un dispositivo pubblica la propria vista del mondo sono detti Service
24
Advertisement Message (SAM) e i servizi di cui è a conoscenza Service Elements
(SE). Il meccanismo di broadcast segue questo schema [11]:
1. I broadcast sono schedulati per avvenire in determinate finestre temporali,
con un solo nodo che trasmette in ogni finestra.
2. Il nodo che deve effettuare il broadcast è determinato con un algoritmo di
tipo back-off: qualunque sia il dispositivo che seleziona il tempo inferiore
di ritrasmissione sarà quello che potrà effettuarla e coloro che riceveranno il
messaggio dovranno annullare il loro invio e ripetere la schedulazione.
3. I nodi che si accorgono che la propria informazione locale è assente oppure
sta per scadere scelgono un tempo di backoff più corto per la prossima
trasmissione del loro SAM aumentando le probabilità di vincere la gara per
lo slot di trasmissione.
4. Se un nodo riceve un SAM con le sue informazioni locali corrette ed un
ragionevole tempo di vita non ha necessità di trasmettere il suo SAM perché
le informazioni in esso contenute sono già state trasmesse da qualcun'altro.
5. Prima di trasmettere il proprio SAM un nodo reinizializza il tempo di vita
dei suoi servizi locali.
Grazie alla trasmissione di questi SAM, un nodo che entra nel raggio di trasmis-
sione di un gruppo esistente ha bisogno di ricevere un solo SAM per venire a
conoscenza dell'intero insieme di servizi al momento disponibili. Infatti, quando
un nodo riceve un SAM combina la lista dei servizi remoti ricevuti con la lista dei
servizi locali e aggiorna il tempo di vita dei servizi remoti.
Descrizione dei servizi in DEAPspace In DEAPspace, ogni servizio è defini-
to principalmente da un formato di input, un formato di output, un nome e un
indirizzo. Il nome offre un'informazione consistente, concisa e leggibile per con-
sentire ad un utente di discriminare tra servizi simili. I formati delle descrizioni
sono di tipo gerarchico, basati sui tipi MIME e consentono ulteriori affinamenti
in termini di numeri di versione etc. In questo modo è possibile specificare delle
query con un qualunque grado di precisione.
La codifica delle descrizioni dei servizi è molto importante perché è impensabile
che ogni dispositivo sia programmato per capire ogni possibile tipo di servizio che
può incontrare. Per questo motivo le descrizioni dei servizi dovrebbero essere
25
incapsulate. Se viene rilevato un servizio completamente nuovo, la sua presenza
nel SAM non dovrebbe interferire con la decodifica del resto della lista e il ricevente
dovrebbe essere in grado di aggiungerlo alla propria lista in maniera sicura.
1.3 Protocolli di Discovery promossi da aziende
In questa sezione verranno descritti tre dei principali protocolli di Discovery pro-
mossi dalle maggiori aziende del settore dell'informazione: Jini di Sun Microsys-
tems, UPnP di Microsoft e Rendezvous di Apple.
1.3.1 Jini
Jini, sviluppato dalla Sun Microsystems, è un sistema distribuito basato sull'idea
di federare gruppi di utenti e le risorse di cui essi necessitano [12]. Le risorse
possono essere rappresentate da dispositivi hardware, programmi software o una
combinazione dei due e il sistema Jini fornisce tutti i meccanismi necessari per la
costruzione di servizi che possono essere utilizzati da una persona, un dispositivo
o un altro servizio. Esempi di servizi possono essere una stampante, un monitor,
un database, etc.
Il cuore di un sistema Jini è formato da un trio di protocolli chiamati rispet-
tivamente discovery, join e lookup. La coppia Discovery/Join si ha quando
un servizio deve essere aggiunto al sistema:
1. In una prima fase di Discovery il provider del servizio cerca un Servizio di
Lookup presso cui registarsi inviando una richiesta in multicast sulla rete
locale oppure rivolgendosi ad un Servizio di Lookup noto a priori (Figura
1.4).
2. Una volta trovato, il provider del servizio registra, tramite Join, un oggetto
servitore ed i suoi attributi presso il Servizio di Lookup(Figura 1.4).
La fase di lookup si ha quando un utente o un generico client vuole localizzare
e invocare un determinato servizio:
1. Un client richiede un servizio tramite il suo tipo Java e, probabilmente,
anche altri suoi attributi. Una copia dell'oggetto del servizio viene spostata
sul client che la utilizza per comunicare con il servizio stesso (Figura 1.5).
26
Figura 1.4: Fase Discovery/Join di Jini
2. Il client interagisce direttamente con il provider del servizio tramite l'oggetto
di servizio in suo possesso (Figura 1.5).
Figura 1.5: Fase Lookup di Jini
Il Servizio di Lookup Il servizio di lookup in Jini può essere visto come un
servizio di directory nel senso che i servizi vengono cercati e localizzati tramite
esso. In una comunità Jini i servizi registrano i propri oggetti proxy presso il
servizio di lookup tramite il meccanismo discovery/join ed i client interrogano il
servizio di lookup per recuperare il servizio desiderato. Jini sfrutta tre protocolli
di discovery [4], in relazione tra di loro, a seconda delle diverse situazioni opera-
tive. Il Multicast Request Protocol viene utilizzato la prima volta che un servizio
o una applicazione diventano attivi e devono trovare un servizio di lookup nel
vicinato. Il Multicast Announcement Protocol è utilizzato dal servizio di lookup
per annunciare la sua presenza ai potenziali servizi interessati nella comunità.
L'Unicast Discovery Protocol è utilizzato per stabilire la comunicazione con uno
specifico servizio di lookup noto a priori in una Wide Area Network.
Il servizio di lookup di Jini però non è solo un semplice server di nomi bensì
mappa le interfacce Java viste dai client con un insieme di oggetti proxy servi-
tori che saranno scaricati dai client per comunicare direttamente col servizio di
interesse.
27