Anonimato in rete, che problema: perché non sempre è garantito e possibili soluzioni | Agenda Digitale

non solo tor

Anonimato in rete, che problema: perché non sempre è garantito e possibili soluzioni

L’anonimato in rete, che non serve soltanto a chi vuole macchiarsi di un crimine, rappresenta un problema aperto. La pletora di proposte presenti nella letteratura scientifica, spesso sono difficilmente applicabili o deboli, dal punto di vista delle garanzie. Ecco come la ricerca sta cercando di risolvere i problemi

05 Mag 2021
Francesco Buccafurri

Professore Ordinario di Sicurezza Informatica presso il dipartimento DIIES dell’Università Mediterranea di Reggio Calabria

Uno degli obiettivi che la ricerca scientifica e tecnologica nel campo della sicurezza informatica e dell’information hiding si è posta nel corso degli anni è quello di permettere agli utenti di utilizzare servizi di rete in maniera anonima.

Sebbene l’anonimato potrebbe apparire vantaggioso solo per scopi criminali, non si deve dimenticare che, invece, esso può rappresentare un presupposto essenziale per realizzare applicazioni che necessitano la non identificabilità degli autori di specifiche azioni, come ad esempio il voto elettronico o l’espressione di opinioni. Inoltre, l’uso libero della rete non è scontato in alcuni Paesi del mondo in cui censura e sorveglianza di massa sono pratiche comuni.

Tor, come ti smaschero gli utenti: perché è sempre più difficile restare anonimi in rete

Come funziona Tor

Il protocollo oggi più noto ed usato per l’anonimato in rete è Tor, che è conosciuto per essere lo strumento che dà accesso al dark web. Al protocollo Tor viene implicitamente associato uno speciale browser, che consente appunto di navigare nel dark web. Tor è in realtà qualcosa di più di un browser, è un’implementazione pratica di un protocollo denominato Onion [4], che sfrutta il concetto della cifratura a strati (appunto, a cipolla), per ottenere l’anonimato. Per capire meglio come funziona Onion, facciamo un semplice esempio.

Digital event, 15 giugno
CyberSecurity360Summit: come rispondere alle necessità di aziende e PA?

Supponiamo che un utente che risiede sull’host A voglia contattare un servizio che risiede sull’host B e supponiamo che vi siano alcuni utenti della rete che risiedono su host disposti a veicolare i messaggi, e cioè a svolgere il ruolo di router. Il routing è cioè realizzato attraverso una overlay network, sulla rete esistente, e quindi non è realizzato a livello 3 (livello IP della rete Internet). Ovviamente il routing realizzato nell’overlay network richiederà l’utilizzo del routing nativo (di livello 3) della rete sulla quale l’overlay è realizzato. Tuttavia, questo aspetto è del tutto trasparente rispetto alle funzionalità di anonimato che si vogliono ottenere. Potrà però avere impatto sulle concrete possibilità che ha l’avversario di potere violare l’anonimato offerto dalla rete. Ma prima di affrontare questo aspetto, riprendiamo la descrizione di Onion.

Supponiamo che, tra gli host che operano da router Onion, l’utente A scelga di usare X, Y e Z. Bene, Onion prevede che A, che intende inviare la richiesta M al servizio B, cifri tale richiesta secondo uno schema a strati, nel modo seguente, inviandola a X:

EX(Y, EY(Z, EZ(B, EB(R))))

dove con EK(M) indichiamo la cifratura di M effettuata con la chiave pubblica di K, e cioè un messaggio che solo K (che possiede la chiave privata corrispondente) può comprendere.

Con la cifratura a strati quindi, ciò che accade è che X riceve un messaggio che è segreto per chiunque altro che, una volta decifrato contiene:

Y, EY(Z, EZ(B, EB(R)))

che, per X significa: invia a Y il messaggio EY(Z, EZ(B, EB(R))). Ma, attenzione, il messaggio che X deve inviare a Y è ignoto per X, perché è cifrato con la chiave pubblica di Y. X sa solo quindi di avere ricevuto da A qualcosa che deve inoltrare a Y. Non sa di cosa si tratta, e, soprattutto, non conosce la destinazione finale del messaggio. Quando Y riceve il messaggio, farà la stessa cosa di X, decifrando il seguente messaggio:

Z, EZ(B, EB(R))

Y quindi invierà a Z il messaggio EZ(B, EB(R)) di cui non può conoscere il contenuto. Z conoscerà la destinazione finale B, anche se non comprenderà il contenuto della richiesta perché essa è cifrata con la chiave pubblica di B.

Risultato: se A avesse utilizzato i servizi standard forniti da Internet per contattare B, il nodo della rete contattato da A (che è tipicamente l’Internet Service Provider, o ISP, e cioè il suo gestore di rete) sarebbe stato a conoscenza della destinazione della richiesta, e cioè del fatto che A sta inviando una richiesta a B. In tal modo, invece, solo Z sa che il messaggio è destinato a B, però non conosce l’origine del messaggio. Non sa che il mittente è A. Sa solo che proviene da Y. Ogni nodo conosce solo precedente e successivo nel percorso seguito. Nessuno dei nodi, quindi, può legare la richiesta di A a B, che è quello che Onion, e quindi Tor, volevano ottenere. Si noti che se riferissimo l’esempio a Tor, allora X, Y, Z sarebbero utenti della rete che, volontariamente, partecipano come router. B sarebbe un servizio presente nel dark web, e A sarebbe un comune utente della rete Internet.

Tor è davvero sinonimo di anonimato assoluto?

