Sicurezza

Il modello di sicurezza di PAST si basa sulle seguenti supposizioni:

1. È computazionalmente impossibile violare il sistema crittograco a chiave pubblica e/o la funzione crittograca di hash usati in PAST;

2. Anche se i client, gli operatori dei nodi o i loro software non sono dati, e attaccanti possono controllare il comportamento di nodi PAST individuali, si suppone che la maggior parte dei nodi PAST si comporti correttamente;

3. Un attaccante non può controllare il comportamento delle smartcard.

Nella trattazione che segue assumeremo l'utilizzo delle smartcard. Come viene spiegato più avanti in questa sezione, è possibile operare una rete PAST senza l'ausilio di smart-card. Ogni nodo PAST ed ogni utente del sistema ha una smartsmart-card. Una coppia (chiave pubblica, chiave privata) è associata a ciascuna smartcard. Ogni chiave pubblica delle smartcard è rmata dalla chiave privata dell'ente rilasciante per questioni di certica-zione. Le smartcard generano e vericano i vari certicati usati durante l'inserimento e di reclamo dello spazio, e mantengono le quote di storage. Di seguito tracceremo le principali funzioni di sicurezza.

2.2.3.1. Generazione dei nodeId

Una smartcard fornisce il nodeId per il nodo PAST che la detiene. Il nodeId si basa su un hash crittograco della chiave pubblica della smartcard. Questa assegnazione probabilistica dei nodeId assicura una copertura uniforme dello spazio dei nodeId e la diversicazione dei nodi con nodeId adiacenti in termini di posizione geograca, ap-partenenza, amministrazione, connettività alla rete, leggi vigenti, ecc. Inoltre, i nodi possono vericare l'autenticità di ciascun nodeId.

2.2.3.2. Generazione dei certicati dei le e delle ricevute di salvataggio

La smartcard dell'utente che vuole inserire un le in PAST rilascia un certicato del le. Il certicato contiene un hash crittograco del contenuto del le (calcolato dal client del nodo), il leId (calcolato dalla smartcard), il fattore di replicazione, il sale, e viene rmato dalla smartcard. Durante un'operazione di inserimento, il certicato del le permette, a ciascun nodo che detiene il le, di vericare (1) che l'utente è autorizzato ad inserire il le nel sistema, il che impedisce ai client di eccedere le loro quote di storage; (2) che il contenuto del le arrivato al nodo che lo deve contenere non sia stato corrotto durante il tragitto dal client da nodi malfunzionanti o malevoli; e, (3) che il leId sia autentico, impedendo l'avvenimento di attacchi di tipo denial-of-service dove client malevoli tentano di esaurire lo storage di un sottoinsieme dei nodi PAST della rete scegliendo leId con valori vicini tra di loro. Ogni nodo di storage, dopo aver salvato con successo una copia del le, rilascia ed invia al client una ricevuta di salvataggio, la

Capitolo 2 Lookup, Routing, e Storage Distribuito quale permette al client di vericare che le k copie del le siano state create su nodi con nodeId adiacenti, il che impedisce ad un nodo malevolo di sopprimere la creazione di k repliche diverse. Durante un'operazione di recupero, il certicato del le viene restituito insieme al le, permettendo così al client di vericarne l'autenticità e l'integrità. 2.2.3.3. Generazione dei certicati e delle ricevute di reclamo

Prima di iniziare un'operazione di reclamo, la smartcard dell'utente genera un certicato di reclamo. Il certicato contiene il leId, viene rmata dalla smartcard e viene inclusa nella richiesta di reclamo che viene inoltrata ai nodi detentori del le. Quando viene elaborata una richiesta di reclamo, la smartcard di un nodo di storage verica prima che la rma nel certicato del reclamo sia coerente con quella nel certicato del le salvato. Questo impedisce che altri utenti al difuori del proprietario del le ne possano richiedere il reclamo dello storage da esso occupato. Se l'operazione di reclamo viene accettata, la smartcard del nodo di storage genera una ricevuta di reclamo. La ricevuta contiene il certicato di reclamo e la quantità di storage reclamata; viene rmata dalla smartcard ed inoltrata al client.

2.2.3.4. Quote di storage

Le smartcard mantengono le quote di storage. La smartcard di ciascun utente viene rilasciata con una quota di utilizzo, in base a quanto storage si vuole concedere all'utente. Quando viene rilasciato il certicato di un le, una quantità pari alla dimensione del le moltiplicata per il fattore di replicazione viene detratta dalla quota. Quando un client presenta una ricevuta di reclamo appropriata, rilasciata da un nodo di storage, la quantità reclamata viene accreditata alla quota del client. Questo previene i client dall'eccedere le proprie quote. La smartcard di un nodo specica la quantità di storage con la quale il nodo contribuisce alla rete (possibilmente anche zero). I nodi vengono controllati casualmente per vedere se possono fornire i le che dovrebbero contenere, scovando così eventuali nodi che cercano di barare orendo meno storage di quello mostrato nella loro smartcard.

2.2.3.5. Integrità del sistema

