================================================================================
---------------------[ BFi14-dev - file 06 - 23/09/2007 ]-----------------------
================================================================================


-[ DiSCLAiMER ]-----------------------------------------------------------------
        Tutto il materiale contenuto in BFi ha fini esclusivamente informativi
        ed educativi. Gli autori di BFi non si riterranno in alcun modo
        responsabili per danni perpetrati a cose o persone causati dall'uso
        di codice, programmi, informazioni, tecniche contenuti all'interno
        della rivista.
        BFi e' libero e autonomo mezzo di espressione; come noi autori siamo
        liberi di scrivere BFi, tu sei libero di continuare a leggere oppure
        di fermarti qui. Pertanto, se ti ritieni offeso dai temi trattati
        e/o dal modo in cui lo sono, * interrompi immediatamente la lettura
        e cancella questi file dal tuo computer * . Proseguendo tu, lettore,
        ti assumi ogni genere di responsabilita` per l'uso che farai delle
        informazioni contenute in BFi.
        Si vieta il posting di BFi in newsgroup e la diffusione di *parti*
        della rivista: distribuite BFi nella sua forma integrale ed originale.
--------------------------------------------------------------------------------


-[ MiSCELLANE0US ]--------------------------------------------------------------
---[ SiCUREZZA DEi SiSTEMi P2P PER iL DATA ST0RE DiSTRiBUiT0 ]------------------
-----[ tlei <tlei@s0ftpj.org> & guy montag <gm@nym.borked.net]------------------


Questa e' una review aggiornata dei piu' interessanti sistemi P2P per il data
store distribuito: OceanStore, Mnemosyne, Free Haven e Freenet. Le appendici
sono dedicate a Mixminion e Tor, due tecnologie che non offrono funzionalita'
di storage, ma possono invece essere usate come canali di comunicazione anonima
in sistemi P2P per il data store.
Con la descrizione dei protocolli e degli algoritmi impiegati e l'analisi delle
problematiche legate alla sicurezza si desidera aiutare il lettore a
comprendere questi sistemi affinche' possa in seguito "metterci le mani sopra"
in modo consapevole, modificarli e progettarne di nuovi.
Data la lunghezza del documento, i capitoli sono scritti in modo tale da poter
esser letti anche singolarmente e fuori ordine senza che questo ne pregiudichi
la comprensione.
Grazie a Marco Calamari, Raistlin, smaster, valv0, vecna per commenti, consigli
o anche solo per aver letto la bozza di questo testo.

Questa opera e' pubblicata sotto una Licenza Creative Commons 
Attribution-NonCommercial-ShareAlike. E' possibile ottenere una copia di questa
licenza visitando http://creativecommons.org/licenses/by-nc-sa/2.5/it/ .

Questo file e' disponibile anche in formato PDF all'URL:
http://bfi.s0ftpj.org/dev/BFi14-dev-06.pdf


-[ Indice

1  Introduzione

2  OceanStore
   2.1  Caratteristiche
   2.2  Tapestry
        2.2.1 Analisi vulnerabilita' note
   2.3  Bamboo / OpenDHT 
   2.4  Modello dei dati
        2.4.1 Identificazione e localizzazione
        2.4.2 Accesso ai dati
              2.4.2.1 Permessi di lettura e scrittura
              2.4.2.2 Scrittura ed operazioni sui blocchi cifrati
              2.4.2.3 Aggiornamento distribuito su rete inaffidabile
   2.5  Conclusioni

3  Mnemosyne
   3.1  Steganografia locale a blocchi
   3.2  Steganografia distribuita
   3.3  Considerazioni e vulnerabilita'

4  Free Haven
   4.1  Principi e funzionamento
        4.1.1 Operazioni
              4.1.1.1 Inserimento
              4.1.1.2 Estrazione
              4.1.1.3 Scadenza
              4.1.1.4 Gestione dei nodi
        4.1.2 Dinamicita' della rete
              4.1.2.1 Four-way handshake
   4.2  Anonimato in rete
        4.2.1 La reputazione ed i suoi limiti
   4.3  Vulnerabilita'
        4.3.1 Anonimato
        4.3.2 I nodi ed i loro contenuti
   4.4  Osservazioni

5  Freenet
   5.1  Freenet Light
        5.1.1 Panoramica
        5.1.2 Protezione dei dati: chiavi
              5.1.2.1 Keyword Signed Key (KSK)
              5.1.2.2 Signed-Subspace Key (SSK)
              5.1.2.3 Content Hash Key (CHK)
              5.1.2.4 Osservazioni sulle chiavi
        5.1.3 Anonimato di chi accede ai dati: richieste
        5.1.4 Anonimato di chi pubblica i dati: inserimenti
        5.1.5 Resistenza alla cancellazione da parte di terzi
              5.1.5.1 Politica di gestione dello spazio di storage
              5.1.5.2 Dispersione e replicazione del documento
              5.1.5.3 Plausible deniability per l'operatore del nodo
        5.1.6 Ricerche sui dati
        5.1.7 Vulnerabilita' ed attacchi
              5.1.7.1 Eavesdropping
              5.1.7.2 Man in the Middle
              5.1.7.3 Node discovery
              5.1.7.4 Analisi del traffico
              5.1.7.5 Attacchi al routing
              5.1.7.6 Attacchi DoS
        5.1.8 Conclusioni
   5.2  Freenet Dark
        5.2.1 Referenze
        5.2.2 Routing greedy distribuito in una rete small world
        5.2.3 Data store
        5.2.4 Conclusioni
   5.3  Riepilogo

6  Analisi conclusiva
   6.1  Routing
   6.2  Affidabilita', fiducia ed accountability
        6.2.1 Micropagamenti
        6.2.2 Reputazione
   6.3  Attacchi Sybil ed Eclipse
   6.4  Replicazione dei dati
   6.5  Autenticita', integrita' e segretezza dei dati
   6.6  Tolleranza ai malfunzionamenti
   6.7  Anonimato
   6.8  Differenze ed equilibri: tutti i nodi sono uguali, ma alcuni sono piu'
        uguali degli altri
   6.9  Chaos, ordine e sicurezza

A  Mixminion
   A.1  Evoluzione dei remailer
        A.1.1 Pseudonym remailer
        A.1.2 Cypherpunk remailer - Tipo 1
        A.1.3 Nymserver
        A.1.4 Mixmaster remailer - Tipo 2
        A.1.5 Debolezze principali
   A.2  Mixminion - Tipo 3

B  TOR: The Second-Generation Onion Router 
   B.1  Modello di minaccia
   B.2  Architettura
   B.3  Analisi a basso costo di traffico Tor
   B.4  Localizzazione degli Hidden Server tramite elezione ad ultimo OR
   B.5  Localizzazione degli Hidden Service attraverso il loro Clock Skew
   B.6  Attacchi con limitate risorse al meccanismo di routing preferenziale

Bibliografia


-[ Elenco delle figure

   2.1  Componenti di Tapestry . . . . . . . . . . . . . . . . . . [img2_1.png]
   2.2  Attenuated Bloom Filter  . . . . . . . . . . . . . . . . . [img2_2.png]
   2.3  Un oggetto attivo  . . . . . . . . . . . . . . . . . . . . [img2_3.png]
   2.4  AGUID e VGUID in Pond  . . . . . . . . . . . . . . . . . . [img2_4.png]
   2.5  Creazione ciphertext da memorizzare sul nodo inaffidabile  [img2_5.png]
   2.6  Modifica di un dato cifrato  . . . . . . . . . . . . . . . [img2_6.png]
   2.7  Propagazione di un aggiornamento . . . . . . . . . . . . . [img2_7.png]

   4.1  Four-way handshake . . . . . . . . . . . . . . . . . . . . [img4_1.png]

   5.1  Messaggi in Freenet Light  . . . . . . . . . . . . . . . . [img5_1.png]
   5.2  Schema di generazione di una KSK . . . . . . . . . . . . . [img5_2.png]
   5.3  Schema di generazione di una SSK . . . . . . . . . . . . . [img5_3.png]
   5.4  Schema di generazione di una CHK . . . . . . . . . . . . . [img5_4.png]
   5.5  Routing in Freenet . . . . . . . . . . . . . . . . . . . . [img5_5.png]
   5.6  Grado di anonimato . . . . . . . . . . . . . . . . . . . . [img5_6.png]

   6.1  Modello di micropagamento end-to-end . . . . . . . . . . . [img6_1.png]
   6.2  Modello di micropagamento pairwise . . . . . . . . . . . . [img6_2.png]
   6.3  Modello di micropagamento amortized pairwise . . . . . . . [img6_3.png]
   6.4  Modello di micropagamento all points . . . . . . . . . . . [img6_4.png]
   6.5  Sistema di reputazione a ticket  . . . . . . . . . . . . . [img6_5.png] 
   6.6  Sistema di reputazione decentralizzato . . . . . . . . . . [img6_6.png]
   6.7  Proprieta' concorrenti in un sistema P2P per il data
        store distribuito  . . . . . . . . . . . . . . . . . . . . [img6_7.png]

   A.1  Sequenza cifrature . . . . . . . . . . . . . . . . . . . . [imgA_1.png]
   A.2  Forward message  . . . . . . . . . . . . . . . . . . . . . [imgA_2.png]
   A.3  Direct reply . . . . . . . . . . . . . . . . . . . . . . . [imgA_3.png]
   A.4  Anonymous reply  . . . . . . . . . . . . . . . . . . . . . [imgA_4.png]

   B.1  La rete Tor  . . . . . . . . . . . . . . . . . . . . . . . [imgB_1.png]
   B.2  Raggiungere l'hidden server  . . . . . . . . . . . . . . . [imgB_2.png]
   B.3  Attacco con onion router ostile  . . . . . . . . . . . . . [imgB_3.png]
   B.4  Configurazione per attacchi all'Hidden Server  . . . . . . [imgB_4.png]
   B.5  Costruzione di un circuito Tor . . . . . . . . . . . . . . [imgB_5.png]


-[ Elenco  delle  tabelle

   5.1  Chiavi note ad un nodo
   5.2  Proprieta' dell'anonimato
   5.3  Esempio di dato
   5.4  Anonimato della query
   5.5  Integrita' dei dati
   5.6  Segretezza dei dati
   5.7  Fiducia anonima
   5.8  Anonimato di chi accede o pubblica documenti
   5.9  Negazione plausibile di responsabilita' da parte dell'operatore del
        nodo
   5.10 Resistenza alla cancellazione da parte di terzi
   6.1  Anonimato computazionale e perfect-forwarding nei sistemi P2P esaminati


-[ 1 Introduzione

La popolarita' dei sistemi per il data store distribuito e' cresciuta negli
ultimi anni grazie ai vantaggi che essi promettono rispetto ai tradizionali
data store centralizzati: tolleranza ai guasti, disponibilita', scalabilita' e
performance. Parallelamente si e' registrata una crescente ricerca nella
progettazione e messa in opera di reti peer-to-peer: a partire da servizi di
comunicazione esistenti esse definiscono un livello di rete sovrapposto
(overlay network) che realizza un servizio distribuito mediante la condivisione
delle risorse (logiche e fisiche) di calcolatori (nodi paritetici).
  L'architettura P2P rappresenta un'attraente soluzione per implementare data
store distribuiti grazie alle sue caratteristiche di decentralizzazione dei
dati e del piano di controllo, di ridondanza, di adattabilita', di capacita' di
organizzarsi autonomamente e di basso costo di gestione [1].

  Se da un lato i sistemi P2P offrono indubbi vantaggi rispetto al
tradizionale modello client-server, dall'altro pongono nuove sfide nell'ambito
della sicurezza. Reti P2P dove non sia limitato il numero di identita' che un
nodo puo' assumere contemporaneamente nell'overlay network e dove i peer
possano unirsi e lasciare la rete in modo arbitrario devono far fronte a due
attacchi di carattere generico [2]:

o Sybil attack.
  L'attaccante genera identita' multiple associate al proprio nodo fisico; il
  numero delle identita' possibili e' limitato solo dalle risorse del nodo. In
  questo modo l'attaccante con la sua entita' puo' arrivare a controllare
  porzioni significative della rete P2P. L'obiettivo del sybil attack e'
  sovvertire il meccanismo di ridondanza e decentralizzazione della rete P2P.

o Eclipse attack.
  In un'estensione dell'attacco precede, l'attaccante giunge a controllare gran
  parte dei nodi adiacenti al nodo vittima. I nodi ostili dell'attaccante
  cooperano per ingannare il nodo legittimo e indurlo a inserirli nella sua
  tabella di routing e considerarli suoi vicini (neighbour). Quando il numero
  di nodi ostili supera un certo limite rispetto alla quantita' di nodi vicini
  legittimi, di fatto i nodi ostili eclissano le comunicazioni tra il nodo
  vittima e gli altri nodi legittimi e a questo punto possono sovvertire il
  meccanismo di routing del nodo vittima, proporgli una visione della topologia
  di rete differente da quella reale ed agire per indurlo a cancellare o
  sostituire file dal data store distribuito.

  Le reti P2P per il data store distribuito possono essere vulnerabili ad altri
attacchi legati allo specifico protocollo di comunicazione impiegato ed ai
servizi forniti; per questo motivo e' opportuno condurre un'analisi di
sicurezza separatamente per ognuna di esse.
  Il paradigma P2P applicato ai sistemi di data store distribuito consente
anche di offrire pubblicazione e ritiro anonimo dei dati dal data store.
L'anonimato dell'utente (e quindi del suo nodo) e' preservato quando non e'
possibile identificare quale utente (nodo) della rete ha effettuato
l'operazione.
  L'anonimato non e' una condizione raggiungibile in un contesto centralizzato
e non distribuito, dal momento che e' sempre relativo ad un anonymity set, in
questo caso l'insieme degli utenti (nodi) che fanno parte della rete P2P; agli
occhi dell'attaccante appaiono in modo equiprobabile coinvolti nella
transazione di interesse. In generale l'aumento della dimensione dell'anonymity
set implica un rafforzamento dell'anonimato.
  Il concetto di anonimato di un sistema per il data store include i seguenti
aspetti:

o Forward anonymity: non e' possibile identificare e localizzare il mittente
  della comunicazione.

o Reverse/backward anonymity: non e' possibile identificare e localizzare il
  destinatario della comunicazione.

o Plausible deniability: chi ospita i dati e' messo in condizione di negare in
  modo plausibile la propria responsabilita' sui contenuti.

  La sfida piu' difficile da vincere per i sistemi anonimi e' posta
dall'analisi del traffico (traffic analysis). L'analisi del traffico consiste
nell'estrarre e correlare informazioni dai metadati della rete, inclusi i
volumi e le tempistiche dei pacchetti di rete, cosi' come gli indirizzi di rete
visibili da cui sono originati o ai quali sono destinati. Nel caso delle
comunicazioni anonime, un avversario userebbe questi dati per condurre
un'analisi del traffico allo scopo di tracciare chi e' l'origine o la
destinazione ultima di una connessione, in modo da violare le proprieta' di
anonimato che il sistema e' progettato per offrire.

  I concetti finora esposti sono propedeutici alla comprensione delle sezioni
successive di questo documento, dove verranno ripresi ed approfonditi.
L'analisi dei sistemi P2P per il data store distribuito proposta vertera' sulle
funzioni di protezione dei file (intergrita', autenticita', segretezza),
eventuali garanzie di forward e reverse anonymity e plausible deniability,
possibilita' di eseguire ricerche sui dati, vulnerabilita' note/individuate e
relativi attacchi possibili. Gli attacchi alle componenti crittografiche
esulano dagli obiettivi di questo documento e pertanto non saranno trattati
[3] [4].
  Il capitolo 2 presenta le caratteristiche, le componenti e la sicurezza di
OceanStore, un sistema P2P per il data store distribuito a livello globale; la
sua attenzione si concentra sulla persistenza dei dati in una rete basata su
nodi inaffidabili. OceanStore si basa su algoritmi di hash distribuiti (DHT),
quali Tapestry e Bamboo DHT.
  Nel capitolo 3 e' descritto un altro data store distribuito, Mnemosyne;
anch'esso si basa su Tapestry ed offre interessanti funzionalita'
steganografiche.
  Il capitolo 4 illustra il progetto Free Haven, un ambizioso studio di una
rete anonima P2P per lo storage distribuito di contenuti sensibili, che ha
prodotto due fra le maggiori tecnologie per la comunicazione anonima,
esaminate in appendice.
  Il capitolo 5 e' dedicato ad un'ampia trattazione ed analisi di sicurezza del
progetto Freenet che costituisce lo stato dell'arte per quanto riguarda i
sistemi anonimi P2P per il data store ed e' la rete di questo tipo che gode
della piu' ampia base di utenti.
  A partire dallo studio degli specifici software P2P per il data store
distribuito, nel capitolo 6 si propongono considerazioni di carattere generale
su elementi e proprieta' che influiscono sulla sicurezza di questa tipologia di
sistemi e dovrebbero essere tenute presenti in fase di progetto. In questa
analisi conclusiva i temi trattati includono routing, affidabilita', fiducia,
accountability, replicazione dei dati, resilienza ai guasti, usability ed
anonimato.
  L'appendice approfondisce due tecnologie di comunicazione anonima che possono
essere impiegate in sistemi P2P per il data store distribuito per ottenere
proprieta' di anonimato:

o Mixminion: un protocollo per le comunicazioni anonime ad elevata latenza,
  concepito per lo scambio anonimo di messaggi di posta elettronica ed
  utilizzabile come canale anonimo per altri applicativi.

o Tor: applicazione di rete che rappresenta lo stato dell'arte per quanto
  riguarda la comunicazione anonima a bassa latenza.


-[ 2 OceanStore

Ideato nel 2000 presso l'University of California di Berkeley, OceanStore [5]
[6] vuole essere un'infrastruttura di rete distribuita a livello globale per
offrire accesso controllato a generici dati persistenti. Questo storage di
rete, utilizzando ridondanza e tecniche crittografiche, si colloca su server
distribuiti inaffidabili; i dati possono essere ospitati ovunque sulla rete ed
essere presenti con un numero arbitrario di copie, risolvendo i problemi
prestazionali tramite caching.
  OceanStore e' progettato per essere un livello di rete stabile, relativamente
performante e sicura, poggiato su una rete instabile; tuttavia il suo sviluppo
non e' ancora concluso. Dal 2002 e' testato presso PlanetLab [7], un insieme
globale di nodi per la ricerca nel campo delle reti; nel gennaio 2006 i nodi
virtuali utilizzati da OceanStore erano 642. E' principalmente portato avanti
da John Kubiatowicz che ne ha assegnato lo sviluppo a vari studenti. Su licenza
BSD e' liberamente disponibile un prototipo di nome Pond [8], scritto in Java,
che raccoglie i meccanismi di OceanStore.

  Per quanto riguarda l'instradamento e la distribuzione dei blocchi di dati,
OceanStore storicamente si basa su Tapestry, un meccanismo di hash distribuito
(DHT - Distributed Hash Table) molto efficiente, che permette una rapida
localizzazione dei blocchi di dati richiesti, anche in caso di malfunzionamenti
di rete. Tapestry e' stato sviluppato in gran parte dagli sviluppatori di
OceanStore, fra cui spicca Ben Zhao. Anch'esso e' quindi un software nato a
Berkeley, ed e' utilizzato come base per diversi progetti di infrastrutture
distribuite. Il suo sviluppo si e' fermato alla release 2.0, in quanto
soppiantato nel 2004 da Chimera [9], una riscrittura sotto forma di libreria C
che ne ha raccolto l'eredita'. Dal 2006 il meccanismo di instradamento e di
localizzazione in OceanStore e' affidato a Bamboo, un progetto di Berkeley
ancora in fase di sperimentazione, sviluppato da Sean Rhea, uno dei progettisti
di OceanStore. E' attualmente integrato nel codice di Pond, avendo entrambi la
stessa licenza; il pacchetto si puo' ottenere tramite CVS da SourceForge [10].


--[ 2.1 Caratteristiche

Secondo il team di OceanStore, le premesse ad un sistema distribuito di
dimensioni globali che gestisca dati persistenti sono le seguenti:

o connessioni veloci sempre disponibili, quindi non di tipo on-demand;
o la rete non e' fidata, ed i nodi della rete possono essere ostili;
o i nodi della rete possono fallire oppure entrare e uscire a piacere dalla
  rete.

  Inoltre gli obiettivi principali sono:

o persistenza dei dati;
o cifratura delle connessioni;
o autenticazione degli utenti;
o elevate prestazioni.

  Tutto questo con l'idea di poter gestire una rete composta da 10 miliardi di
persone con 10 mila file immessi da ognuna.

  L'indipendenza della rete rispetto al comportamento dei nodi e' una premessa
necessaria per l'affidabilita' di una rete globale, in quanto poggia su server
e connessioni preesistenti. Questa infrastruttura pre-esistente non e' fidata
in quanto possono esistere nodi della rete malevoli. Tuttavia per poter
funzionare i client che si collegano alla rete devono conoscere una classe di
server sicuramente fidati a cui trasmettere i dati. Ma si deve anche assumere
che gran parte dei server lavorino correttamente, a causa della gestione
distribuita della consistenza basata sull'algoritmo Byzantine Agreement
Protocol. Quest'algoritmo permette di essere ragionevolmente certi della
corretezza di un messaggio ricevuto che ha attraversato vari nodi; per ogni
aggiornamento interno alla rete avviene infatti un controllo di consistenza con
gli altri nodi, onde evitare di accettare informazioni generate da un nodo
ostile. Dall'algoritmo risulta che il numero massimo tollerabile di nodi
disonesti e' M su un totale di N = 3 * M + 1 nodi; risulta quindi che per
funzionare correttamente il numero di nodi malevoli M e': M < (N - 1) / 3.
  Il numero piu' piccolo di nodi per funzionare e' quindi 4, con 1 nodo
disonesto; se infatti vi siano soltanto 3 nodi, A, B e C, con A disonesto che
informa B e C con istruzioni differenti, durante il loro raffronto ne' B ne' C
possono sapere chi degli altri due e' disonesto. Nel caso in cui siano piu' di
M i nodi disonesti, e' possibile effettuare un Eclipse attack, detto cosi' in
quanto piu' nodi malevoli riescono ad eclissare le informazioni corrette
fornite da un nodo onesto.

  La struttura generale di OceanStore e' una gerarchia di 2 livelli di nodi
peer-to-peer. I client accedono ad uno qualsiasi dei nodi di OceanStore, una
vasta rete di nodi peer-to-peer che memorizzano i dati ed effettuano le
operazioni di instradamento e localizzazione. Alcuni di questi nodi, che
formano il primary tier, sono i punti di riferimento per quando riguarda gli
aggiornamenti ai dati; topologicamente e' una rete di nodi peer centrali alla
rete. Tutti gli altri nodi formato il secondary tier, che possono essere
collegati sia ad uno o piu' nodi del primary tier e a nodi del secondary tier,
sia soltanto a nodi peer del secondary tier. Si forma quindi una rete peer-to-
peer in cui nelle operazioni di scrittura alcuni peer centrali sono piu'
importanti degli altri nodi. Le modifiche vengono infatti validate nel primary
tier e si diffondono nel secondary tier, in entrambi i livelli grazie al
Byzantine Agreement Protocol. I nodi del primary tier devono essere chiaramente
in numero maggiore di 4.

  Per ottenere connessioni veloci in una rete cosi' vasta, e' necessario
implementare meccanismi di caching: la localita' dei dati e' quindi importante,
in quanto si riduce la latenza, si incrementa l'affidabilita' poiche' i dati
fanno meno strada e si riduce la banda complessivamente utilizzata nella rete.
I dati possono essere presenti in cache (queste copie sono detti "replica") su
qualsiasi nodo: la ricerca di un dato presente localmente deve possibilmente
interessare soltanto i nodi locali alla richiesta. Si dice quindi che i dati
sono nomadici: monitoraggi interni al funzionamento della rete scovano
relazioni fra gli oggetti memorizzati e li spostano e duplicano a seconda delle
necessita', in modo del tutto automatico e progressivo.

  Il tipo di memorizzazione offerto mantiene nel tempo ogni versione dei dati
immessi, senza perdere alcun contenuto, poiche' alcune replica per ogni
versione di un contenuto sono statisticamente sempre presenti nella rete:
tecnicamente il sistema si definisce quindi come un version-based archival
storage system. E' possibile a posteriori ricostruire ogni versione del dato
immesso con le successive modifiche; non e' quindi possibile cancellare un
contenuto dopo l'inserimento.
  Alla base di OceanStore vi e' il concetto che l'informazione e' separata
dalla collocazione fisica; per funzionare al meglio i server dovrebbero essere
uniformemente distribuiti sul globo. In tal modo si avrebbe la configurazione
ideale per l'accesso in tempi rapidi da parte dei client.
  Tapestry, ora sostituito da Bamboo, e' integrato con OceanStore ed e'
utilizzato per quanto concerne la localizzazione e l'instradamento degli
oggetti. Il loro utilizzo e' fondamentale per gestire localmente tali funzioni,
a meno che non sia strettamente necessario fare richieste non locali,
sfruttando la localita' nomadica dei dati illustrata precedentemente.
  Per questioni di portabilita', OceanStore, Tapestry e Bamboo si basano su una
JVM (Java Virtual Machine).


--[ 2.2 Tapestry

Tapestry [11] e' un livello avanzato di rete che offre un servizio di routing
efficiente e scalabile per reti peer-to-peer. Esso implementa un'infrastruttura
decentralizzata (e' un DOLR, Decentralized Object Location and Routing [12])
utilizzando una tabella di hash per la localizzazione e l'instradamento degli
oggetti, e quindi e' una DHT (Distributed Hash Table). E' una delle prime
quattro DHT concepite verso il 2000, assieme a CAN, Pastry e Chord, alla base
delle reti peer-to-peer di seconda generazione. Nel suo caso il posizionamento
delle risorse tiene conto del percorso utilizzato per raggiungerlo: questa
caratteristica di fondo permette ad OceanStore di ottenere la localita' degli
oggetti cercati.
    
  Figura 2.1: Schema delle componenti di Tapestry e loro interazioni con la
              rete e OceanStore.

  E' concepito per adattarsi a reti IP in cui sia i nodi che i link siano
inaffidabili. Puo' utilizzare sia TCP che UDP; il vantaggio ben noto di TCP e'
l'implicito controllo di flusso e anti-congestionamento, mentre come contro ha
i lunghi tempi di apertura e chiusura dei flussi. Il livello UDP, essendone
privo, viene fornito assieme ad un controllo di congestione simile al TCP. La
preferenza di un protocollo rispetto all'altro si limita di solito a
considerazioni sulle prestazioni, in quanto l'utilizzo del TCP utilizza piu'
file descriptor rispetto ad UDP.

  Vengono di seguito elencate le principali componenti logiche di Tapestry:

o Core router
  Utilizza il routing e una tabella di indici agli oggetti per gestire
  l'inoltro di messaggi. La ricerca effettuata puo' essere di due tipi:

  - ricerca di oggetti, che ha complessita' O(1) se tutte le referenze sono
    contenute in memoria;
  - ricerca di nodi, che ha complessita' O(logN) e si appoggia su un algoritmo
    di ricerca veloce chiamato Bloom Filter.

    Bloom Filter [13] e' un algoritmo probabilistico per verificare rapidamente
    l'appartenenza di un elemento ad un vasto insieme di valori (set),
    utilizzando h differenti funzioni di hash su un un vettore di bit
    identificativo dell'elemento.
    Nel caso di Tapestry si utilizza un versione semplificata e applicabile
    all'ambito distribuito, l'Attenuated Bloom Filter (ABF). Esso utilizza un
    solo algoritmo di hash per la ricerca di un elemento. ABF e' una
    rappresentazione approssimativa di un gruppo di elementi, che oltre a
    determinare l'assenza di un elemento molto velocemente, puo' lavorare per
    passi successivi su diversi set di elementi.
    In Tapestry l'algoritmo gestisce elementi identificati da vettori v lunghi
    160 bit non ordinati, ovvero gli identificativi di un oggetto (GUID)
    generati con un hash SHA-1.
    E' approssimativa in quanto puo' generare falsi positivi, ma mai falsi
    negativi. E' quindi possibile che un elemento venga individuato su un nodo
    benche' non presente, ma non capita mai che un elemento non venga trovato
    anche se presente; il numero statistico di questi falsi positivi e'
    inversamente proporzionale con il numero v di bit utilizzati per
    rappresentare l'elemento.
    E' veloce in quanto localmente il tempo per calcolare l'appartenenza di un
    elemento al set non dipende dal numero di elementi del set, ma e' costante
    e dipende dalla lunghezza dell'hash; per cui ben si applica ad un sistema
    peer-to-peer con un elevato numero di oggetti.
    Il suo funzionamento e' distribuito poiche' permette, oltre a verificare
    l'appartenenza dell'elemento al set locale, di passare la richiesta al
    nodo vicino piu' indicato, proprio grazie all'hash dell'elemento cercato.
    Ogni volta che si vuole localizzare un elemento si parte da un punto a
    caso della rete e si confronta l'hash attuale con gli elementi vicini,
    spostandosi sull'elemento che ha piu' bit in comune con il nostro hash.
    
      Figura 2.2: Funzionamento dell'Attenuated Bloom Filter in Tapestry.

    In figura 2.2 e' raffigurato il funzionamento in Tapestry dell'Attenuated
    Bloom Filter con v = 5. Esso prevede che ogni nodo mantenga un numero di
    oggetti il cui hash corrisponde, solo con i bit posti ad uno, con il
    valore identificativo del nodo stesso. La ricerca (cosi' come
    l'inserimento) dell'oggetto il cui hash ha posto ad uno i bit 0, 1 e 3
    (ovvero 11*1*) parte casualmente dal nodo a. Dopo aver verificato che i
    bit del valore del nodo a (11100) non soddisfano il Bloom Filter locale,
    si confronta con la tabella dei nodi adiacenti, contenente per ogni valore
    dei nodi adiacenti, l'OR logico dei nodi vicini di secondo grado; nello
    schema l'unico nodo adiacente e' b, con valore 11100, a cui corrisponde il
    pattern 11011. Il nodo b non puo' soddisfare i bit richesti; tuttavia il
    pattern del suo vicinato si'. La richiesta giunge quindi a b, che scopre
    nella sua tabella che il valore del nodo c (11010) soddisfa il
    Bloom Filter; per cui la richiesta arriva a c, che verifica se
    effettivamente contiene nei suoi oggetti locali quello il cui hash ha i
    bit 0, 1 e 3 posti ad uno.
    Il suo utilizzo in Tapestry e' decisivo poiche' la verifica avviene in
    parte su differenti nodi; a livello globale tutti i riferimenti non stanno
    certo in memoria principale. Inoltre siccome la maggior parte dei percorsi
    di routing riceve risultati negativi, e' molto probabile che bastino pochi
    passi per identificare la sequenza di bit corretta.
    Si noti infine che l'identificativo di un oggetto corrisponde anche
    all'informazione sulla sua locazione; inoltre nel caso reale di OceanStore
    puo' convenire iniziare la ricerca dai nodi del primary tier, poiche' sono
    piu' centrali.

o Node membership component
  E' responsabile dell'integrazione dei nuovi nodi e dell'uscita volontaria
  dei nodi.

o Mesh repair
  E' responsabile dell'adattamento delle connessioni Tapestry a seconda dei
  cambiamenti della rete, nel caso di collegamenti interrotti oppure nel caso
  di nodi malfunzionanti.

o Patchwork
  Monitora le informazioni sulla latenza e sulle perdite dei canali di
  comunicazioni.

  Ad ogni nodo Tapestry viene assegnato un NodeID pseudo-casuale composto da
160 bit generati tramite SHA-1, espresso sotto forma di stringa esadecimale da
40 caratteri. Il meccanismo di instradamento dei messaggi e' detto Mesh
Routing, poiche' ogni nodo utilizza direttamente i NodeID dei nodi vicini per
raggiungere la meta. Infatti dato un nodo da raggiungere, il messaggio e'
trasmesso da ogni nodo al vicino con il NodeID piu' simile, utilizzando un
algoritmo che ad ogni nodo incrementa il suffisso di una stringa inizialmente
di 1 carattere. La ricerca su una rete con N NodeID esadecimali casualmente
distribuiti e' dell'ordine di log16 N; se alla fine della ricerca il nodo non
viene trovato, il messaggio rimane sul nodo con il NodeID piu' simile, che puo'
quindi appropriarsene.


---[ 2.2.1 Analisi vulnerabilita' note

  Tipicamente questi framework peer-to-peer per il routing sono vulnerabili ad
un noto tipo di attacco, il Sybil attack [14], in cui si costruiscono ad-hoc
molte identita' per un nodo. Infatti questi sistemi per resistere alle
informazioni errate di un nodo malizioso utilizzano ridondanza; tuttavia, se un
nodo raccoglie un gran numero di identita' puo' tentare collisioni, poiche'
controlla una parte sostanziosa del sistema, insidiando il meccanismo di
ridondanza.
  Tapestry limita questi tipi di attacchi in quanto si basa su una
infrastruttura fidata a chiave pubblica (PKI ) per assegnare alle identita'
degli ID univoci, che sono quindi certificati. Per una discussione piu'
approfondita sul Sybil attack ed una valutazione dell'efficacia della soluzione
basata su PKI, si faccia riferimento alla sezione 6.3 del capitolo 6.
  Al fine di garantire il corretto funzionamento del Mesh Repair, per limitare
i possibili danni causati da qualche nodo compromesso o malfunzionante, i nodi
di Tapestry possono lavorare appaiati scambiandosi messaggi attraverso i nodi
adiacenti per verificare i percorsi.
 Il software di Tapestry e' implementato a livelli, permettendo cosi' di
analizzare solo l'header dei messaggi ricevuti da trasmettere ad altri nodi.
Questo evita di copiare il messaggio completo in memoria (byte copying) e
quindi evita il passaggio dei dati trasportati (appartenenti ad OceanStore in
questo caso) alla memoria riservata a Java, che puo' essere sotto osservazione
da parte di un processo malevolo.


--[ 2.3 Bamboo / OpenDHT

OpenDHT [15] [16] e' una rete sperimentale che espone un servizio DHT,
utilizzando il software Bamboo [17] [18] [19]; in effetti OpenDHT serve anche
al testing e allo sviluppo di Bamboo. Bamboo e' implementato in Java
ispirandosi in parte ai protocolli di Pastry; il suo meccanismo di interazione
fra i nodi e' del tutto nuovo. Rispetto ai DHT di generazione precedente offre
prestazioni e scalabilita' migliori, soprattutto in applicazioni in cui vi sono
notevoli e continui ingressi ed uscite di nodi dalla rete; tutto questo
cercando di limitare al massimo la banda occupata dalle comunicazioni del
sistema.
  Il servizio OpenDHT espone un'interfaccia standard ad un DHT pubblica e senza
limiti di accesso, grazie alle tecnologie SunRPC e XML-RPC. E' possibile
immettere ed estrarre chiavi senza dover installare un DHT; questo e' utile
allo sviluppo di reti distribuite che vogliano appoggiarsi a tale servizio
senza reimplementare un DHT. Il progetto e' incubato presso il PlanetLab, di
cui utilizza circa 200 nodi.
  Bamboo e' implementato in Java strutturato utilizzando una macchina a stati
fornita dal framework SEDA (Staged Event-Driven Architecture); il codice e'
quindi organizzato con code di eventi di una macchina real-time.
  Le funzionalita' fornite ad OceanStore sono le stesse di Tapestry, ovvero
routing, ricerca, inserimento ed estrazione di chiavi; anche qui il routing
utilizza un meccanismo ricorsivo durante la ricerca di chiavi. Esso si basa
come Tapestry su chiavi date da hash SHA-1 a 160 bit.
  Essendo in fase di testing, alcuni dettagli sono ancora poco chiari,
soprattutto gli aspetti riguardanti la sicurezza, che e' proprio l'ambito di
sviluppo attuale. Alcuni problemi di sicurezza presenti al momento sono per
esempio la possibilita' di effettuare una serie di insermenti su un nodo
Bamboo, provocando l'esaurimento del suo spazio di memorizzazione, causando
cosi' un Denial of Service (DoS). Un altro tipo di DoS e' un attacco costruito
in modo tale che un nodo di Bamboo rediriga molte richieste verso un terzo nodo
obiettivo.


--[ 2.4 Modello dei dati

L'unita' fondamentale per la memorizzazione di informazioni in OceanStore e'
l'oggetto: sono oggetti copie aggiornabili di dati (dette replica) e copie
archiviate di blocchi di dati. Gli oggetti si trovano quindi in due forme dette
attiva e archiviata.
  Nella forma attiva vi e' l'ultima versione dell'oggetto, con i necessari
puntatori per l'aggiornamento; l'oggetto contiene infatti una copia dell'ultima
versione archiviata, i cambiamenti non ancora resi noti, i permessi di accesso
e i metadati necessari. La forma attiva si trova presso i nodi dove viene
utilizzata piu' spesso: queste copie prendono il nome di floating replica; per
riunire le modifiche ai vari blocchi e ridistribuire le forme attive e
archiviate vengono impiegati i primary replica, alcune copie attive di
riferimento.
  Un oggetto di tipo archiviato e' una rappresentazione in sola lettura che
viene sparsa su centinaia o migliaia di nodi; in caso di gravi errori o perdita
dei replica, dalle varie versioni delle forme archiviate si dovrebbe sempre
poter ricostruire i dati.
  Il sistema con i due livelli di replica e le forme archiviate viene chiamato
dagli sviluppatori deep archival storage, poiche' fornisce una ridondanza di
ogni versione degli oggetti, raggiungendo un buon compromesso con lo spazio
utilizzato. Sono state fatte delle analisi statistiche a riguardo: ipotizzando
di avere m frammenti archiviati e n copie, l'aumento di spazio necessario e'
n/m. Nel caso si utilizzi 106 nodi in cui il 10% perde i dati, e si replichi i
dati (n/m = 2), otteniamo per 4, 8 e 16 frammenti di un documento:

o m = 4, n = 8: probabilita' di trovare il documento e' 0.99
o m = 8, n = 16: probabilita' di trovare il documento e' 0.99999
o m = 16, n = 32: probabilita' di trovare il documento e' 0.99999... (20000
  nove)


---[ 2.4.1 Identificazione e localizzazione

Un oggetto di OceanStore e' identificato da un GUID (Globally Unique
IDentifier); e' una stringa pseudo-casuale con lunghezza in bit fissa, che
viene generata differentemente a seconda che l'oggetto sia in sola lettura
oppure sia attivo. La figura 2.3 illustra la formazione ed il contenuto di un
oggetto attivo.

  Figura 2.3: Un oggetto attivo definito da un GUID e con puntatori ad oggetti
              aggiornati.

  Il GUID di un oggetto in sola lettura e' un hash (si utilizza SHA-1) sui
blocchi di dati che contiene; in questo modo ogni versione di ogni oggetto e'
identificato univocamente. Inoltre i client che chiedono un oggetto archiviato
in sola lettura attraverso il suo GUID possono facilmente verificare la sua
correttezza, ricalcolando l'hash.
  Per i replica la questione e' piu' delicata, in quanto e' necessario poterli
trovare dato un nome facile da memorizzare per l'uomo; serve quindi un
meccanismo decentralizzato per assegnare un GUID resistente ad attacchi di
hijacking dei dati da parte di utenti ostili, che vorrebbero distribuire un
dato non autentico con un nome od un GUID autentico. Per evitare il problema,
il GUID viene costruito generando l'hash con SHA-1 della stringa ottenuta
concatenando il nome dell'oggetto (il titolo del blocco di dati) e la chiave
pubblica del proprietario (l'ultimo ad aver modificato questa versione). I nodi
possono quindi verificare l'autore dei dati rapidamente, facilitando il
controllo degli accessi ai dati.
  In OceanStore si possono generare dei percorsi a file utilizzando oggetti che
contengono riferimenti ad altri oggetti; il percorso e' quindi dato da una
successione di GUID. Si noti che in se' questo meccanismo simile ad un
filesystem non ha una radice unica, ma e' l'utente che puo' costruirsene una:
prendendo un oggetto di tipo directory, che contiene riferimenti ad altri
oggetti, e' possibile per un utente utilizzarlo come radice generandone una
propria versione con la propria chiave; da li' in poi ogni nuova directory e'
implicitamente una firma digitale della successiva (self-certifying path [20]).
  Il meccanismo per generare i GUID non assicura la totale infallibilita' della
corrispondenza univoca con gli oggetti, poiche' sposta il problema
sull'algoritmo di hash utilizzato, che per ora, sia in Tapestry che in Bamboo,
e' SHA-1 a 160 bit. OceanStore e' comunque implementato in modo tale da
permettere aggiornamenti futuri sulle funzioni di hashing utilizzate (per
esempio SHA-512).
  I GUID formati con l'hash del nome e della chiave pubblica del proprietario
sono chiamati brevemente AGUID (Active GUID), quelli di un blocco di dati
archiviato BGUID (Block GUID) e quelli del blocco d'origine di una versione
corrente VGUID (Version GUID, e' in verita' un BGUID ma e' il riferimento
presente nel replica).

 Figura 2.4: Relazione tra AGUID e VGUID di un primary replica in Pond. Due
             versioni di un oggetto e loro composizione dai blocchi di dati
             archiviati; il secondo VGUID aggiorna i blocchi d4 e d5.


---[ 2.4.2 Accesso ai dati

Le azioni consentite sugli oggetti sono:

o la memorizzazione di un nuovo dato;
o l'aggiornamento, che crea una nuova versione;
o lettura dell'ultima versione;
o lettura di una versione precedente.

  La memorizzazione e l'aggiornamento non cancellano mai dati preesistenti, ma
generano nuovi oggetti o nuove versioni di oggetti. E' quindi assicurato il
cosiddetto time travel, che permette di analizzare il resoconto di ogni
modifica, in quanto nella versione corrente di un oggetto vi sono i VGUID agli
oggetti archiviati.
  La lettura di un oggetto presuppone l'individuazione dello stesso, che puo'
essere effettuata in due modi: conoscendo gia' l'identificativo e la versione
voluta di un blocco di dati tramite il BGUID o VGUID, oppure facendo una
ricerca sul nome dell'oggetto, ottenendo quindi l'AGUID e l'ultima versione
dell'oggetto, con i collegamenti ai VGUID.


----[ 2.4.2.1 Permessi di lettura e scrittura

OceanStore fornisce due primitive per il controllo degli accessi: permesso di
lettura e permesso di scrittura. Altri tipi di regole piu' complicate, quali
gruppi di lavoro, si riconducono a queste.
  Per limitare la lettura non autorizzata di documenti, tutti i dati di
OceanStore non completamente pubblici sono crittografati, e la chiave di
decifratura e' distribuita agli utenti con permessi di lettura. Per revocare il
permesso di lettura ad un oggetto senza modificarlo, il proprietario
dell'oggetto deve richiedere che i replica debbano essere cancellati e cifrare
di nuovo il contenuto.
  Puo' sembrare strano il fatto che un utente a cui e' stato revocato il
permesso di lettura puo' accedere agli oggetti in cache (nei floating replica)
non ancora ri-cifrati; e' anche possibile che un nodo malevolo non aggiorni i
cambiamenti di permessi. Tuttavia questo problema e' implicito a tutti i
filesystem, in quanto non e' possibile impedire che un utente ricordi cio' che
ha letto.
  L'accesso in scrittura e' verificato in modo molto diverso da quello in
lettura, in quanto le letture sono limitate dagli utenti grazie allo scambio di
chiavi, mentre le scritture sono controllate dai server esaminando certificati
digitali. Infatti una modifica all'oggetto e' accettata oppure no dal nodo a
seconda della ACL (Access Control List) presente nell'oggetto stesso imposta
dal proprietario. Questo campo nell'oggetto puo' anche essere un puntatore ad
un altro oggetto contenente una ACL. I permessi concessi da queste access list
sono molto semplici: si descrive per ogni chiave pubblica di un utente i suoi
permessi sull'oggetto, non si descrive l'identita' degli utenti ne' la presenza
di utenti maggiormente privilegiati.
    Per ovvi motivi di gestione, questo campo contenente i permessi e gli
oggetti che contengono solo permessi non sono mai cifrati, cosicche' i nodi
possano sempre verificare le regole.
  Inoltre la memorizzazione di un nuovo blocco di dati non richiede consensi,
se non limitazioni da parte del nodo a cui l'utente e' connesso; il
proprietario deve solamente generare l'oggetto con la sua chiave pubblica, e
imporre se ne ha bisogno i permessi necessari. L'inserimento in un percorso a
directory, come detto precedentemente, e' del tutto personale e non necessita
quindi di essere reso pubblico.


----[ 2.4.2.2 Scrittura ed operazioni sui blocchi cifrati

In OceanStore i cambiamenti ai dati di un oggetti vengono effettuati dagli
utenti che generano nuove versioni. Ogni tentativo di aggiornamento viene
registrato, che sia andato a buon fine oppure no. Nel caso di aggiornamenti
concorrenti eseguiti con la stessa chiave pubblica, viene utilizzata una
politica di merging dei blocchi di dati; possono pero' accadere conflitti non
risolvibili, che vengono gestiti generando una nuova versione dell'oggetto.
  Il modello di aggiornamento dei dati di OceanStore funziona anche con i
blocchi di dati cifrati; infatti i nodi implicati nella procedura di
aggiornamento non devono poter conoscere il contenuto di oggetti riservati.
Questo e' essenziale per poter attuare un sistema distribuito peer-to-peer
affidabile. e' da notare che la maggior parte dei dati sono contenuti in
oggetti cifrati, in quanto la presenza di dati con permessi assegnati sono la
norma in un qualsiasi filesystem.
  Questa complicazione e' risolta utilizzando un algoritmo di cifratura
position-dependent a blocchi. Le operazioni possibili sono quindi:

o confronto di versione;
o confronto di dimensione;
o confronto di blocchi;
o ricerca;
o sostituzione di blocchi;
o aggiunta in coda di blocchi;
o inserimento di blocchi;
o rimozione di blocchi.

  Le prime due operazioni sono banali in quanto lavorano sui metadati. Il
confronto di blocchi e' possibile utilizzando un algoritmo di cifratura come
indicato: l'utente calcola l'hash del blocco cifrato che vuole confrontare e lo
invia ai nodi OceanStore che effettueranno il controllo corrispondente.
  La ricerca puo' essere effettuata direttamente sul testo cifrato, senza
rivelare in chiaro la stringa di ricerca ma solo l'esito della ricerca; ne' e'
possibile per i nodi della rete effettuare ricerche di loro iniziativa.

  Il funzionamento di questa ricerca all'interno di un blocco di dati cifrato
  e' stato dimostrato rigorosamente da Dawn Xiaodong Song, David Wagner e
  Adrian Perrig [21]. Il trucco sta nel produrre il testo cifrato da
  memorizzare effettuando uno XOR bit a bit tra le singole parole cifrate con
  un algoritmo deterministico (di tipo ECB) e degli stream cipher generati
  partendo da sequenze pseudo casuali con una chiave nota.
  La ricerca su questo testo cifrato prodotto dallo XOR presente sul server 
  inaffidabile avviene inviandogli la parola da cercare cifrata e la chiave
  utilizzata per generare lo stream impiegato nell'operazione di XOR. Il
  server deve quindi effettuare lo XOR fra il testo cifrato e la parola
  cifrata inviatagli, e verificarne la corrispondenza con il ciphertext
  generato dalla chiave nota.

    Figura 2.5: Creazione ciphertext da memorizzare sul nodo inaffidabile.

  Schematizzando in figura 2.5, al fine di generare il testo protetto da
  memorizzare sul nodo inaffidabile si procede come segue:

    o il testo in chiaro viene cifrato dall'utente con una chiave privata Ks
      utilizzando un algoritmo di codifica a blocchi (ECB) sulle parole prese
      ad una ad una;

    o l'utente produce una sequenza di bit pseudocasuali (stream cipher)
      generato con una chiave nota Kp;

    o essendo il testo cifrato facilmente riconoscibile dal momento che una
      parola produce sempre lo stesso ciphertext, l'utente effettua lo XOR
      binario tra il testo cifrato e la sequenza di bit pseudocasuale;

    o il risultato produce il testo in una nuova forma cifrata in cui ad ogni
      medesima parola non corrisponde lo stesso ciphertext;

    o questo testo protetto viene inviato al nodo che lo memorizza.

  Ora che tale testo cifrato e' presente sul nodo, la ricerca di una parola da
  parte di un utente si effettua come segue:

     o la parola da ricercare viene cifrata dall'utente con la stessa chiave
       privata Ks e l'algoritmo ECB di prima;

     o l'utente invia al nodo tale parola in forma cifrata e la chiave nota Kp
       utilizzata per generare la sequenza pseudocasuale di bit utilizzata
       prima;

     o il nodo genera la sequenza pseudocasuale tramite la chiave nota
       inviatagli;

     o il nodo effettua lo XOR blocco per blocco tra il testo cifrato che
       memorizza e la parola cifrata ricercata dall'utente;

     o per ogni blocco verifica se il risultato compare nella sequenza
       pseudocasuale;

     o in caso affermativo la parola cercata dall'utente e' presente nel testo
       cifrato che risiede sul nodo.

  Il server non puo' venire a sapere nulla del contenuto del testo, ne' della
  stringa di ricerca; tuttavia analizzando la lunghezza della stringa di
  ricerca, il server potrebbe effettuare attacchi statistici. Il server non
  puo' effettuare ricerche di sua iniziativa, non disponendo del testo cifrato
  con la chiave Kp.

  Infine si noti che quest'algoritmo e' computazionalmente pesante per il
  server avendo un ordine O(n) lineare con la lunghezza n del testo presente;
  le cose si complicano nel caso di ricerche con caratteri jolly, poiche' e'
  necessario ricercare tutte le combinazioni possibili.

  La sostituzione di blocchi e l'accodamento di blocchi cifrati sono semplici,
sempre utilizzando un algoritmo di cifratura indicato per i confronti. Per
l'inserimento e la cancellazione di blocchi cifrati l'operazione e' piu'
delicata e richiede che i dati siano organizzati in due gruppi: blocchi di
indice e blocchi di dati. I blocchi di indice non sono cifrati e contengono
puntatori ad altri blocchi all'interno dell'oggetto. Per effettuare un
inserimento, il blocco presente al punto di inserimento e' sostituito con un
blocco di indice; questi conterra' prima l'indice al nuovo blocco da inserire,
e poi l'indice del blocco sostituito, che verranno entrambi accodati
all'oggetto. In questo modo i nodi che effettuano l'operazione non vengono a
conoscenza del contenuto dei blocchi.

  Figura 2.6: Inserimento di un blocco cifrato. L'inserimento di un blocco tra
              il 41 ed il 42 provoca la sostituzione del 42 con un blocco di
              indice e l'accodamento del nuovo blocco 41.5 e del blocco 42.

  Per la cancellazione, anche qui si utilizzano i blocchi di indice: i
blocchi da rimuovere sono sostituiti da blocchi di indice vuoti.
  Queste operazioni di inserimento e cancellazione possono pero' fornire al
nodo informazioni sul traffico effettuato, ed essere suscettibili ad attacchi
di analisi passiva; la soluzione temporanea a questo problema inizialmente
venne rimandata ad applicazioni intelligenti a livello superiore, che dovevano
accodare nuovi blocchi inserendovi le operazioni da effettuare ed ogni tanto
ri-cifrare gli oggetti effettuando tali operazioni.

  In Pond si e' poi deciso di utilizzare uno schema a due livelli di oggetti,
nel piu' basso dei quali si trovano oggetti contenenti solo blocchi cifrati; a
livello superiore si trovano oggetti contenenti solamente blocchi di indice. In
questo modo le operazioni di inserimento e cancellazione si riducono a
spostamenti di puntatori sul primo livello. Questo dovrebbe limitare gli
attacchi di analisi di traffico, ma aggiunge gradi di complessita' al modello.


----[ 2.4.2.3 Aggiornamento distribuito su rete inaffidabile

In caso di conflitti nel processo di aggiornamento di un oggetto, e'
necessario scegliere un ordine con il quale eseguire i vari passi, ed eseguirli
nella corretta sequenza; il modello di riferimento e' lo schema ACID di
risoluzione dei conflitti, quello tipico delle basi di dati. Il modo piu'
semplice per effettuare questo lavoro sarebbe far elaborare gli aggiornamenti
ad un singolo nodo; tuttavia questo schema andrebbe contro l'idea di fondo di
OceanStore, poiche' ci si fiderebbe di un unico nodo. Il lavoro di questo nodo
viene quindi ripartito ad una classe ridotta di nodi, completamente connessa,
chiamata primary tier (o inner ring). Questi nodi cooperano fra di loro tramite
il Byzantine Agreement Protocol nella scelta dell'ordine definitivo di
esecuzione delle operazioni. Come descritto in precedenza, questo protocollo
prevede che i nodi malevoli non superino M nodi su un totale di N = 3 * M + 1;
i quattro nodi della figura 2.7 prevedono quindi che al massimo 1 nodo possa
essere malevolo. Si e' gia' accennato alla sua vulnerabilita' nota col nome di
Eclipse attack; questo limite degli M nodi ostili su N = 3*M +1 nodi totali e'
una limitazione implicita. Immaginando pero' una rete globale basata su
migliaia di nodi diversi per piattaforma e proprietario diventa difficile
riuscire nell'attacco; tuttavia il risvolto negativo e' l'elevato numero di
comunicazioni per le verifiche, dell'ordine di O(N^2).

  Figura 2.7: Aggiornamento con le due classi di nodi. (a) Un client invia la
              notifica di una modifica a vari nodi tra cui un nodo primario;
              (b) mentre il primary tier elabora il risultato della modifica,
              gli altri nodi propagano la notifica; (c) quando il primary tier
              ha concluso, diffonde tra i nodi il risultato.

  Gli altri nodi appartengono al secondary tier e comunicano fra di loro e con
il primary tier tramite un algoritmo epidemico, che inoltra le informazioni a
tutti i nodi. Il protocollo di diffusione dei dati e' tratto dal sistema Bayou
sviluppato presso il PARC [22]. La scelta di utilizzare due classi di nodi per
la propagazione degli aggiornamenti e' un giusto compromesso tra numero non
eccessivo di connessioni per le verifiche e distribuzione dei compiti. Il
primary tier, essendo in teoria connesso da linee a banda elevata, puo'
effettuare le verifiche necessarie in tempi veloci.
  Prima di ricevere l'ordine esatto di esecuzione degli aggiornamenti, i nodi
del secondary tier continuano a diffondere l'aggiornamento non ancora
verificato, non sapendo se la richiesta e' giunta al primary tier; e' quindi
possibile per una applicazione che necessita di risultati non definitivi ma in
tempi rapidi di utilizzare le richieste di aggiornamento. Infatti con la
richiesta e' presente un timestamp e il client puo' ottimisticamente valutare i
timestamp di due aggiornamenti concorrenti; all'arrivo dell'informazione dal
primary tier la sua supposizione sara' poi confermata oppure smentita. Siccome
le decisioni del secondary tier sono tentativi, non possono essere affette da
attacchi; per avere garanzie di consistenza e' sufficiente attendere l'ordine
fornito dal primary tier.
  Infine si noti che le comunicazioni tra i nodi dell'inner ring sono
autenticate da meccanismi a chiavi simmetriche, per via della loro velocita' di
computazione maggiore rispetto alle firme a chiave pubblica; queste ultime
vengono invece utilizzate dal secondary tier, i cui nodi possono cosi'
verificare l'autenticita' dei dati senza dover comunicare con il primary tier.


--[ 2.5 Conclusioni

  La rete OceanStore rappresenta un notevole sforzo di realizzare un data store
distribuito in grado di gestire il problema dell'affidabilita' dei nodi. Una
rete di questo tipo pero' necessita di una larga base d'utenza, senza la quale
con abbastanza nodi si puo' facilmente sovvertire il Byzantine Agreement
Protocol.
  Attualmente OceanStore e', sebbene pienamente funzionante, ancora in fase di
sviluppo e di testing; l'implementazione corrente evidenzia problemi di latenza
nel Byzantine Agreement Protocol che rendono la rete lenta benche', come
illustrato, le operazioni avvengono localmente. Per rimediare a questo
inconveniente ci si sta concentrando sullo sviluppo di un algoritmo di
consistenza che richieda meno comunicazioni, pur assicurando una buona
resistenza.
  OceanStore inoltre e' interessante per via del suo carattere commerciale. A
parte le attuali problematiche prestazionali, l'interesse dei clienti potrebbe
essere limitato proprio dalla natura P2P del servizio, ancora oggi associata a
fenomeni quali distribuzione di materiale illegale e violazione di copyright:
gli utenti potrebbero non considerarla adatta per ospitare i propri contenuti
sensibili.


-[ 3 Mnemosyne

Un altro storage distribuito di tipo peer-to-peer basato su Tapestry e'
Mnemosyne [23] [24] [25], ideato da Steven Hand e Timothy Roscoe. L'approccio
rispetto ad OceanStore e' pero' differente; si tratta di un file system
steganografico, poiche' utilizza i blocchi di dati dispersi sulla rete per
nascondervi le informazioni utili.
  La steganografia [26] e' una tecnica che consente di nascondere un messaggio
all'interno di un dato che funge da contenitore, in modo tale che solo il
destinatario sia in grado di individuare la presenza dell'informazione
nascosta. Un esempio classico e' nascondere il testo di un messaggio
all'interno della codifica di un'immagine. La steganografia non protegge il
contenuto sensibile ma lo nasconde (e' una forma di "security through
obscurity"). Spesso il dato nascosto e' comunque crittografato: si aggiunge
quindi un ulteriore livello di protezione che garantisce la segretezza del
contenuto nell'eventualita' che l'attaccante riesca ad individuare ed estrarre
l'informazione nascosta. In questo caso particolare, ad un utente che ignora la
presenza di Mnemosyne oppure e' privo delle chiavi corrette, il filesystem
appare come un insieme di blocchi di dati non allocati e senza significato: non
solo un attaccante non puo' accedere ai dati, ma non sa neppure se i dati
esistano.

  I principali vantaggi di un filesystem di questo tipo sono:

o Estraneita' dei gestori dei nodi riguardo i contenuti dei dati,
  tecnicamente chiamata negazione plausibile di responsabilita' (plausible
  deniability). I fornitori del servizio infatti non sono al corrente (e non
  possono esserlo in alcun modo) del contenuto dei dati, e quindi non possono
  essere considerati a tutti gli effetti responsabili delle informazioni che
  ospitano, compatibilmente con la legislazione locale.

o Resistenza ad interruzioni di servizio. Per un utente che vuole sicurezza in
  termini di accessibilita' e disponibilita', un sistema distribuito e' molto
  meno soggetto a guasti e ad attacchi di tipo Denial of Service.

o Trasmissione sicura di informazioni. Viene garantito un alto livello di
  riservatezza allo scambio di dati.

  Ogni nodo di Mnemosyne agisce sia da client che da server: le funzioni di
client comprendono l'accesso in lettura e scrittura di blocchi di dati, mentre
la parte server fornisce uno spazio per la memorizzazione di blocchi di dati
(non e' necessariamente affidabile).

  Comunemente i meccanismi per applicare la steganografia sono due:

o Creare dei file di copertura contenenti dati sensati sufficientemente
  entropici oppure del tutto casuali ed insensati, e memorizzare le
  informazioni da coprire effettuando uno XOR bit a bit con il file di
  copertura nelle posizioni indicate da una chiave.

o Scrivere dati casuali su tutti i blocchi di un disco; cifrare ogni blocco
  del file da memorizzare che viene scritto sui blocchi del disco scelti
  secondo un algoritmo pseudo-casuale.

  L'implementazione steganografica utilizzata e' la seconda, e parte dalle idee
di StegFS [27], un noto filesystem steganografico locale per Linux; e' adattato
per essere comodamente gestito su una rete Tapestry. Tuttavia i meccanismi di
Mnemosyne funzionano anche per un sistema locale, per cui verra' prima
descritto il suo funzionamento in locale.


--[ 3.1 Steganografia locale a blocchi

Il filesystem e' organizzato a blocchi di dati; in fase di formattazione
tutti i blocchi sono colmati da dati casuali, in modo da massimizzare
l'entropia sul filesystem. Il file da memorizzare e' quindi diviso in parti, le
quali sono cifrate con una chiave segreta e quindi scritte su blocchi sparsi
del filesystem; il posizionamento e' determinato da un hash calcolato a partire
dal nome del file e dall'indice del blocco del filesystem. Se la chiave segreta
e l'algoritmo di hashing sono buoni, i blocchi del file sono difficilmente
distinguibili dai blocchi contenenti dati casuali.
  Il problema di questo meccanismo sono le collisioni: infatti stessi blocchi
possono essere sovrascritti da successive memorizzazioni di file. Per ovviare a
questo problema si utilizza la replicazione, per cui ogni blocco e' scritto in
n ubicazioni differenti. La scelta di n e' strategica, poiche' se troppo
piccolo o troppo grande il rischio di perdere blocchi a causa di sovrascritture
aumenta notevolmente; gli sviluppatori indicano un numero di replicazioni n
ottimale che va da 2 a 8.
  Nello specifico la scrittura di un blocco di dati richiede, oltre al blocco
stesso, una chiave segreta K, un valore di hash iniziale per il blocco h0 ed
una stringa da utilizzarsi come controllo di validita'. Il primo passo e'
quello di calcolare una sequenza n di hash differenti (n e' il numero di
replicazione), ottenuta da una funzione di hashing H (attualmente si utilizza
SHA-256) come: h_0, h_1 = H(h_0), ..., h_n - 1 = H(h_n - 2)
  Il passo successivo e' quello di cifrare la copia i-esima del blocco
(ovviamente 0 <= i <= n - 1), con la chiave k_i= E_K (h_i); la funzione di
cifratura a blocchi E_K() utilizzata e' AES, con la chiave segreta K lunga 256
bit. Il blocco i-esimo e' memorizzato alla posizione b_i = h_i mod (N), dati N
blocchi totali. Si noti che l'utilizzo di una chiave k_i per ogni replica del
blocco assicura l'omogeneita' dei dati.

  Per la lettura il processo e' inverso: data la chiave K e il valore di hash
h_0, si calcolano le varie posizioni delle copie del blocco e si decifrano man
mano, finche' un blocco passa il controllo di validita'. Questo controllo di
consistenza e' sotto forma di stringa presente all'interno del blocco stesso;
la sua struttura cambia a seconda del contenuto del blocco, che puo' accogliere
dati, un inode oppure una directory.
  La funzione principale del blocco directory e' quella di raccogliere file che
utilizzino la stessa chiave K; il blocco contiene il nome della directory
stessa e la lista dei nomi dei file. h_0 e' calcolato come l'hash del nome
della directory, dopo averne calcolato lo XOR con la chiave K. Si noti che
cosi' facendo nomi di directory identici vengono scritti da utenti differenti
in luoghi differenti; inoltre il controllo di validita' si ottiene dal nome
della directory, avendo h_0 e K.
  Il blocco inode serve per raccogliere i collegamenti ai blocchi di dati che
appartengono ad un file. Il valore h_0 per questo blocco e' calcolato dall'hash
sulla directory del file concatenato con il nome del file, e anche qui il
risultato si ottiene dopo lo XOR con la chiave K. Il blocco contiene anche il
nome del file, che serve al controllo di correttezza. Si noti che i blocchi
directory sono opzionali alle operazioni sui file, a patto che si conosca gia'
il nome della directory.
  I blocchi inode contengono quindi una lista di puntatori ai blocchi di dati;
ogni elemento contiene una coppia di valori da 256 bit: il valore di h_0 per il
blocco dati e l'hash sul contenuto del blocco dati, da utilizzarsi per il
controllo di validita'.
  Contrariamente all'implementazione di StegFS, il sistema descritto e' del
tutto piatto in quanto non vi e' un elemento piu' importante che gestisce
l'ubicazione dei blocchi; Mnemosyne e' quindi scalabile a piacere e del tutto
decentrato. Inoltre la replicazione permette di non dover fidarsi di tutto il
dispositivo di memorizzazione, ma basta che la gran parte delle volte si
comporti correttamente.


--[ 3.2 Steganografia distribuita

Lo schema descritto si estende facilmente all'utilizzo distribuito con
Tapestry. Infatti il numero di blocchi totali del sistema ora e' dato dalla
somma dei nodi per il numero di blocchi disponibili per nodo; cambia il
meccanismo per determinare la posizione del blocco i-esimo partendo dal suo
hash h_i. Dato un insieme di M nodi Tapestry, supponendo che ognuno fornisca lo
stesso spazio (per esempio 1 GB composto da 2^20 blocchi da 1 KB), il modo piu'
semplice per operare e' riservare i primi 160 bit di h_i all'identificazione
del nodo Tapestry M_i, ed per esempio i successivi 20 bit come b_i su quel
nodo. Quindi quando un nodo vuole leggere un blocco, parte da h_0, ottenendo
M_0 e b_0. Poi prova le altre copie del blocco fino a h_n - 1, utilizzando M_n
- 1 e b_n - 1. Le richieste possono essere effettuate in parallelo; il primo
blocco che arriva ed e' corretto viene utilizzato.
  Le primitive di accesso ai file sono due, lettura e scrittura; come accennato
prima richiedono solo l'informazione sull'ubicazione del blocco. Tutta la parte
di verifica del blocco ed estrapolazione di puntatori e nomi viene fatta
dall'utente. Le informazioni in Mnemosyne sono nascoste a due livelli, in
quanto sia i blocchi sono sparsi su diversi nodi non noti a priori, sia il
blocco e' all'interno di una lista di blocchi dai contenuti egualmente
probabili.
  Si noti che se un nodo vuole offrire meno spazio degli altri, deve mappare i
bit di indirizzo sul suo numero ridotto di bit di indirizzo utilizzabili; se
invece vuole offrire maggiore spazio, deve utilizzare un altro identificativo
Tapestry.


--[ 3.3 Considerazioni e vulnerabilita'

Il modello descritto e' stato migliorato, in quanto il meccanismo di
replicazione rimane il punto debole del sistema, poiche' e' troppo
semplicistico. Si utilizza quindi un algoritmo di dispersione di informazioni
(Information Dispersal Algorithm, IDA) che garantisce una migliore
distribuzione dei blocchi e quindi anche una minore sovrascrittura dei dati.
  L'adozione di un IDA costringe pero' all'utilizzo di un controllo di
validita' dei blocchi basato su cifratura a blocchi (in particolare si utilizza
OCB); e' quindi possibile aggirare un attaccante che controlla le richieste di
un nodo tramite analisi passiva del traffico, richiedendo dei blocchi
identificati dall'IDA che non c'entrano nulla con i dati voluti; i blocchi
indesiderati saranno scartati all'arrivo grazie ad OCB.
  Rimane l'inconveniente che ogni lettore di un file puo' modificarlo oppure
cancellarlo. Per aggirare il problema, con l'IDA e' possibile fornire al
lettore l'indicazione di una parte minima delle repliche dei blocchi, per cui
l'autore che e' l'unico a conoscere tutte le locazioni dei blocchi non perde il
contenuto.
  Un altro problema e' la necessita' di effettuare un refresh dei vecchi file.
Infatti piu' vengono aggiunti blocchi nuovi, piu' e' possibile perdere il
contenuto dei vecchi blocchi utili mai piu' riscritti. Percio' e' necessario
decidere un periodo di rinfresco dei file, tuttavia difficile da stabilire
perche' l'utente non conosce l'attivita' generale del sistema. Inoltre nasce
un'altra questione sulla vulnerabilita' all'analisi del traffico, in quanto e'
possibile localizzare i blocchi aggiornati. Riscrivere blocchi non propri per
confondere l'attaccante non e' una soluzione efficace poiche' puo' generare
collisioni.
  L'implementazione attuale e' sperimentale e non e' liberamente ottenibile; la
parte client e' scritta in linguaggio C ed utilizza SHA-256 e OCB-AES, mentre
l'IDA e' un polinomio con 216gradi di liberta'. La parte server e' scritta in
Java e si basa su Tapestry, utilizzando UDP. Le prestazioni raggiunte in locale
sono dell'ordine di 80 KB/s in scrittura e 160 KB/s in lettura.
 

-[ 4 Free Haven

Il progetto Free Haven [28] [29] nasce con lo scopo di realizzare un sistema
distribuito anonimo di memorizzazione persistente; tra i suoi obiettivi
principali vi e' l'anonimato delle operazioni effettuate e dei contenuti dello
storage, realizzati tramite una rete peer-to-peer in cui tutti i nodi
collaborano in modo paritario. I nodi paritari offrono uno spazio di
memorizzazione, in cui i dati contenuti sono frequentemente scambiati con gli
altri; per migliorare l'affidabilita' della rete e' presente un sofisticato
meccanismo di reputazione sulle transazioni. La riservatezza e' piu' importante
delle prestazioni del sistema, in quanto il suo scopo ultimo e' resistere alla
censura dei contenuti attuata da avversari potenti.
  L'anonimato della rete Free Haven e' in gran parte assicurato dall'utilizzo
di canali di comunicazione basati su meccanismi di rete a cifratura multipla,
come quello offerto dalla rete Mixminion oppure dalla rete Tor (The Onion
Routing). La rete Mixminion offre un sistema per la trasmissione anonima di
messaggi di posta elettronica; e' l'implementazione del terzo tipo di remailer
anonimi. L'anonimato delle comunicazioni e' assicurato dal transito del
messaggio attraverso una serie casuale di nodi remailer, dove ad ogni
trasmissione il dato e' decifrato con differenti chiavi asimmetriche. La rete
Tor lavora in modo simile ma piu' sofisticato, opera a livello TCP e permette
prestazioni nettamente migliori. Infatti Mixminion ha troppe latenze per essere
impiegato efficacemente come livello di rete di uno storage distribuito;
funziona bene con i messaggi di posta elettronica, che non hanno particolari
esigenze di performance.

  Il progetto Free Haven e' iniziato nel dicembre 1999 presso il Massachussets
Institute of Technology da Roger Dingledine e Nick Mathewson e ha ricevuto
negli anni collaborazioni e supporto dall'US Navy e dall'Electronic Frontier
Foundation. Le ultime attivita' riguardanti lo sviluppo vero e proprio della
rete Free Haven sono datate dicembre 2004; piu' che alla progettazione dello
storage stesso, il progetto Free Haven e' stato molto utile allo sviluppo di
Mixminion e Tor; attualmente e' attivo sul fronte Tor. In appendice A e B si
trovano le trattazioni esaustive dei sistemi Mixminion e Tor, con le relative
analisi di sicurezza. Questo capitolo descrive quindi il funzionamento e le
caratteristiche progettuali di Free Haven, analizzandone gli aspetti relativi
alla sicurezza; si da' per scontata la conosenza del funzionamento del livello
di rete sottostante per la comunicazione anonima.


--[ 4.1 Principi e funzionamento

Seppur implementato solo nel livello di trasporto delle informazioni,
l'intero progetto Free Haven e' sempre stato definito per quanto riguarda le
sue caratteristiche. Gli autori hanno ritenuto infatti inutile implementare il
sistema finche' vi sono incertezze nella progettazione, esaminate alla fine del
capitolo.
  I principi che hanno guidato lo sviluppo del progetto Free Haven sono:

o Robustezza e anonimato, ottenuti grazie alla dispersione dei contenuto ed ad
  un livello di comunicazione anonima.
o Affidabilita', data da una rete di fiducia decentralizzata.
o Semplicita' e modularita', in quanto i sistemi complessi portano sempre a
  debolezze di sicurezza. Questi concetti hanno favorito la definizione e lo
  sviluppo di Tor.
o Flessibilita', poiche' l'operatore di ogni nodo puo' decidere quanto essere
  paranoico o fiducioso.
o Neutralita' del contenuto. La popolarita' o l'opinione su un contenuto non
  influenzano la permanenza sulla rete.
o Free e Open Source, visto che la ridistribuzione del codice e
  l'incoraggiamento alle modifiche favoriscono la scoperta di vulnerabilita' e
  il miglioriamento del programma.

  Il progetto si pone come strumento per impedire la censura o l'individuazione
degli autori e dei fruitori dei documenti; l'attenzione e' centrata piu' sullo
sviluppo di meccanismi di riservatezza e di permanenza delle informazioni
rispetto alle prestazioni, intese sia come tempi di accesso che banda occupata.
La rete Free Haven evita la censura partendo dalla considerazione che le
informazioni censurate in alcune zone tipicamente non lo sono in molte altre;
favorendo lo scambio frequente dei dati cifrati fra nodi localizzati in molti
luoghi diversi impedisce l'individuazione esatta dei contenuti sensibili. Il
sistema essendo poco efficiente e' pensato per memorizzare i contenuti in modo
affidabile, per poi renderli disponibili tramite canali convenzionali, come per
esempio pagine web situate in locazioni dove tali informazioni non sono
soggette a censura.

  Un file sulla rete Free Haven non e' presente come tale, ma per assicurare
robustezza e' disperso fra i nodi utilizzando un Information Dispersal
Algorithm (IDA). Tale algoritmo prevede che dal file da pubblicare si ottengano
N parti, in modo tale che almeno un sottoinsieme k di tutte le parti permetta
la ricostruzione corretta del dato. In particolare si e' pensato all'IDA ideato
da Rabin [30]; esso offre il secret share, in quanto con i < k parti non si
puo' ricostruire il messaggio. Questo fatto e' importante in quanto garantisce
la negazione plausibile di responsabilita' (plausible denyability) per un nodo
che contiene le parti di un contenuto. E' possibile scegliere il livello di
robustezza, dato da r = N/k, variando il valore di k, in quanto un valore
piccolo rispetto ad N implica una maggiore robustezza, mentre un valore di k
elevato significa minor spazio occupato.


---[ 4.1.1 Operazioni

Free Haven si compone di una rete di nodi peer-to-peer che offrono spazio di
memorizzazione, ricevendone in cambio. Tuttavia l'autore o chi pubblica un
contenuto non e' costretto a mantenere un nodo, ma puo' contattare un nodo a
sua scelta chiedendogli di pubblicare il contenuto sulla rete. Si possono
quindi distinguere due livelli gerarchici, i client e la servnet.
  L'identita' di un client e' nascosta grazie alla comunicazione tramite
Mixminion o Tor con il nodo. Esso e' scelto senza un criterio preciso, deve
pero' essere predisposto con un reply block pubblico ed essere disponibile a
pubblicare i dati di utenti anonimi. Per il client tutti i nodi sono uguali;
per l'estrazione di un contenuto il client invece si interfaccia con tutti i
nodi, in quanto ottenere un contenuto implica una ricerca in broadcast su tutta
la servnet.
  Un nodo della servnet invece si raffronta con gli altri nodi in modo
paritario; d'ora in avanti si considereranno client e nodo come un'unica
entita', in quanto e' un nodo che effettivamente pubblica ed estrae i
contenuti.
  Le operazioni fondamentali sulla rete sono:

o Inserimento nella rete di un contenuto da parte di un utente anonimo.
o Estrazione di un contenuto con modalita' anonime, che incorpora un
  meccanismo di verifica di autenticita' ed integrita' del contenuto.
o Meccanismo di scadenza dei documenti. All'inserimento deve essere imposta
  la durata della permanenza, durante la quale esso e' immutabile.
o Meccanismo per l'aggiunta di nodi alla rete senza provocarne rallentamenti
  o disfunzioni.
o Meccanismo per individuare ed escludere dal sistema i nodi inattivi o
  malevoli.


----[ 4.1.1.1 Inserimento

Un nodo che vuole pubblicare un contenuto, deve per prima cosa creare le N
parti ottenute con l'IDA. Quindi deve procedere generando una coppia di chiavi
asimmetriche Kp[dato] e Ks[dato] da utilizzare per firmare le parti. Ogni
frammento e' presente sulla rete come un blocco di dati contenente la parte
stessa, un hash della chiave pubblica HASH(Kp[dato]) per provare l'autenticita'
del dato (message digest), un timestamp con informazione sulla scadenza, il
numero della parte dato dall'IDA e naturalmente la firma ottenuta con la chiave
Ks[dato] per verificare l'integrita'.
  Le parti di un file sono tenute nello spazio di memorizzazione locale. Per
introdurre un nuovo contenuto e' allora necessario incrementare il proprio
spazio di memorizzazione condiviso in modo da poterlo contenere localmente. Il
nodo chiede poi ad altri nodi scelti di memorizzare le parti che contiene.
Avvengono quindi degli scambi di frammenti fra i nodi; questi scambi sono
continui e frequenti, permettendo la dispersione statistica delle parti sulla
rete; gli aspetti di una rete dinamica verranno analizzati nella sezione 4.1.2.
L'algoritmo di IDA deve essere robusto, in quanto la perdita di fino a meta'
dei nodi non deve compromettere la presenza dei documenti. Inoltre si assicura
che lo spazio totale presente su Free Haven e' sufficiente dato che un nodo per
immettere un documento, deve anche mettere a disposizione lo spazio necessario
a contenerlo.


----[ 4.1.1.2 Estrazione

Quando un utilizzatore del sistema (client o nodo che sia) vuole accedere ad
un oggetto, deve effettuare una richiesta a piu' nodi, possibilmente fidati; la
richiesta contiene una locazione ed una chiave da utilizzarsi per la consegna
dell'oggetto ricercato con modalita' anonima. Nel dettaglio, la ricerca si
effettua sull'hash della chiave Kp[dato] utilizzata per firmare le parti. Il
richiedente deve generare una coppia di chiavi asimmetriche Kp[nodo] e Ks[nodo]
per la ricerca, ed un reply block costruito ad-hoc.

  Per il funzionamento del reply block si rimanda all'appendice A e B; in breve
  esso contiene una serie di livelli di cifrature racchiusi l'uno nell'altro
  che permettono di rispondere ad un messaggio anonimo senza conoscerne il
  mittente.

La richiesta si compone quindi della chiave Kp[nodo], dell'hash della chiave
Kp[dato] e del reply block. Essa viene trasmessa ai nodi fidati; il nodo a cui
e' stata fatta la richiesta deve ritrasmetterla ai nodi da lui conosciuti, e
cosi' via. Le richieste essendo broadcast possono occupare una notevole banda;
possono pero' essere accumulate ed inviate in blocco in momenti piu' opportuni.
  Ogni nodo contattato della richiesta verifica se ha delle parti con l'hash
uguale a quello della chiave del dato cercato (HASH(Kp[dato])), nel qual caso
cifrano ogni parte con la chiave Kp[nodo] inviata e la trasmettono con il reply
block. Quando almeno k parti arrivano al nodo destinazione, e' possibile
ricostruire il contenuto desiderato.


----[ 4.1.1.3 Scadenza

Assieme ad ogni frammento e' presente un timestamp ed un'indicazione di
scadenza; essa e' un riferimento assoluto del momento dopo il quale un nodo
puo' cancellare senza problemi il dato. Si noti che diversamente da Freenet
(capitolo 5), qui e' l'utente che nel momento dell'inserimento del contenuto ne
decide la scadenza, indipendentemente dalla popolarita' del dato.


----[ 4.1.1.4 Gestione dei nodi

Un nodo che vuole far parte della rete inizialmente non conosce altri peer.
Per questo alcuni nodi possono servire da i'niziatore'; devono avere una buona
reputazione e devono essere disposti a notificare agli altri peer che conoscono
l'esistenza del nuovo nodo.
  Inoltre i nodi possono considerare come dormienti nodi che non rispondono ai
messaggi. In tal caso essi non vengono utilizzati per gli scambi e le ricerche.


---[ 4.1.2 Dinamicita' della rete

Questo sistema si basa sulla fiducia fra i nodi data dalla loro reputazione
[31], argomento approfondito nella sezione 4.2.1: un nodo che scarta
sistematicamente gli oggetti prima della loro scadenza non sara' in grado di
soddisfare le richieste come gli altri nodi e tendenzialmente verra'
considerato poco affidabile dal sistema. Per reputazione di un nodo s'intende
il suo grado di onesta' calcolato secondo il parere dei nodi che hanno
completato delle transazioni con esso. Ogni nodo mantiene quindi una lista di
nodi fidati a cui inviare gli oggetti e trasmettere le ricerche; questa lista
e' continuamente aggiornata secondo dei punteggi attribuiti internamente ai
nodi conosciuti. Le liste interne con i giudizi sono scambiate con gli altri
nodi. E' possibile variare il livello di fiducia minima richiesta scegliendo in
modo piu' o meno generoso dalla lista interna i nodi con cui comunicare.
  In questa rete quindi i nodi adiacenti o vicini sono i nodi fidati,
indifferentemente dai tempi o dalla banda del link tra due nodi: si realizza
una rete di fiducia, in cui un nodo ostile e' progressivamente escluso.

  Il meccanismo di scambio dei dati e' centrale al funzionamento di Free Haven.
I nodi non accettano qualsiasi scambio, viene stipulata una sorta di contratto,
in cui una coppia di nodi si promettono di ospitare i dati scambiati. Ogni
contratto concluso con successo incrementa la reputazione di un nodo, mentre un
nodo disonesto che scarta i dati prima della scadenza o non rispetta il
meccanismo di contratto la decresce. Un nodo con buona reputazione aumenta la
sua probabilita' di poter scambiare i suoi dati con gli altri peer.
  La frequenza degli scambi interni di dati e' un parametro deciso
dall'amministratore del nodo. Frequenti scambi permettono maggiore anonimato,
dato che non e' possibile distinguere tra scambi dovuti all'immissione di nuovi
dati e scambi interni regolari. Inoltre permettono di escludere in modo rapido
i nodi disonesti, in quanto si hanno frequenti contratti con conseguenti report
di fiducia dai nodi. Si noti infine che una rete dinamica quale e' la servnet
di Free Haven implica che per un attaccante (che vuole colpire l'anonimato od i
contenuti) non c'e' mai un unico specifico e statico obiettivo ed e' costretto
ad "inseguire" i dati.


----[ 4.1.2.1 Four-way handshake


  Figura 4.1: Four-way handshake

Si esamina ora come funziona il protocollo d'intesa per lo scambio di un
dato. Come presentato in figura 4.1, il nodo A vuole provare uno scambio con il
nodo B, scelto nella sua lista di nodi conosciuti fra quelli con buona
reputazione. A invia quindi il blocco di dati contenente la parte di file con i
suoi attributi, aspettandosi come risposta da B un altro blocco di dati. I
blocchi di dati scambiati dovrebbero avere circa lo stesso valore. Una proposta
di valore presente in [32] e' il prodotto fra dimensione e tempo prima della
scadenza; tuttavia dato il suo costo la dimensione e' meno importante rispetto
al tempo. Lo scambio non deve per forza avvenire, in quanto B puo' sia non
ricevere il messaggio sia non avere un dato con un valore simile.
  Il nodo B risponde con un suo blocco. Per completare la transazione, alla
ricezione il nodo A deve inviare una ricevuta dell'avvenuto scambio a B. Il
nodo B dovrebbe rispondere ad A con la sua ricevuta; tuttavia il nodo B
potrebbe essere disonesto e a questo punto scartare il dato di A senza
rispondere. Il nodo A e' autorizzato a scartare il vecchio dato e tenere quello
di B, in quanto la sua transazione e' terminata dopo aver inviato la sua
ricevuta; non ricevendo la ricevuta da B invia ai nodi conosciuti un reclamo
per abbassare la sua reputazione. Piu' robustezza potrebbe essere aggiunta
facendo in modo che il nodo A tenga il dato inviato fino alla ricezione della
ricevuta di B; cio' ha pero' delle controindicazioni per esempio nel caso di
collegamenti malfunzionanti che potrebbero portare al raddoppio dello spazio
richiesto.
  Il primo scambio di frammenti di dati ed il secondo scambio di ricevute
prendono il nome di fourway handshake. Si noti che le ricevute non implicano la
buona conclusione della transazione, ma solo della sua meta'. Esse vengono
diffuse non solo al nodo che partecipa allo scambio, ma anche agli altri nodi
conosciuti; nell'esempio, i nodi che ricevono sia la ricevuta sia il reclamo da
A hanno quindi una doppia conferma della disonesta' di B. La reputazione gioca
un ruolo molto importante in questi scambi, in quanto e' il fattore che
favorisce l'onesta' dei nodi nell'ultima ricevuta.
    Le ricevute sono composte dall'identificativo dei due nodi, dagli attributi
(HASH(Kp[dato]), numero di parte, timestamp) delle due parti scambiate e dal
timestamp dello scambio. Esse sono memorizzate a lungo dai nodi, come appunto
ricevute della transazione.
  E' stato proposto un meccanismo (buddy system) per il quale i frammenti di un
contenuto a due a due si `cercano' l'un l'altro, verificandone la presenza. In
caso di parte corripondente non trovata un nodo genera un reclamo. Questo
meccanismo potrebbe aumentare la robustezza sia in caso di nodo che scarta
prematuramente i dati, sia in caso di four-way handshake fallito. Le ricevute
vengono inviate ai nodi contenenti la parte associata, aumentando la cattiva
reputazione del nodo disonesto. Con l'algoritmo di IDA utilizzato la parte
associata ad una persa potrebbe attivamente creare una nuova parte cosi' da
rigenerare la coppia; anche questa soluzione e' stata pero' scartata per
evitare di congestionare la rete a causa di problemi del canale di
comunicazione.