Ma è davvero così? Abbiamo realmente ottenuto un anonimato assoluto?

Tutto dipende da quale threat model consideriamo. E cioè, da cosa l’avversario è in grado di fare. Questo, certo, dipende da come il routing nella rete è di fatto realizzato. Per esempio, dipende dal fatto che il traffico dell’utente A passerà comunque dall’ISP (mettendoci nel caso dell’utente domestico). È realistico, pertanto, che l’avversario possa monitorare il traffico presso l’ISP. Difficile pensare che possa controllare tutti i router di Tor, che sono in realtà sparsi per mondo. Ma non del tutto irrealistico pensare che possa controllarne qualcuno, magari qualcuno che svolge il ruolo di exit node, e cioè di nodo che, nell’overlay network, contatta il destinatario della richiesta. Come Z, quindi, nel nostro esempio. In tal caso l’avversario ha molte più chance. Può infatti mettere in atto quello che viene chiamato timing attack, riuscendo a correlare le richieste inviate da A verso la rete Tor (che può monitorare grazie al controllo dell’ISP) e il traffico in uscita verso il darkweb (che può monitorare grazie al fatto che controlla il nodo Z).

Onion e Tor non offrono quindi una protezione assoluta in un threat model realistico e non particolarmente severo. Un threat model che ipotizza ancora maggiore potere all’attaccante è quello del global passive adversary, nel quale l’avversario è in grado di monitorare tutti i messaggi che sono scambiati nella rete. Sebbene tale threat model possa apparire irrealistico, vi sono diverse situazioni in cui non lo è. Per esempio, nel caso in cui il traffico è interno ad un’area geografica (anche vasta) nella quale l’avversario è in grado di controllare tutti gli ISP, oppure, spostandoci su un livello applicativo, se ci riferiamo a un social network provider, relativamente a ogni messaggio scambiato tra gli utenti di quel social network.

Come resistere ad attacchi “global passive adversary”

Per resistere ad attacchi come quello descritto prima, o ancor di più, al global passive adversary, è necessario adottare protocolli di routing anonimo più robusti. Nella letteratura scientifica esistono diverse proposte che si collocano nel dominio del routing anonimo. Solo pochi protocolli sono resistenti al global passive adversary, e tipicamente usano il concetto di mixnet [2] con traffico fittizio (cover traffic). Nelle mixnet vi sono nodi che miscelano il traffico entrante disaccoppiandolo da quello uscente, ma la correlazione diventa impossibile solo se i messaggi vengono inviati all’interno di traffico fittizio sempre presente nella rete. Questo ha chiaramente un costo elevato in termini di overhead di traffico. Il protocollo più noto di questo tipo è Tarzan [3], che, nel panorama delle mixnet rappresenta la soluzione più realistica (le mixnet in generale producono altissima latenza o cover traffic eccessivo) anche se non ampiamente sperimentata su Internet.

La ricerca

In tale contesto si inquadra anche una recente attività di ricerca messa in atto dal gruppo di ricerca di cybersecurity del dipartimento DIIES dell’Università Mediterranea di Reggio Calabria, che ha prodotto primi risultati incoraggianti [1]. L’approccio proposto, anch’esso di tipo overlay network, riesce a migliorare le caratteristiche di anonimato di Onion rendendo l’anonimato resistente al global passive adversary, attraverso il concetto di ring, un circuito virtuale circolare in cui viene veicolato cover traffic (i token) che il mittente usa in maniera opportunistica e invisibile per l’avversario per inviare il messaggio sulla rete. Il messaggio esce dal ring (da un punto scelto in maniera random dal mittente) e, attraverso un percorso alla Onion, raggiunge il destinatario, che però lo inoltra fittiziamente, producendo un tratto di percorso inerziale, capace di nascondere il destinatario anche agli occhi del global passive adversary.

Conclusioni

In conclusione, l’anonimato in rete rappresenta ancora un problema aperto, nonostante la pletora di proposte presenti nella letteratura scientifica, spesso difficilmente applicabili o deboli, dal punto di vista delle garanzie di anonimato. È importante sottolineare di nuovo che, nonostante il possibile uso malicious di strumenti che garantiscono l’anonimato in rete, vi sono diversi contesti, che riguardano la sfera personale, gli ambiti finanziari e quelli politici, in cui l’anonimato può avere un ruolo cruciale, senza il quale la rete stessa potrebbe diventare strumento di minaccia, non solo all’efficacia delle stesse applicazioni, ma anche ai diritti fondamentali del cittadino.

Bibliografia

[1] Francesco Buccafurri, Vincenzo De Angelis, Maria Francesca Idone, and Cecilia Labrini, WIP: An Onion-Based Routing Protocol Strengthening Anonymity, In Proceedings of the 22nd IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), June 7-11, 2021 (virtual), IEEE Computer Society, to appear.

[2] D.L. Chaum, Untraceable electronic mail, return addresses, and digital pseudonyms, Communications of the ACM, vol. 24, no. 2, pp. 84–90, 1981.

[3] M.J. Freedman, R. Morris. Tarzan: A peer-to-peer anonymizing network layer. In Proceedings of the 9th ACM Conference on Computer and Communications Security. pp. 193{206 (2002)

[4] D. M. Goldschlag, M. G. Reed, and P. F. Syverson, Hiding routing information, In Proceedings of the International workshop on information hiding. Springer, 1996, pp. 137–150.

WHITEPAPER
Cosa fare per trovare, classificare e analizzare i dati in tempo reale?
Big Data
Cybersecurity
@RIPRODUZIONE RISERVATA

Articolo 1 di 4