Sicurezza nella fase di routing

Il sistema di sicurezza nella fase di storage garantisce, entro certi limiti, l’integrità dei dati immagazzinati. Il sistema di sicurezza nella fase di routing, invece, si concentra sul bloccaggio degli attaccanti in riferimento ad attacchi di tipo DOS (Denial of Service) sul sistema, che si basano su di un reinstradamento, naturalmente scelto dall’attaccante, dei messaggi e quindi non corretto per il sistema.

Ci sono alcune semplici osservazioni legate a questo attacco:

• è facile ‘imbrogliare’ il sistema facendogli credere che un attaccante sia un peer valido;

• nel caso in cui una larga percentuale di peer nell’overlay è corrotta, con molta probabilità sarà impossibile proteggere perfettamente il sistema da attacchi di tipo DOS;

I meccanismi di sicurezza nella fase di routing del protocollo RELOAD sono stati disegnati per contenere più che per eliminare attacchi, ed è quindi comunque possibi- le per un attaccante effettuare un’ampia varietà di attacchi. Lo schema di sicurezza basato sul certificato rende sicuro il namespace, ma se un peer nell’overlay fosse com- promesso o l’attaccante ottenesse un certificato, il sistema potrebbe essere irrimedia- bilmente corrotto.

3.4. CONSIDERAZIONI SULLA SICUREZZA

In generale, gli attacchi al routing di tipo DHT (Distributed Hash table) sono attuati dall’attaccante in modo da instradare il traffico attraverso i nodi da lui controllati; questi particolari attacchi, come analizzato in [8], sono particolarmente efficienti in sistemi P2PSIP, e devono quindi essere analizzati molto attentamente. Gli attacchi di questo tipo più dannosi sono l’attacco Sybil e l’attacco Eclipse. Come verrà trattato in dettaglio nei capitoli seguenti, in un Sybil Attack l’attaccante registra un ampio numero di nodi ed in questo modo può essere in grado di catturare un ampio volume di traffico; in un Eclipse Attack, invece, l’attaccante, tramite la manomissione delle tabelle di instradamento, può riuscire ad aumentare il volume di traffico controllato ovvero rispetto all’attacco Sybil, che rappresenta comunque un punto di partenza, riuscirà a catturare una percentuale di chiavi maggiore con un costo computazionale meno elevato. Questi attacchi sono limitati dall’utilizzo di un controllo di ammissione centralizzato e basato su certificati, anche se queste soluzioni allontanano il sistema dal paradigma P2P puro.

Controllo di Ammissione

L’ammissione, nel protocollo RELOAD, è controllata tramite la richiesta che ogni peer abbia un certificato contenente il suo peer ID; questa richiesta è rinforzata dall’utilizzo di un’autenticazione mutua basata su certificati ad ogni connessione. In questo modo, ogni volta che un peer si connette ad un altro, ognuna delle due parti potrà controllare automaticamente che l’altra abbia un certificato adatto.

Questi peer ID vengono assegnati casualmente dal server centrale di iscrizione e questo porta a due benefici:

• permette al server di iscrizione di limitare il numero di peer ID assegnati allo stesso utente fornendo protezione contro l’attacco Sybil grazie alla limitazione della capacità del singolo nodo;

• evita che l’attaccante possa scegliere peer ID specifici e questo riesce a limitare l’effetto dell’attacco Eclipse, anche se non a prevenirlo completamente, in quanto l’attaccante non potrà porsi in posizioni strategiche all’interno dell’overlay;

Identificazione ed autenticazione di peer

In generale, non appena un peer inizia un’attività che può portare alla modifica della routing table, deve stabilire la sua identità. Nel momento in cui il peer stabilisce una connessione diretta con un altro, dovrà autenticarsi tramite un processo mutuo basato su certificati. In questo modo si viene a formare un canale protetto sul quale viaggeranno poi tutte le informazioni tra i peer ed uno qualsiasi potrà verificare la provenienza e la correttezza dei valori senza necessitare di meccanismi di cifratura. In alcuni casi, però, potrebbe essere necessario stabilire l’identità dei peer con i quali non si hanno connessioni dirette. Questa situazione, per esempio, potrebbe verificarsi