--[ 4.2 Anonimato in rete

Free Haven vuole essere uno storage permanente anonimo. L'anonimato puo' essere
presente a differenti livelli; in questa rete quasi tutte le comunicazioni sono
anonime, poiche' include le seguenti proprieta':

o gli oggetti pubblicati sulla rete sono immessi da utenti che non devono poter
  essere rintracciati;
o gli utenti che recuperano gli oggetti presenti non devono doversi
  identificare in alcun modo;
o la posizione attuale di un oggetto non deve essere nota ad alcuno;
o un nodo della rete non conosce il contenuto dei suoi oggetti;
o le transizioni fra i nodi della rete devono essere effettuate in modo tale da
  fornire il minimo possibile di informazioni ad un osservatore esterno.

  In una rete distribuita l'anonimato non e' semplice da ottenere come la
cifratura di un dato: non e' un accordo dove bastano i due enti che fanno parte
della comunicazione, ma e' necessario avere un numero (il piu' vasto possibile)
di enti intermediari in modo tale da far perdere le tracce del mittente e del
destinatario. Tutti i sistemi di comunicazione realmente anonima, che quindi
non affidano l'identita' degli utenti ad un presunto server fidato (ad esempio
un proxy anonimizzante), hanno come requisito una rete eterogenea di nodi che
possano selezionare uno qualsiasi degli altri nodi per la trasmissione del
messaggio.
  L'anonimato prevede l'attribuzione di uno pseudonimo. Lo pseudonimo e la vera
