354 lines
5.6 KiB
Text
354 lines
5.6 KiB
Text
|
@freenetlogo.png
|
||
|
|
||
|
Cos'è Freenet?
|
||
|
|
||
|
Freenet:
|
||
|
• Rete peer-to-peer decentralizzata
|
||
|
• Protocollo di rete
|
||
|
|
||
|
Perchè Freenet?
|
||
|
• Rispettare la libertà di espressione
|
||
|
• Resistere alla censura
|
||
|
• Proteggere l'anonimato
|
||
|
|
||
|
# --- cenni storici, decidere se tenere tutto o tagliare
|
||
|
|
||
|
Cenni Storici
|
||
|
|
||
|
• Ideata da Ian Clarke nel 1999
|
||
|
• Fondazione nel 2001, paper di Clarke
|
||
|
• Nel paper, le basi di Freenet
|
||
|
|
||
|
Anonimato
|
||
|
→ Decentralizzazione
|
||
|
|
||
|
Idea:
|
||
|
• Dividere i dati in blocchi
|
||
|
• Cifrarli
|
||
|
• Distribuirli a tutti nodi della rete
|
||
|
|
||
|
Risultato:
|
||
|
• Nodi formano una cache distribuita
|
||
|
• Impossibile il client-server
|
||
|
|
||
|
Dal 2001: sviluppo continuo
|
||
|
• Cross-Platform
|
||
|
• Implementazione in Java
|
||
|
• Necessita solo di una JVM
|
||
|
|
||
|
2008: Freenet 0.7
|
||
|
• Riscrittura estensiva
|
||
|
• Opennet
|
||
|
• Darknet
|
||
|
# espandere il punto su TCP, magari togliere da qui e parlarne alla fine
|
||
|
• Supporta TCP e UDP
|
||
|
|
||
|
Stato attuale:
|
||
|
• FProxy: interfaccia web
|
||
|
• Supporto a OpenJDK
|
||
|
|
||
|
# --- Fine cenni storici, inizio architettura
|
||
|
|
||
|
Architettura
|
||
|
|
||
|
Freenet
|
||
|
→ Rete di nodi
|
||
|
|
||
|
Tutti i nodi sono uguali
|
||
|
• No gerarchie
|
||
|
• No central points of failure
|
||
|
|
||
|
Contenuti:
|
||
|
associati a chiavi
|
||
|
→ Key Based Routing
|
||
|
|
||
|
Storage:
|
||
|
condiviso in rete
|
||
|
→ Decentralized Storage
|
||
|
|
||
|
Comunicazione:
|
||
|
solo con nodi vicini
|
||
|
→ Small World Network
|
||
|
|
||
|
# --- KBR
|
||
|
Key
|
||
|
Based
|
||
|
Routing
|
||
|
|
||
|
Tre tipi di chiavi:
|
||
|
• KSK (Keyword Signed Key)
|
||
|
• SSK (Subspace Signed Key)
|
||
|
• CHK (Content Hash Key)
|
||
|
|
||
|
Le chiavi sono ottenute
|
||
|
applicando hash functions
|
||
|
(DSA, SHA256)
|
||
|
|
||
|
KSK non più utilizzata
|
||
|
(poco sicura)
|
||
|
|
||
|
SSK (DSA):
|
||
|
• Chiave asimmetrica (Pub/Priv)
|
||
|
• Indentifica un namespace
|
||
|
|
||
|
Un namespace
|
||
|
→ Un utente
|
||
|
|
||
|
Files associati a:
|
||
|
• Stringa descrittiva
|
||
|
• Namespace dell'uploader
|
||
|
|
||
|
SSK:
|
||
|
Sequenza di cifratura
|
||
|
1. Hash (pubkey)
|
||
|
2. Hash (descrizione)
|
||
|
3. XOR tra i due hash,
|
||
|
4. Hash (result)
|
||
|
5. Firma del file (chiave privata)
|
||
|
→ Risultato: File Key
|
||
|
|
||
|
CHK (SHA256):
|
||
|
• Hash diretto del file
|
||
|
• Chiave pseudo-unica
|
||
|
• Utili per file statici
|
||
|
(pdf, mp3, ...)
|
||
|
|
||
|
Upload
|
||
|
di Files
|
||
|
|
||
|
Un utente rende pubbliche:
|
||
|
• Stringa descrittiva
|
||
|
• Public namespace key
|
||
|
|
||
|
File caricati
|
||
|
→ Immutabili
|
||
|
|
||
|
Update tramite indirezione:
|
||
|
→ Sia CHK che SSK
|
||
|
|
||
|
Indirezione:
|
||
|
• File inserito sotto CHK
|
||
|
• CHK salvata in un file indiretto
|
||
|
• File indiretto inserito sotto SSK
|
||
|
|
||
|
Indirezione:
|
||
|
Ottenere un file
|
||
|
|
||
|
Il file viene ottenuto in due step:
|
||
|
1. SSK → CHK
|
||
|
2. CHK → File
|
||
|
|
||
|
Routing
|
||
|
|
||
|
Routing Table:
|
||
|
(Forwarding Table)
|
||
|
• Salvata in ogni nodo
|
||
|
• Associa chiavi e nodi
|
||
|
• Permette routing dinamico
|
||
|
|
||
|
Richieste
|
||
|
|
||
|
Una richiesta e' formata da:
|
||
|
• Hops-To-Live (HTL)
|
||
|
• ID pseudo-unico, casuale
|
||
|
|
||
|
Passaggio delle richieste:
|
||
|
catena di Proxy Requests
|
||
|
|
||
|
Ogni nodo decide
|
||
|
dove indirizzare la richiesta
|
||
|
(simile a IP)
|
||
|
|
||
|
Invio di una richiesta:
|
||
|
(utente)
|
||
|
1. Ottieni File Key
|
||
|
2. Invia richiesta al nodo
|
||
|
|
||
|
Ricezione di una richiesta:
|
||
|
(nodo)
|
||
|
1. File presente in storage?
|
||
|
Si: ritorna risultato all'upstream
|
||
|
No: forward della richiesta
|
||
|
|
||
|
Request Forwarding
|
||
|
• Richiesta mandata
|
||
|
al nodo piu' vicino
|
||
|
a quello cercato
|
||
|
|
||
|
Vicinanza:
|
||
|
• Distanza lessicografica
|
||
|
dalla File Key cercata
|
||
|
|
||
|
@./friends-nodes.png
|
||
|
|
||
|
Nodo piu' vicino
|
||
|
→ Nodo contenente
|
||
|
la chiave piu' vicina
|
||
|
a quella cercata
|
||
|
|
||
|
Risultato di una richiesta:
|
||
|
• Data not found / HTL expired
|
||
|
→ failure
|
||
|
• Data found
|
||
|
→ success
|
||
|
→ data cached
|
||
|
(per ogni nodo)
|
||
|
|
||
|
Il risultato e' restituito
|
||
|
lungo la catena di nodi
|
||
|
che ha mandato la richiesta
|
||
|
(Upstream)
|
||
|
|
||
|
@./requestseq.png
|
||
|
|
||
|
# -------------------------- Routing Adattivo
|
||
|
Analisi:
|
||
|
Routing Adattivo
|
||
|
|
||
|
Routing Adattivo:
|
||
|
• Richieste per
|
||
|
chiavi vicine
|
||
|
mandate verso
|
||
|
stessi nodi
|
||
|
|
||
|
Routing Adattivo:
|
||
|
• Replica trasparente
|
||
|
di dati piu' richiesti
|
||
|
|
||
|
Routing adattivo:
|
||
|
• Favorisce i nodi
|
||
|
che rispondono con successo
|
||
|
a piu' richieste,
|
||
|
guadagnando entry
|
||
|
nella Forwarding Table
|
||
|
|
||
|
Routing adattivo:
|
||
|
• Si creano link diretti
|
||
|
alle sorgenti dei dati
|
||
|
|
||
|
# ----------------------- DDS
|
||
|
Decentralized
|
||
|
Data
|
||
|
Storage
|
||
|
|
||
|
Ogni nodo
|
||
|
condivide
|
||
|
spazio locale
|
||
|
|
||
|
Lo spazio condiviso
|
||
|
e' dedicato esclusivamente
|
||
|
al data storage
|
||
|
|
||
|
Local storage
|
||
|
→ LRU Cache
|
||
|
(Least Recently Used)
|
||
|
|
||
|
LRU Cache:
|
||
|
• Ordina i dati salvati
|
||
|
in maniera decrescente
|
||
|
in base al ricevimento
|
||
|
delle richieste
|
||
|
|
||
|
Significa:
|
||
|
• I file piu' richiesti
|
||
|
in cima alla lista
|
||
|
|
||
|
Problema:
|
||
|
Come gestire una cache piena?
|
||
|
|
||
|
Soluzione:
|
||
|
• Drop-Tail approach
|
||
|
|
||
|
Drop-Tail:
|
||
|
• Files meno richiesti
|
||
|
eliminati dallo storage,
|
||
|
• Entry corrispondenti
|
||
|
rimangono nella
|
||
|
Forwarding Table
|
||
|
|
||
|
Mantenere le entry
|
||
|
→ Evitare la perdita
|
||
|
di file poco richiesti
|
||
|
(Probabilita' che vengano
|
||
|
salvati in cache di nuovo)
|
||
|
|
||
|
Vantaggi:
|
||
|
• Performance migliora
|
||
|
nel tempo
|
||
|
• Update di files
|
||
|
trasparente
|
||
|
|
||
|
File Update:
|
||
|
• Files "vecchi" rimpiazzati da
|
||
|
files aggiornati in automatico
|
||
|
• Files "vecchi" ma ancora in uso
|
||
|
sono preservati dalle richieste
|
||
|
|
||
|
Data
|
||
|
Encryption
|
||
|
|
||
|
Necessita':
|
||
|
• Operatori di nodi
|
||
|
non devono conoscere
|
||
|
i dati salvati
|
||
|
|
||
|
Soluzione:
|
||
|
File Encryption
|
||
|
|
||
|
File Encryption:
|
||
|
• Utilizza chiavi (SSK, CHK)
|
||
|
• Utente puo' conoscere solo la File Key
|
||
|
(Invertire l'hash e' complesso)
|
||
|
• Dictionary attack puo' avere successo
|
||
|
ma e' estremamente costoso
|
||
|
|
||
|
Freenet:
|
||
|
Protocollo
|
||
|
|
||
|
Protocollo:
|
||
|
• P2P adattivo
|
||
|
(rete di nodi)
|
||
|
• Packet-oriented
|
||
|
• Self-contained
|
||
|
messages
|
||
|
|
||
|
Ogni messaggio
|
||
|
contiene un ID
|
||
|
della transazione
|
||
|
→ Insert, request
|
||
|
sono tracciabili
|
||
|
|
||
|
Trasporto:
|
||
|
Grande flessibilita',
|
||
|
principalmente:
|
||
|
• TCP
|
||
|
• UDP
|
||
|
|
||
|
I nodi che utilizzano
|
||
|
connessioni persistenti
|
||
|
(TCP)
|
||
|
possono mandare
|
||
|
piu' di un messaggio
|
||
|
sulla stessa connessione
|
||
|
|
||
|
Naming Prefix:
|
||
|
Utilizza ARK
|
||
|
(Address Resolution Keys)
|
||
|
• Chiavi SSK
|
||
|
aggiornate all'indirizzo
|
||
|
corrente del nodo
|
||
|
(semplifica la mobilita')
|
||
|
|
||
|
# ----------------------- SWN
|
||
|
|
||
|
Small
|
||
|
World
|
||
|
Network
|
||
|
|
||
|
Il mondo è piccolo
|
||
|
|
||
|
@./darknet_peers.png
|
||
|
|
||
|
|
||
|
?
|