3.4. CONSIDERAZIONI SULLA SICUREZZA

nel momento in cui un peer aggiorna il suo stato; in questo caso, gli altri peer potreb- bero necessitare un aggiornamento della visualizzazione dell’overlay ma dovrebbero verificare che il messaggio di aggiornamento provenga dal peer e non da un attaccante; per questo motivo tutti i messaggi di routing dell’overlay vengono firmati dal peer che li ha generati.

Protezione della segnalazione

Lo scopo della protezione della segnalazione è quello di non permettere ad un attac- cante di scoprire il mittente ed il destinatario della segnalazione stessa, e possibilmente anche il contenuto.

Un attaccante potrebbe però essere in grado di osservare le attività di un gruppo di peer ed inoltre, siccome i messaggi potrebbero essere instradati utilizzando esclusiva- mente le informazioni del campo header, il corpo del messaggio RELOAD potrebbe essere cifrato durante la trasmissione.

Nascono allora due linee di difesa per controbattere questo problema; queste strate- gie non sono esclusive ma possono essere integrate per ottenere un miglior livello di sicurezza.

• Utilizzo di TLS (Transport Layer Security) o DTLS (Datagram TLS ) per ogni link di comunicazione tra peer; questo garantisce protezione contro attaccanti che non sono membri dell’overlay, ovvero attaccanti esterni.

• Utilizzo l’algoritmo di sicurezza certificate-based, ed in questo modo ogni mes- saggio può essere firmato; questo permetterà la protezione dei messaggi dalla modifica da parte di peer avversari, anche se fossero situati sul percorso di routing del messaggio stesso.

Tramite questi meccanismi di sicurezza, quindi, il protocollo RELOAD può riuscire a gestire varie problematiche legate principalmente all’implementazione della versione P2P di SIP.

Come detto già in precedenza, però, lo studio di questo protocollo e di conseguenza di tutto il P2PSIP usage, è ancora oggi ad uno stadio iniziale e quindi serviranno alcuni anni di sviluppo per riuscire ad osservare miglioramenti generali sul funzionamento e sullo sviluppo di tecniche di sicurezza.

Capitolo 4

Il protocollo Chord

Il protocollo Chord [9, 10] è un protocollo scalabile per la ricerca in sistemi P2P dinamici con frequenti arrivi ed uscite di nodi; esso supporta fondamentalmente un’o- perazione: data una chiave la assegna ad un nodo e permette poi la ricerca ottimizzata del nodo responsabile di una particolare chiave; inoltre, a seconda dell’applicazione che utilizza Chord, il nodo potrebbe essere responsabile della memorizzazione di un valore associato alla chiave.

In questo capitolo verrà analizzato nel dettaglio il protocollo Chord in quanto è con- siderato attualmente lo standard per la gestione del P2PSIP ed il suo funzionamento può essere visto come riferimento per uno scenario tipico d’utilizzo del protocollo RE- LOAD; è stato quindi interessante riuscire ad analizzare un protocollo semplificato rispetto alla struttura di usage classica che, come detto nel capitolo precedente, non è ancora stata standardizzata, in modo tale da riuscire ad effettuare varie misurazioni ricavando risultati coerenti anche per il protocollo RELOAD e quindi per la struttura di gestione del P2PSIP che diventerà lo standard nei prossimi anni.

4.1

Concetti preliminari

Il protocollo Chord semplifica il design di reti P2P generiche e di sistemi basati su di esse tramite l’indirizzamento di alcuni problemi complessi.

• Bilanciamento del carico; Chord fornisce una computazione veloce e distribuita di una hashing function per l’assegnamento delle chiavi ai nodi responsabili; con alta probabilità questa funzione di hash bilancia il carico, ovvero tutti i nodi ricevono all’incirca lo stesso numero di chiavi, ed inoltre, nel momento in cui l’N-esimo nodo entra (o esce) dalla rete, viene mossa esclusivamente una frazione O(1/N ) di chiavi in una diversa locazione, ovvero il minimo necessario per mantenere il bilanciamento del carico.