identita' di un soggetto o nodo devono essere scorrelate. Per identita' si
intende sia il nome dell'utente, sia l'indirizzo IP e la locazione geografica
di un nodo.

  In Free Haven l'anonimato di chi pubblica e' garantito dal fatto che sia
l'autore che il nodo d'ingresso sono sconosciuti: l'autore grazie alla
comunicazione basata sui remailer e il nodo d'ingresso poiche' i continui
scambi con gli altri nodi lo nascondono. L'anonimato di un lettore e' protetto
dalla comunicazione con il reply block. La posizione di un contenuto e'
sconosciuta data la sua scomposizione tramite l'IDA ed i continui scambi; l'IDA
garantisce anche la negazione plausibile di responsabilita'. Le transazioni fra
i nodi sono rese anonime e poco correlabili ad un osservatore esterno grazie
all'utilizzo di un canale di comunicazione anonimo; i sistemi che Free Haven
puo' utilizzare sono Mixminion in modalita' Forward Message (vedi sezione A.2
in appendice) oppure la rete Tor (vedi appendice B).


---[ 4.2.1 La reputazione ed i suoi limiti

  Si noti che le transazioni tipicamente sono inaffidabili poiche' non si
conosce il destinatario; poche sono le transazioni fra gli stessi due nodi. Per
migliorare il grado di affidabilita' del destinatario di una transazione deve
esistere una sorta di accordo per verificare l'onesta' degli altri nodi, in
modo da escludere quelli disonesti. Cio' implica o di poter conoscere lo stato
di tutta la rete, impossibile dato l'anonimato richiesto, o di avere un modo
per fidarsi del destinatario. Il meccanismo di Free Haven per migliorare
l'affidabilita' della rete si basa sulla reputazione dei nodi, in quanto e' un
criterio di giudizio che mantiene l'anonimato del sistema. In Free Haven,
tramite la lista di nodi fidati, la reputazione di un nodo viene diffusa per la
rete.
  L'anonimato e la reputazione potrebbero sembrare proprieta' contrastanti. 
Tuttavia e' stato osservato che il sistema di fiducia fondato sulla reputazione
degli pseudonimi funziona, si guardi ad esempio ai servizi web quali eBay,
Yahoo! Auction ed ai commenti di Amazon [33].
  La reputazione e' pero' un elemento critico nei sistemi anonimi. Prima di
tutto in un ambiente anonimo e cosi' dinamico, e' comunque difficile essere
certi della disonesta' di un nodo. Alcuni accorgimenti potrebbero migliorare il
sistema, ad esempio il Buddy system, pero' implicano tutti l'aggiunta di
notevole complessita' ed overhead su una rete gia' non prestazionalmente buona.
  Un'altra questione riguarda eventuali reclami ingestibili: se un nodo onesto
viene maliziosamente screditato da un nodo malevolo, non e' possibile
verificare l'esattezza di un reclamo da parte del nodo erroneamente screditato.
Inoltre un attaccante che possiede abbastanza nodi puo' cercare di screditare
gli altri nodi ed accreditare i propri; questo potrebbe essere opportuno per
condurre attacchi passivi sui dati, perche' permette di esaminare una maggior
quantita' di traffico.
  Il meccanismo di reputazione ha inoltre alcuni problemi di anonimato. Un nodo
non puo' verificare tutti i nodi e, se ne misura alcuni, rende noto ad un
osservatore esterno l'informazione su quali nodi conosce; per questo in Free
Haven l'elenco di nodi fidati e' continuamente scambiato con gli altri e
l'affidabilita' di un nodo nell'elenco e' aggiornata dalle informazioni
passivamente ricevute dalla rete. Avere uno o alcuni nodi centrali che
gestiscono la reputazione dei nodi non risolve il problema poiche' si torna
alla situazione di partenza in quanto ci si lega ad un presunto nodo fidato che
puo' rispondere a suo piacimento ad ogni richiesta.

  Gli attacchi atti a modificare la reputazione di un nodo possono
principalmente avere come obiettivo l'accumulo di notorieta' o lo screditamento
di un nodo attaccato. Nel secondo caso si puo' interpretare come un attacco di
tipo DoS: il nodo attaccato assume una cattiva reputazione, diventa isolato
dalla rete che e' in effetti ragionevole al fine di proteggere l'intero
sistema. La rete Free Haven risponde quindi automaticamente ad un attacco di
questo tipo considerando un nodo attaccato non affidabile.
  Vi sono altri attacchi possibili contro il sistema di reputazione:

o Tradimento. Un nodo ostile che fa parte della rete accumula una buona
  reputazione per poi cancellare tutti i dati che contiene lasciando sulla
  rete i suoi file. In verita' un attacco di questo tipo non puo' avvenire in
  quanto per accumulare abbastanza credito per memorizzare i suoi dati deve
  mantenerne di conseguenza. Un nodo che agisce in questo modo non nuoce alla
  rete, ma in realta' le giova.

o Manomissione delle ricevute degli scambi. Le ricevute sono firmate ed
  includono un timestamp. Tuttavia un attaccante che dispone di piu' nodi
  potrebbe effettuare manomissioni della reputazione di un nodo inviando delle
  ricevute ad-hoc.

  La sezione 6.2.2 approfondisce le problematiche legate alla reputazione.


--[ 4.3 Vulnerabilita'


---[ 4.3.1 Anonimato

Diversi tipi di attacchi possono essere condotti al fine di rivelare
l'identita' di alcune entita' della rete:

o Identita' di chi estrae.
  Un attaccante potrebbe sviluppare e pubblicare sulla rete P2P un malware che
  contatta un server ostile, il quale registra le connessioni. Questo malware
  potrebbe semplicemente essere nascosto, per esempio in un documento
  ipertestuale, ed attivarsi al momento dell'apertura del documento.

  Un nodo della rete Free Haven che fa parte anche della rete del canale di
  comunicazione (per esempio Tor), potrebbe cercare di correlare le
  connessioni per individuare l'identita' dei nodi, per esempio tenendo
  traccia delle tempistiche del four-way handshake.

  Un nodo sofisticato potrebbe cercare di correlare i contenuti estratti da un
  utente e costruire dei profili statistici e cercarne la corrispondenza con
  individui fuori da Free Haven. Questo problema dovrebbe essere risolto
  dall'utilizzo di reply block sempre differenti per ogni estrazione.

o Identita' del nodo.
  Un nodo attaccante puo' creare delle parti eccezionalmente grandi e cercare
  quindi di ridurre il numero di nodi che possono permettersi lo scambio di
  moli di dati cosi' consistenti. Questo e' un problema di anonimato parziale,
  in quanto non e' possibile essere certi di una corrispondenza ma vi e' solo
  un sospetto dato dal numero esiguo di possibilita'.

  Sempre un nodo malevolo potrebbe immagazzinare tutte le informazioni
  sull'entrata ed uscita dei nodi dalla rete, inferendole dalle liste di
  fiducia dagli altri nodi; avendo un'ottima conoscenza delle caratteristiche
  di molte sottoreti di Internet, il nodo malevolo potrebbe cercare di
  costruire la topologia della rete Free Haven.

  Una variante della vulnerabilita' precendente potrebbe essere la diffusione
  su Internet di un codice malevolo (come un worm) che cerca i nodi Free Haven
  e pubblica la lista delle parti presenti sul nodo infettato.

  Riguardo l'anonimato non bisogna sottovalutare gli attacchi a livello
sociale; per esempio il pagamento in cambio di qualsiasi informazione utile e'
una costante minaccia. Questo problema dovrebbe essere fortemente limitato
dall'utilizzo di un canale di comunicazione adeguatamente anonimo.


---[ 4.3.2 I nodi ed i loro contenuti

Gli attacchi ai nodi possono avere il fine di limitare il loro funzionamento
oppure eliminare i dati contenuti:

o Attacco fisico. Un nodo puo' semplicemente essere distrutto. L'IDA permette
  di scegliere il livello di resistenza a questo tipo di attacco, in quanto per
  la perdita dell'informazione e' necessario distruggere piu' di n - k
  frammenti.

o Azione legale. Se si riesce a conoscere l'identita' di un nodo Free Haven,
  si puo' intraprendere un'azione legale al fine di rimuoverne i contenuti.
  Questo pericolo e' spesso risolto dalla negazione plausibile di
  responsabilita', dove applicabile, in quanto l'amministratore di un nodo non
  ne conosce i contenuti.

o Pressione sociale. Un amministratore oppure l'intera rete Free Haven potrebbe
  essere citata per contenuti illegali, immorali o che violino le leggi sul
  copyright; un amministratore potrebbe essere quindi costretto a rimuovere
  tutti i contenuti del suo nodo. Per questo si suppone che la rete Free Haven
  sia abbastanza vasta da coprire molti Paesi con differenti giurisdizioni,
  tale da permettere alla rete di sopravvivere anche in mancanza di molti nodi
  di un Paese.

o Denial of Service. La rete di Free Haven potrebbe essere attaccata da
  continue ricerche di dati o richieste di ingresso nella rete, in modo da
  sovraccaricarla. Questo tipo di attacco non dovrebbe funzionare se il canale
  di comunicazione e' bufferizzato, come il canale anonimo Tor o Mixminion.

o Data flooding. Si potrebbe cercare di riempire tutto lo spazio di
  memorizzazione. Come si e' visto, questo non e' permesso dal sistema di
  scambi.

o Accumulo di dati. Un attaccante con alcuni nodi dotati di notevole spazio
  puo' cercare di accumulare molti dati di Free Haven scambiando in modo
  intelligente dati spazzatura che trasferisce agli altri nodi. Si presuppone
  che la rete sia abbastanza vasta da rendere proibitivo un attacco di questo
  tipo. In caso contrario l'attaccante riesce sia ad eliminare dalla rete gran
  parte dei contenuti, sia a ricostruire i file.


--[ 4.4 Osservazioni

I problemi irrisolti di Free Haven relativi al meccanismo di reputazione, il
primo dei quali quello dei reclami, ne hanno probabilmente frenato lo sviluppo,
portando quindi gli sviluppatori a concentrarsi sul canale di comunicazione,
prima Mixminion e poi Tor. Il sistema di reputazione probabilmente dovra'
essere scartato per evitare troppa complessita', ripensando Free Haven da capo
con un modo per accertare anonimamente l'affidabilita' di un nodo senza che ci
possano essere reclami.
  Un ulteriore grosso problema e' proprio l'efficienza, in quanto per l'utente
finale medio l'usabilita' e' comunque piu' importante dell'elevato livello di
anonimato. Un sistema inusabile porta ad avere una base d'utenti ridotta, il
che e' diametralmente opposto al requisito principale di Free Haven, un largo
numero distribuito di nodi. Quindi prima di implementarla, la rete deve essere
ripensata in modo da risultare maggiormente efficiente.


-[ 5 Freenet

Freenet e' un sistema per lo storage distribuito e il prelievo di
informazioni progettato per risolvere i problemi legati alla privacy degli
utenti e alla sopravvivenza dei dati. Il sistema realizza un filesystem
location-independent distribuito attraverso molti nodi paritetici che donano le
proprie risorse hardware per permettere di inserire, memorizzare e prelevare in
modo anonimo i file, ma senza garantire che i dati rimangano permanentemente
nello storage.
  Gli obiettivi primari di Freenet sono cinque:

o Garantire l'anonimato degli utenti che producono e consumano l'informazione.
o Permettere agli operatori dei nodi di esercitare la negazione plausibile di
  responsabilita' (plausible deniability).
o Impedire la censura dei documenti ad opera di terze parti.
o Memorizzare e distribuire documenti in maniera efficiente.
o Decentralizzare tutte le funzioni di rete, eliminare qualsiasi single point
  of failure o di controllo centralizzato.

  Freenet e' descritta nella pubblicazione "A distributed decentralized
information storage and retrieval system" redatto da Ian Clarke nel Luglio 1999
quando si trovava come studente presso l'Universita' di Edinburgh in Scozia.
Freenet e' un Free Software rilasciato sotto licenza GPL e scritto in
linguaggio Java, pubblicamente distribuito per la prima volta in versione 0.1
nel Marzo 2000.
  La metodologia impiegata nello sviluppo di questo programma ricalca
l'architettura distribuita e decentralizzata della rete stessa: i principali
componenti del team (Ian Clarke, Matthew Toseland, Oskar Sandberg, Florent
Daignie're e Scott Miller) collaborano da molti Paesi diversi del mondo in modo
delocalizzato attraverso Internet. Il progetto fa affidamento in gran parte
all'impegno volontaristico di queste persone e alle donazioni degli utenti; i
finanziamenti piu' significativi sono stati erogati da John Gilmore
dell'Electronic Frontier Foundation e da Google nell'ambito dei Summer Of Code.
  Attualmente le versioni di Freenet che gli utenti possono utilizzare sono
due:

o Freenet Light: versione stabile (ramo 0.5, ultima release del Settembre
  2005), trattata nella sezione 5.1 di questo testo.
o Freenet Dark: versione in sviluppo (ramo 0.7, ultima release del Settembre
  2006), discussa separatamente nella sezione 5.2 dal momento che costituisce
  un radicale cambiamento di design della rete.

  Il codice sorgente di Freenet e' consultabile online presso [34].


--[ 5.1 Freenet Light


---[ 5.1.1 Panoramica

Freenet consiste di un insieme di nodi che scambiano tra di loro messaggi. Un
nodo e' semplicemente un calcolatore che sta eseguendo il software Freenet e
tutti i nodi della rete sono identici e trattati allo stesso modo. Ogni nodo
mette a disposizione una certa quantita' di spazio di memorizzazione per
mantenere una propria porzione locale del data store distribuito. Gli ideatori
di Freenet desiderano offrire a qualsiasi autore la possibilita' di pubblicare
i propri documenti a prescindere dalle sue disponibilita' finanziarie e di
spazio libero su disco e per questo motivo il sistema non richiede ne' di
condividere una soglia minima di memoria di massa ne' alcun pagamento per
fruire del servizio. Questo giustifica il fatto che Freenet non garantisce che
i documenti siano presenti in modo permanente nello storage ed implementa
invece una politica probabilistica per lo scarto dei file meno richiesti quando
e' necessario liberare spazio per l'inserimento di nuovi dati.
  I nodi di Freenet Light seguono il Freenet Network Protocol (FNP) per
organizzarsi spontaneamente in una configurazione di rete efficiente. In
Freenet Light pertanto i nodi stabiliscono automaticamente connessioni gli uni
con gli altri: una rete di questo tipo e' definita Opennet. Gli indirizzi dei
nodi sono composti da un metodo di trasporto ed un identificativo specifico a
livello di trasporto (tipicamente un indirizzo IP e un numero di porta), ad
esempio tcp/192.168.1.1:19114. Il FNP e' un protocollo packet-oriented basato
sullo scambio dei messaggi riportati in figura 5.1.

  Figura 5.1: Messaggi in Freenet Light.

  Ogni messaggio include i seguenti tre campi:

o UniqueID: 64 bit generati in modalita' casuale che consentono ai nodi di
  tenere traccia dello stato degli inserimenti e delle richieste.
o Hops-To-Live (HTL): valore intero impostato dal mittente di un messaggio e
  decrementato a ogni hop per prevenire l'inoltro infinito dei messaggi.
o Depth: valore intero incrementato ad ogni hop che consente al destinatario di
  un messaggio di impostare nella risposta un valore di HTL sufficientemente
  alto da raggiungere il mittente.

  Una transazione in Freenet ha inizio con l'invio di un messaggio
Request.Handshake da un nodo ad un altro, specificando quale indirizzo di
ritorno per il nodo mittente si desidera. Il nodo destinazione risponde con un
messaggio Reply.Handshake in cui indica il numero di versione del protocollo. I
nodi ricordano gli handshake per un certo periodo di tempo, durante il quale
comunicazioni successive tra gli stessi due nodi non necessitano ripetere la
fase di handshake.
  I messaggi Request.Data, Send.Data e Reply.NotFound sono legati ai meccanismi
di richiesta dei file dal data store descritti in sezione 5.1.3.
  I messaggi Reply.Insert e Send.Insert permettono di pubblicare documenti come
spiegato in sezione 5.1.4.


---[ 5.1.2 Protezione dei dati: chiavi

In Freenet ogni documento e' identificato da una chiave binaria ottenuta
applicando la funzione di hash SHA-1 a 160 bit. Freenet definisce un Uniform
Resource Indicator (URI) nella forma seguente:

freenet:keytype@data

dove il dato binario e' codificato usando una variante dello schema Base64. 
Ogni tipo di chiave interpreta a suo modo la parte data dell'URI, la cui
spiegazione e' quindi legata al keytype.
  In Freenet Light si possono usare tre tipi di chiavi per indicizzare un
documento:

o Keyword-Signed Key (KSK).
o Signed-Subspace Key (SSK).
o Content-Hash Key (CHK).


----[ 5.1.2.1 Keyword Signed Key (KSK)

Il tipo piu' semplice di chiave e' la KSK, viene derivata da una breve
stringa di testo facile da ricordare (ad esempio text/books/1984.html) scelta
dall'utente al momento della pubblicazione di un file nel data store
distribuito ed appare cosi':

freenet:KSK@text/books/1984.html

  Figura 5.2: Schema di generazione di una KSK.

  La figura 5.2 illustra il procedimento di creazione di una chiave KSK:

o si calcola l'hash SHA-1 della stringa descrittiva;
o si utilizza il valore di hash della stringa descrittiva come chiave privata;
o a partire dalla chiave privata si genera una chiave pubblica secondo il
  Digital Signature Algorithm (DSA);
o si ottiene la chiave KSK associata al file inserito calcolando l'hash SHA-1
  della chiave pubblica.

  La chiave privata e' utilizzata per firmare il digest del file inserito, in
modo da offrire un controllo minimo di integrita' garantendo che un documento
ritirato corrisponda alla sua chiave KSK associata. Il documento e' inoltre
cifrato in modalita' simmetrica usando proprio la stringa descrittiva come
chiave.
  Per permettere agli altri di ritirare un documento, chi inserisce il file
deve pubblicare la relativa stringa descrittiva; questo risulta evidente se si
percorre a ritroso il diagramma di figura 5.2 dal blocco "Chiave KSK del file":
e' sufficiente conoscere la stringa descrittiva per calcolare la chiave KSK che
identifica il file.
  Nonostante il formato convenzionale di una KSK ricordi l'organizzazione in
directory di un filesystem, questo non deve indurre a pensare che in Freenet vi
sia una gerarchia all'interno del data store: in Freenet non esiste una
gerarchia dei documenti.
  Un documento inserito tramite KSK apparira' sui nodi nel data store come una
chiave binaria seguita da dati opachi (firma digitale e file cifrato).
L'operatore di un nodo non puo' ricostruire la stringa di testo descrittiva
dalla chiave binaria dal momento che e' ottenuta calcolando l'hash della chiave
pubblica DSA della stringa e l'operazione non e' invertibile; d'altra parte
allora non puo' neppure risalire al contenuto del file perche' esso e'
simmetricamente cifrato usando per chiave la stringa descrittiva.
  Le KSK sono tuttavia il tipo piu' debole di chiave perche' la stringa di
testo viene scelta per essere facilmente memorizzabile da un utente ed e'
formata da una concatenazione di parole di senso compiuto; un attaccante puo'
sfruttare questa peculiarita' della stringa per sferrare un attacco brute-
force: con un nodo ostile genera molte stringhe comuni fino a quando trova
quella che produce la KSK vittima ed a questo punto e' in grado di inviare
false risposte quando riceve richieste per quella KSK. Inoltre nulla vieta a
due utenti di scegliere in modo indipendente la stessa stringa descrittiva per
pubblicare file diversi e quindi un attaccante puo' eseguire un attacco di key-
squatting in cui inserisce molti dati fasulli indicizzati da descrizioni
popolari provocando collisioni al momento di richiesta dei documenti.


----[ 5.1.2.2 Signed-Subspace Key (SSK)

Le SSK si basano sullo stesso sistema a chiave pubblica DSA delle KSK, ma sono
puramente binarie in quanto non sono derivate dalla sola stringa descrittiva
human-readable.
  Per risolvere i problemi propri dell'impiego delle KSK, le SSK consentono la
gestione di namespace (detti anche subspace) personali per controllare un
insieme di chiavi. Un utente definisce un proprio personale namespace generando
in modo casuale un paio di chiavi pubblica/privata che serviranno da
identificativo.

  Figura 5.3: Schema di generazione di una SSK.

  La figura 5.3 illustra il procedimento di creazione di una chiave SSK per
inserire un file:
                      
o si sceglie una breve stringa descrittiva come nel caso delle KSK;
o si calcolano separamente l'hash della chiave pubblica del namespace e l'hash
  della stringa descrittiva;
o si esegue sui due valori di hash ottenuti l'operazione XOR;
o si applica l'hash SHA-1 al risultato per ottenere la chiave binaria SSK del
  documento.

  In analogia con le KSK, si usa la meta' privata della coppia di chiavi
asimmetriche per firmare il documento. Questa firma, ottenuta da un paio di
chiavi generate in modalita' pseudo-casuale dall'utente che pubblica il file,
e' piu' sicura di quella usata nelle KSK dal momento che in quel caso le chiavi
erano derivate in modo deterministico a partire dalla sola stringa descrittiva.
Il documento e' anche cifrato servendosi della stringa descrittiva come chiave,
come gia' visto per le KSK.
  Per consentire agli altri di prelevare un documento, chi pubblica rende note
la stringa descrittiva insieme alla chiave pubblica del subspace: percorrendo a
ritroso il diagramma di figura 5.3 dal blocco "Chiave SSK del file" si vede
come a partire da queste sole due informazioni sia possibile ottenere la chiave
SSK che identifica il file. L'inserimento del documento invece richiede la
conoscenza della chiave privata e pertanto solo il proprietario del subspace
puo' aggiungere o modificare i file in esso contenuti.
  Il meccanismo impiegato nelle SSK permette di raggiungere due obiettivi
importanti. In primo luogo con le SSK un utente ora puo' organizzare un proprio
namespace in cui simulare ad esempio una struttura gerarchica dei documenti e
creare tramite un'opportuna sintassi interpretabile dai client file simili a
directory che contengono metadati che puntano ad altri file. Ad esempio una
directory inserita sotto la chiave text/cryptome potrebbe includere una lista
di chiavi come text/cryptome/freedom-of-speech, text/cryptome/cryptography e
text/cryptome/surveillan ce che a loro volta sono liste di chiavi che
corrispondono a documenti.
  Il secondo significativo risultato e' conseguenza del primo: se un utente
puo' creare un proprio sottospazio e controllare un insieme di chiavi, allora
e' in condizione di mantenere un proprio pseudonimo su Freenet. Quando gli
utenti si fidano del proprietario di un namespace, si fidano anche dei
documenti in esso contenuti e nel contempo l'anonimato di chi pubblica rimane
protetto.
  La possibilita' di fidarsi delle pubblicazioni di un utente anonimo rende
vani attacchi di key-squatting in cui la rete viene inondata di falsi documenti
(problema presente in sistemi per il file sharing che non godono di fiducia
anonima come Gnutella e Napster).
  Una URI di SSK appare cosi':

freenet:SSK@U7MyLlomHrjm6443k1svLUcLWFUQAgE/text/books/1984.html


----[ 5.1.2.3 Content Hash Key (CHK)

  La CHK di un documento e' semplicemente ottenuta calcolando direttamente
l'hash del contenuto del file, come illustra la figura 5.4. Dal momento che la
funzione di hash e' tale da rendere computazionalmente molto difficile trovare
due input che forniscano lo stesso output, la chiave CHK costituisce un
identificativo pseudo-unico di ogni file.

  Figura 5.4: Schema di generazione di una CHK.

  Il dato inoltre e' cifrato con una chiave generata in modalita' casuale.
Affinche' gli altri utenti possano prelevare e visualizzare il documento, chi
inserisce il file deve pubblicare insieme alla sua CHK anche la chiave
simmetrica per la decrittazione. Anche in questo caso la chiave di cifratura
non viene mai memorizzata sui nodi insieme al documento, ma solo pubblicata
insieme alla CHK binaria.
  Dal momento che un documento e' inviato in risposta ad una richiesta che
include la sua CHK, un nodo e' in grado di verificare l'integrita' dei dati
eseguendo un redundancy check tra message digest e CHK contenuta nella
richiesta: se i valori di hash coincidono allora il documento e' quello
corretto. Le CHK forniscono una chiave unica e inalterabile e per questo la
maggior parte dei dati in Freenet sono memorizzati sotto una CHK. Le CHK
inoltre riducono la ridondanza delle informazioni perche' dati uguali avranno
la medesima CHK e al momento dell'inserimento si verifichera' una collisione.
  Servendosi sia delle CHK che delle SSK si ottiene un sistema che unisce i
benifici di entrambe: e' possibile verificare l'integrita' dei documenti
ritirati e fidarsi di chi li ha pubblicati, anche se questi rimane anonimo e
protetto da uno pseudonimo. Per pubblicare un documento con una CHK congiunta
ad una SSK (lo stesso vale per una KSK, nel caso non interessi l'aspetto di
fiducia anonima) il client e' in grado di attuare un meccanismo di indirezione:
pubblica il file sotto una CHK e poi inserisce una SSK che ridirige a quella
CHK.
  L'URI di una CHK appare cosi':

freenet:CHK@DtqiMnTj8YbhScLp1BQoW9In9C4DAQ,2jmj7l5rSwOyVb-vlWAYkA


----[ 5.1.2.4 Osservazioni sulle chiavi

  Si e' visto come tutti i documenti in Freenet sono crittografati prima
dell'inserimento. La chiave e' sia casuale che distribuita dal richiedente
insieme all'URI (CHK) o basata su dati che il nodo non puo' conoscere (ad
esempio la stringa di una KSK o SSK). In ogni caso un nodo non puo' sapere
quali informazioni siano contenute in un documento. Questo ha due conseguenze:
in primo luogo gli operatori dei nodi non possono impedire ai propri nodi di
memorizzare in cache o inoltrare contenuti per loro indesiderabili perche' non
hanno nessun modo per dire che cosa contenga un documento; il secondo effetto
e' che l'amministratore di un nodo non puo' ritenersi responsabile dei dati
presenti sul suo nodo (plausible deniability).
  La verifica di integrita' dei documenti e' offerta sia dalla corrispondezza
tra message digest del file e chiave binaria (CHK), sia dalla verifica della
firma DSA (KSK e SSK).


---[ 5.1.3 Anonimato di chi accede ai dati: richieste

  Un utente, per ritirare un file dal data store distribuito di Freenet, deve
conoscere o calcolare la chiave binaria del file. Quindi deve inviare una
richiesta in cui specifica la chiave desiderata e il numero di Hops-To-Live. Le
richieste sono messaggi Request.Data che possono essere inoltrati attraverso
numerosi nodi diversi. All'inizio un utente spedisce la richiesta a un nodo a
lui noto e di cui si fida (solitamente questo nodo e' in esecuzione sul suo
stesso calcolatore).
  Quando un nodo riceve una richiesta, controlla se possiede nel proprio data
store locale il documento cercato e in caso positivo lo invia come risposta in
un messaggio Send.Data indicando se stesso come sorgente dei dati nel campo
DataSource. Se al contrario il nodo non dispone del documento richiesto allora
cerca nella sua tabella di routing la chiave piu' "vicina" (in base alla
distanza lessicografica) a quella desiderata e inoltra la richiesta al nodo
associato a tale chiave.
  In questo modo i messaggi vanno a formare una catena dal momento che ogni
nodo inoltra la richiesta al prossimo nodo. Il meccanismo di conteggio degli
Hops-To-Live, simile al Time-To-Live dei datagrammi IP, fa scadere i messaggi
dopo aver attraversato un certo numero di nodi, cosi' si limita la lunghezza
massima di una catena. La catena di messaggi termina quando un messaggio scade
oppure quando un nodo risponde col documento richiesto.
  Se la richiesta viene completata con successo, il documento viene inviato
percorrendo a ritroso la catena formata dai nodi che avevano precedentemente
inoltrato la richiesta, fino a raggiungere il nodo iniziale. Ogni nodo della
catena puo' memorizzare una copia della risposta nella sua porzione locale del
data store, cosi' potra' rispondere immediatamente a qualsiasi futura richiesta
per quello specifico documento; inoltre ogni nodo inserisce nella sua tabella
di routing una nuova entry in cui associa la chiave richiesta con l'attuale
sorgente di risposta. Questo significa che i documenti ritirati piu'
frequentemente sono memorizzati nelle cache di molti nodi e si evita un
sovraccarico dell'unico server che inizialmente ha pubblicato il documento
richiesto.
  Questo sistema fa si' che una richiesta successiva per la medesima chiave
venga soddisfatta piu' rapidamente (perche' il documento e' ora presente in
molti data store locali); richieste di chiavi "vicine" (ovvero di ridotta
distanza lessicografica) verranno instradate con probabilita' alta verso una
medesima sorgente di dati.
  La risposta ad una richiesta contiene un indirizzo di uno dei nodi che ha
attraversato, cosi' col tempo i nodi possono acquisire informazioni a proposito
di altri nodi. Questo significa che l'interconnessione dei nodi della rete
Freenet aumenta col trascorrere del tempo. In questo modo a un nodo puo'
accadere di ricevere dati da un nodo sconosciuto: ogni nodo ottiene
informazioni solo riguardo ai nodi con cui scambia messaggi direttamente e al
piu' un altro nodo della catena, ma nel momento in cui riceve una risposta ad
una richiesta e' possibile che non sia ancora a conoscenza del nodo che
risponde. Tuttavia mantenere sui nodi una tabella delle sorgenti dei dati
costituirebbe un potenziale rischio per la sicurezza e per evitarlo ogni nodo
della catena puo' arbitrariamente decidere di cambiare il messaggio di risposta
per dichiarare se' stesso o un altro nodo scelto a caso come sorgente dei dati.
  Se un nodo non puo' inoltrare una richiesta al nodo associato alla chiave
piu' vicina perche' la destinazione e' irraggiungibile o si verrebbe a creare
un ciclo infinito, provera' a inviare al nodo la cui chiave e' seconda in
ordine di vicinanza, eventualmente al terzo e via di seguito. Se un nodo
esaurisce tutti i candidati a cui inviare la richiesta, riportera' in un
messaggio Reply.NotFound la notifica di fallimento al nodo che lo precede nella
catena, il quale tentera' di inoltrare la richiesta al suo secondo nodo piu'
vicino alla chiave desiderata, e cosi' via. In questo modo, il meccanismo di
richiesta opera come una ricerca steepest-ascent-hill-climbing [35] con
backtracking. Se si eccede il limite di Hops-To-Live, viene propagata a ritroso
per tutta la catena una notifica di fallimento fino all'origine della
richiesta, senza provare altri nodi.

  Figura 5.5: Routing in Freenet

  Il sistema di routing di Freenet basato sulle chiavi e' sintetizzato nella
figura 5.5, dove viene illustrata una tipica sequenza di messaggi di richiesta.
Un utente avvia una richiesta al nodo a. Il nodo a inoltra la richiesta al nodo
b, che a sua volta la spedisce al nodo c. Il nodo c non e' in grado di
contattare altri nodi e risponde a b con un messaggio di fallimento. Il nodo b
a questo punto tenta con la sua seconda scelta, e, che inoltra la richiesta a
f. Il nodo f invia la richiesta a b, che rileva il loop e ritorna un messaggio
di fallimento. Il nodo f non puo' contattare alcun altro nodo e restituisce il
controllo ad e. Il nodo e inoltra la richiesta alla sua seconda scelta, d, che
possiede il dato sul proprio data store locale. Il documento e' inviato in
risposta da d attraverso e e b fino ad a, il quale la spedisce all'utente. Il
dato a questo punto e' stato memorizzato anche nelle cache di e, b ed a.
  Dal momento che un nodo non e' in grado di vedere il cammino percorso da una
richiesta al di la' del nodo che gliel'ha direttamente inoltrata, e' molto
difficile individuare la persona che ha avviato la richiesta. Questo meccanismo
di inoltro e caching tra i nodi offre pertanto l'anonimato per gli utenti che
ritirano documenti da Freenet.


---[ 5.1.4 Anonimato di chi pubblica i dati: inserimenti

L'inserimento di un documento in Freenet segue una strategia parallela a
quella delle richieste. Per inserire un file, l'utente prima calcola una
corrispondente chiave binaria applicando una delle procedure descritte nella
sezione 5.1.2. Quindi invia un messaggio di inserimento Request.Insert al nodo
in esecuzione sul proprio calcolatore in cui specifica la chiave binaria
proposta e un certo valore per il campo HTL (questo indichera' il numero di
nodi in cui si vuole memorizzare il documento).
  Quando un nodo riceve una proposta di inserimento, per prima cosa verifica se
nel proprio data store locale la chiave e' gia' utilizzata. Se trova la chiave
binaria, allora il nodo manda per risposta il file preesistente per quella
chiave in un messaggio Send.Data, proprio come se avesse ricevuto una richiesta
per quel documento. In questo modo l'utente viene a sapere che si e' verificata
una collisione e puo' riprovare usando una chiave diversa. Se il nodo che ha
ricevuto la richiesta non ha invece trovato una chiave locale preesistente
allora individua la chiave piu' vicina nella sua tabella di routing e inoltra
la richiesta di inserimento al nodo corrispondente. Se questo messaggio di
inserimento causa una collisione il nodo riceve il documento preesistente, si
comporta come se fosse stata effettuata una richiesta (cioe' memorizza
localmente il file e crea una entry per la sorgente dei dati nella tabella di
routing) e trasmette a ritroso i dati al suo predecessore nella catena degli
inserimenti.
  Se viene raggiunto il limite di HTL senza che si rilevi alcuna collisione di
chiave, viene propagato un messaggio Reply.Insert all'indietro fino all'utente
che ha avviato l'inserimento: questa condizione indica che tutto e' pronto per
effettuare l'inserimento vero e proprio.
  A questo punto l'utente manda in un messaggio Send.Insert i dati da inserire
che verranno propagati attraverso il percorso stabilito dalla richiesta
iniziale di inserimento e saranno memorizzati in ogni nodo del cammino.
  Ciascun nodo crea anche una entry nella sua tabella di routing in cui associa
la sorgente dei dati, cioe' chi inserisce, con la nuova chiave. Come nel caso
delle richieste, ogni nodo della catena puo' decidere in modo unilaterale di
cambiare il messaggio di inserimento per annunciare se' stesso o un altro nodo
scelto arbitrariamente come sorgente dei dati.
  Se un nodo non puo' inoltrare un inserimento al suo nodo preferito giu' lungo
la catena perche' la destinazione e' irraggiungibile o si verrebbe a creare un
loop, il nodo che sta inserendo prova a inviare al nodo associato alla seconda
chiave piu' vicina, quindi alla terza, e cosi' via con le stesse modalita' di
backtracking viste nella sezione precedente per le richieste. Se la procedura
di backtracking ritorna indietro fino ad arrivare all'utente che ha inserito
per primo il file, questo indica che e' stato possibile contattare meno nodi di
quelli desiderati. Come per le richieste, i nodi possono ridurre valori
eccessivi di HTL ed eventualmente ignorare inserimenti che rimangono in coda di
attesa per un periodo di tempo eccessivo.
  Analogamente al caso delle richieste, anche per quanto riguarda gli
inserimenti un nodo non e' pertanto in grado di vedere il cammino percorso da
un inserimento al di la' del nodo che gliel'ha direttamente inoltrato ed e'
molto difficile individuare la persona che ha inserito il dato in rete.
  Gli utenti che pubblicano documenti in Freenet, oltre che rimanere anonimi
grazie al meccanismo appena visto di inoltro e caching tra i nodi, possono
usare le chiavi SSK per gestire i propri pseudonimi e realizzare un modello di
fiducia anonima degli utenti che ricevono i dati nei confronti di chi li
pubblica.


---[ 5.1.5 Resistenza alla cancellazione da parte di terzi

Il tentativo di cancellare un documento dal data store di Freenet puo' essere
condotto in parallelo su due fronti:

o In rete attraverso l'impiego di nodi ostili controllati dall'attaccante che
  lavorano per "spingere" al di fuori del data store distribuito i dati da
  censurare.
o Localmente eliminando il file dai data store locali dei nodi su cui e'
  memorizzato.

  Per impedire la censura delle informazioni pubblicate, Freenet implementa una
combinazione di soluzioni a diversi livelli del sistema:

o Politica di gestione dello spazio di storage.
o Dispersione e replicazione del documento.
o Negazione plausibile di responsabilita' da parte dell'operatore del nodo.


----[ 5.1.5.1 Politica di gestione dello spazio di storage

  Freenet non mira a offrire un servizio di data store permanente e quindi
tutte le informazioni inserite devono confrontarsi con la capacita' di storage
limitata della rete. Gli operatori dei nodi decidono in fase di configurazione
quanto spazio su disco offrire al data store distribuito.
  I documenti memorizzati nello storage locale di un nodo sono gestiti secondo
un algoritmo di caching Least Recently Used (LRU) in cui i documenti sono
mantenuti in ordine decrescente in base al tempo dell'ultima richiesta ricevuta
per essi (o in base al tempo di inserimento, se un file non e' ancora mai stato
richiesto). In questa struttura dati simile ad uno stack, illustrata in figura
5.1, ogni chiave binaria di cui il nodo e' a conoscenza e' associata in una
entry al relativo documento nel data store locale e al corrispondente indirizzo
sorgente.
   
   Chiave                   Dato                     Indirizzo
  -----------------------------------------------------------------------
  8e0109xb87wkhkujhs98k    99usbkjhgd7333khjgs763   tcp/5.34.27.4:6473
  uushs89763kjhx7w732722   yy6254231gsyw4GGcwhgs    tcp/89.34.36.1:24855
  kjhks872228x0982876jjhd  TTRos384hgygduybv1111n   tcp/194.44.62.66:9897
  878772kx762776xbv8622                             tcp/64.28.67.48:43653
  222764kjhx8f63wkbkjs77w                           tcp/4.18.49.35:65466
  57765xkjhd72729jnbck01kj                          tcp/55.18.4.1:3895

  Tabella 5.1: Chiavi note ad un nodo

  Una copia dei documenti richiesti con maggiore frequenza e' pertanto
memorizzata nel data store locale al nodo e le relative entry sono spostate
verso la cima dello stack mentre quelle dei file meno richiesti vengono scalate
verso la base. Per incentivare gli utenti a comprimere i file prima di
inserirli in Freenet, le entry dei documenti si muovono sullo stack di una
distanza variabile legata alla dimensione del dato: i documenti piu' grandi
sono penalizzati e percorrono sullo stack una distanza minore di quella dei
documenti di piccole dimensioni. Al di sotto di una certa posizione nello stack
il nodo non memorizza piu' in locale i dati accoppiati ad una chiave, ma solo
l'indirizzo sorgente ad essa associato, di fatto elimininandoli dal nodo.
  Il metodo per scartare i dati impiegato in Freenet ha quindi l'effetto di
rimuovere i documenti meno richiesti (cioe' per i quali si e' registrata una
bassa quantita' di richieste da parte degli utenti), non quelli piu' impopolari
(cioe' quelli sgraditi a molte persone). Se fossero i dati piu' impopolari ad
essere rimossi, allora questo potrebbe essere usato per censurare i documenti.
Il design di Freenet e' molto attento affinche' questo sia evitato.
  Questo modello fa in modo che lo scarto di un documento dal data store di un
nodo sia un'azione intrapresa individualmente dal nodo stesso in base alle
richieste che ha veicolato; nel protocollo di rete Freenet non esiste alcun
messaggio per cancellare un file dal data store: un documento non puo' essere
volontariamente rimosso da Freenet neppure dall'utente che l'ha inserito e
questo rende vano qualsiasi attacco censorio nei confronti di chi ha pubblicato
documenti.
    Se un autore vuole assicurarsi che un documento permanga in Freenet, tutto
quello che deve fare e' richiederlo o reinserirlo molto spesso.


----[ 5.1.5.2 Dispersione e replicazione del documento

Nonostante tutti questi accorgimenti, la capacita' limitata di contenere
informazioni rende Freenet vulnerabile ad un attacco in cui la rete venga
inondata di documenti spazzatura allo scopo di cancellare quelli presenti.
L'algoritmo di routing key-based impiegato in Freenet fornisce una certa
resilienza a un attacco di questo tipo. Infatti i nuovi file vengono segregati
in prossimita' dei nodi che li inseriscono: in questo modo la parte di Freenet
rimanente non viene interessata dall'inondazione e le informazioni in essa
presenti non vengono cancellate.
  Le chiavi che guidano il meccanismo di inoltro e caching dei documenti sono
hash e quindi file simili nel contenuto o nella stringa di descrizione o
appartenenti a uno stesso subspace saranno associati a chiavi binarie non
correlate tra loro: le chiavi non trasportano informazioni sul contenuto
semantico dei relativi documenti. Questo significa che documenti che trattano
argomenti simili saranno sparsi su nodi diversi e lontani nella rete e per un
censore non sara' sufficiente agire contro un sin


----[ 5.1.5.3 Plausible deniability per l'operatore del nodo

Si e' visto quanto Freenet renda difficile individuare su quali nodi sia
presente un documento, ma si immagini ora che un attaccante abbia comunque
localizzato tali nodi. Per far fronte a questa evenienza, Freenet e' progettata
per ampliare al massimo la negazione plausibile di responsabilita' da parte di
chi la usa.
  Come spiegato in sezione 5.1.2.4, tutti i file memorizzati su un certo nodo
sono crittografati e quindi inaccessibili al suo operatore a meno che egli non
conosca le chiavi di richiesta e di cifratura. Inoltre la presenza di un dato
su uno specifico nodo puo' essere dovuta sia al suo inserimento o lettura, sia
allo spontaneo ed automatico funzionamento della rete Freenet, riducendo le
possibilita' che un operatore risulti legalmente perseguibile per contenuti
questionabili ospitati sul suo data store.
  In conclusione Freenet impedisce totalmente attacchi di tipo censorio
realizzati costringendo gli autori o gli operatori a cancellare documenti:
nessuno, neanche chi l'ha inserita, puo' volontariamente cancellare una
informazione da Freenet.


---[ 5.1.6 Ricerche sui dati

La messa a punto di un meccanismo che consenta agli utenti di cercare in rete
documenti di loro interesse, ma di cui non conoscono le relative chiavi e' un
problema aperto di Freenet. Nel web esistono alcuni soluzioni efficaci, ad
esempio l'impiego di siti spider che visitano i nodi e indicizzano i file
oppure il mantenimento di siti che ospitano elenchi di segnalibri. Tuttavia
questi approcci hanno la caratteristica di essere centralizzati e questo non
soddisfa appieno i requisiti di Freenet. Inoltre le chiavi binarie non
forniscono informazioni sul contenuto del corrispondente file e quindi
l'entita' migliore candidata a catalogare un documento e' soprattutto l'utente
che lo ha inserito.
  Un metodo semplice per realizzare un vero sistema di ricerca in Freenet
potrebbe consistere nel creare uno speciale subspace pubblico per inserirvi
chiavi che puntino indirettamente ad un documento. Quando gli autori pubblicano
i file, potrebbero inserire in rete anche varie chiavi che per indirezione
rimandino ai documenti e associno ad essi le relative parole chiave (keyword).
Ad esempio questo testo potrebbe essere inserito e indirettamente indicizzato
dalle chiavi keyword:anonimato e keyword:sicurezza.
  Il sistema consentirebbe a numerose chiavi binarie diverse di coesistere per
una stessa keyword (a differenza che per i file normali dove una chiave indica
un solo documento) e richieste per questa chiave ritornerebbero corrispondenze
multiple. Gestire un gran numero di file indiretti per le keyword piu' comuni
sarebbe tuttavia difficile perche' il meccanismo di routing le attrarrebbe
tutte sugli stessi nodi.


---[ 5.1.7 Vulnerabilita' ed attacchi

Per la sicurezza di Freenet l'obiettivo primario e' proteggere l'anonimato
degli utenti che richiedono e inseriscono i file. E' anche importante
proteggere l'identita' degli operatori che ospitano i nodi dove risiedono i
file. Anche se chiunque puo' in modo banale fare in modo che un nodo memorizzi
un file richiedendolo attraverso di esso, "identificando" quindi il nodo come
uno di quelli che ospitano il file, cio' che e' importante e' che rimangono pur
sempre altri nodi, non identificati, che mantengono il file: in tal modo un
avversario non puo' rimuovere un file attaccando tutti i nodi che lo ospitano
se non riesce a conoscerli tutti.
  I file devono essere protetti rispetto a modifiche malevole ed infine il
sistema deve essere resistente ad attacchi di tipo Denial-of-Service.
  Reiter e Rubin [36] presentano una utile tassonomia delle proprieta' di
comunicazione anonima su tre assi.
  Il primo asse e' il tipo di anonimato: sender anonimity (anonimato del
mittente) o receiver anonimity (anonimato del ricevente), che significano
rispettivamente che un avversario non puo' determinare chi ha originato il
messaggio o a chi e' stato inviato.
  Il secondo asse e' l'avversario in questione: un local eavesdropper (un
ascoltatore locale, in grado di monitorare il traffico in modalita' passiva),
un nodo ostile o un insieme di nodi ostili che collaborano o un web server (non
applicabile a Freenet).
  Il terzo asse e' il grado di anonimato, che cattura la forza di ogni tipo di
anonimato su uno spettro che spazia da absolute privacy (privacy assoluta: per
l'avversario non e' possibile neanche avvertire la presenza della
comunicazione) a provably exposed (comunicazione comprovatamente esposta:
l'avversario puo' provare chi siano mittente e destinatario). Di particolare
interesse su questo spettro sono i punti beyond suspicion (sotto sospetto) e
probable innocence (probabile innocenza). L'anonimato del mittente e' sotto
sospetto se, nonostante l'attaccante possa rilevare l'evidenza di un messaggio
inviato, il mittente non appare un candidato piu' probabile ad essere l'origine
di quel messaggio che ogni altro potenziale mittente del sistema. Una garanzia
di anonimato piu' debole e' la probabile innocenza: il mittente e'
probabilmente innocente, dal punto di vista dell'attaccante, se ogni mittente
appare con la stessa probabilita' tanto essere l'originatore del messaggio
quanto non esserlo. La figura 5.6 visualizza lo spettro che descrive il grado
di anonimato.

  Figura 5.6: Grado di anonimato

  Dal momento che la comunicazione in Freenet non e' diretta verso specifici
destinatari, l'anonimato del ricevente e' visto in modo piu' preciso come
anonimato dell'interrogazione (query anonymity), cioe' il nascondere la chiave
che sta venendo inserita o richiesta. Sfortunatamente, dal momento che il
routing dipende dalla conoscenza della chiave, l'anonimato della chiave non e'
possibile nello schema base di Freenet.
  Contro un ascoltatore locale non c'e' protezione per i messaggi tra l'utente
e il primo nodo contattato perche' la comunicazione avviene in chiaro per mezzo
dell'insicuro Freenet Client Protocol (FCP). Siccome il primo nodo contattato
puo' agire come un ascoltatore locale, il team di Freenet raccomanda che
l'utente usi solo un nodo sul proprio calcolatore come primo punto di ingresso
nella rete Freenet. I messaggi tra i nodi seguono il FNP e sono cifrati per
contrastare l'intercettazione passiva.
  Contro una collaborazione di nodi malevoli, l'anonimato del mittente e'
preservato sotto sospetto in quanto un nodo in una catena di una richiesta non
p