Sono diverse le condizioni che assicurano l'integrità di base del sistema PAST. Primo, per mantenere un bilanciamento del carico approssimativo tra i nodi di storage, i nodeId ed i leId dovrebbero essere uniformemente distribuiti. La procedura per generare e vericare i nodeId ed i leId ci assicura di questo. Secondo, deve esserci un equilibrio tra la somma di tutte le quote dei client (richiesta) e lo storage totale disponibile (oerta). Il broker assicura il bilanciamento, in linea di principio usando il prezzo monetario dello storage per regolare richiesta e oerta. Terzo, singoli nodi malevoli devono essere incapaci di negare il servizio ad un client in modo persistente. Un protocollo di routing randomizzato, descritto nella sezione 2.1.8 a pagina 24 garantisce che una operazione ripetuta eventualmente verrà instradata aggirando il nodo malevolo.

2.2.3.6. Persistenza

La persistenza dei le in PAST dipende principalmente da tre condizioni. (1) Gli utenti non autorizzati non possono reclamare lo storage di un le, (2) un le viene salvato su k nodi di storage diversi, e (3) c'è suciente diversità nell'insieme dei nodi di storage che detengono un determinato le. Rilasciando e richiedendo certicati di reclamo, le smartcard assicurano la condizione (1). La (2) viene resa possibile dall'utilizzo delle ricevute di storage e la (3) dalla distribuzione quasi-casuale dei nodeId, i quali non

2.2 PAST

possono essere manipolati da un attaccante. La scelta del fattore di replicazione k deve tenere presente la frequenza dei fallimenti dei nodi di storage per assicurare un livello di disponibilità suciente. Nel caso in cui il fallimento di un nodo di storage comporti la perdita di le salvati, il sistema ristabilisce automaticamente k copie come parte della procedura di recupero.

2.2.3.7. Privacy ed integrità dei dati

Gli utenti possono usare la cifratura per proteggere la privacy dei loro dai, usando sistemi di cifratura di loro scelta. Questi sistemi di cifratura non dipendono dalle smartcard. L'integrità dei dati viene assicurata tramite i certicati dei le rilasciati dalle smartcard. 2.2.3.8. Pseudonimia

La rma della smartcard di un utente è l'unica informazione che associa un le salvato o una richiesta all'utente responsabile. L'associazione tra una smartcard e l'identità di un utente è nota solo all'utente, a meno che l'utente divulghi questa informazione volontariamente. La pseudonimia dei nodi di storage viene assicurata in modo simile dato che la rma della smartcard del nodo non viene collegata all'identità dell'operatore del nodo. In più, lo schema di routing di Pastry previene la disseminazione sparsa di informazioni riguardanti le associazioni tra nodeId ed indirizzi IP.

2.2.3.9. Smartcard

L'utilizzo delle smartcard e/o la presenza dei broker come terze parti date non sono fondamentali per l'architettura di PAST. Primo, le smartcard possono essere rimpiazzate da servizi on-line sicuri di quote eseguiti da altri broker. Secondo, è possibile eseguire PAST senza l'ausilio di terze parti. Comunque, data la tecnologia odierna, le smartcard ed i broker risolvono diversi problemi in modo eciente:

1. Le smartcard ed i broker assicurano l'integrità dell'assegnazione dei nodeId ed i leId. Senza una terza parte, sarebbe molto dicile e costoso prevenire gli attaccanti dallo scovare, tramite prove ripetute, leId e nodeId che cadono tra due nodeId adiacenti esistenti in PAST.

2. Le smartcard mantengono le quote di storage in maniera sicura ed eciente. Rag-giungere la stessa scalabilità ed ecienza con un servizio on-line di quote è dici-le. Senza l'ausilio di terze parti, implementare un sistema di quote richiederebbe protocolli di accordo molto complessi.

3. Le smartcard sono un mezzo conveniente tramite il quale un utente può ottenere le credenziali necessarie per unirsi al sistema in maniera anonima. Un utente può ottenere una smartcard con la quota desiderata in maniera anonima senza dover rivelare la propria identità a terze parti.

2.2.3.10. Schema di routing di PAST

PAST si basa su Pastry per il routing e la localizzazione dei le, il cui funzionamento è descritto nella sezione 2.1.4 a pagina 16. Dato un leId, Pastry inoltra il messaggio associato al nodo il cui nodeId sia il più vicino numericamente ai 128 bit più signicativi del leId (ricordiamo che i leId sono lunghi 160 bit). Dato che un le viene salvato su k nodi i cui nodeId sono numericamente vicini ai 128 bit più signicativi del leId, segue che il le può essere ottenuto a meno che tutti e k i nodi falliscano simultaneamente.

Capitolo 2 Lookup, Routing, e Storage Distribuito Dato che Pastry sceglie ripetutamente un passo di routing localmente breve (si veda la sezione 2.1.7.2 a pagina 22), i messaggi tendono a raggiungere per primo uno, dei k nodi contenenti il le desiderato, che si trova vicino al client, secondo la metrica di prossimità, come già discusso nella sezione 2.1.7.3 a pagina 22.