Sicurezza degli Anonymous Remailer contro modelli di minaccia avanzati

Gli anonymous remailer cypherpunk offrono garanzie molto migliori del vecchio tipo pseudoanonimo contro il ripetersi di episodi come quello di anon.penet.fi, specie se concatenati. Ma è evidente che la sicurezza offerta dall'invio di un'e-mail senza crittazione è comunque piuttosto bassa, specie se consideriamo che potrebbe esserci a nostra insaputa una registrazione di quanto noi trasmettiamo dalla nostra macchina al remailer. Anche l'impiego di un solo remailer associato a crittazione deve essere considerato a bassa sicurezza: il remailer conosce comunque sia il mittente che il destinatario e per quanto ne sappiamo potrebbe essere stato compromesso all'insaputa dell'operatore, oppure l'operatore stesso potrebbe aver configurato il remailer proprio allo scopo di bloccare e tracciare la posta altrui. L'ipotesi può parere un tantino paranoica, ma è proprio con un certo livello di paranoia razionale che occorre confrontarsi per valutare la sicurezza di queste tecniche. La concatenazione degli anonymous remailer associata a crittazione offre una sicurezza molto più forte. Riconsideriamo il disegno della catena come nell'esempio precedente.

Joe - Remailer A. Joe trasmette ad A un messaggio crittato che solo A può decifrare. Un eventuale "origliatore" che controlli la trasmissione di posta da Joe ad A (o semplicemente tutta la posta in ingresso nel remailer A) potrà sapere solo che Joe ha spedito un'e-mail ad A. Non conosce né il contenuto di essa, né il destinatario finale, né i successivi remailer della catena.

Remailer A - Remailer B. A conosce Joe, ma una volta decifrato il messaggio sa solo che deve rinviarlo a B che a sua volta è l'unico che può decifrare il testo PGP dopo che esso è stato sottoposto alla prima decrittazione da parte di A.

Remailer B - Remailer C. B non sa più che Joe è il mittente originario, sa solo che il messaggio proviene da A e che, una volta decrittato, deve rinviarlo a C.

Remailer C - Lex. C sa solo che il messaggio gli arriva da B. Una volta decrittato il messaggio conosce il destinatario finale (Lex) e il contenuto del messaggio (ma solo se il messaggio stesso non è ulteriormente crittato con la chiave pubblica del destinatario); non conosce né il mittente né il percorso del remailing precedente a B.

Di conseguenza, per ricostruire il percorso mittente-destinatario bisognerebbe che tutti i remailer della catena fossero compromessi. È quindi sufficiente che uno solo dei remailer sia sicuro per mantenere l'integrità del nostro anonimato. È inoltre evidente che tanto più lunga è la catena tanto più alta è la probabilità che almeno un remailer sia sicuro, anche se considerazioni pratiche sulla garanzia dell'arrivo a destinazione del messaggio limitano solitamente questa lunghezza a poco più di tre remailer.

Potrebbero esistere però forme di attacco alla sicurezza del nostro anonimato estremamente più sofisticate e potenti. Per dare un'idea di esse faremo riferimento al "modello di minaccia" proposto da Lance Cottrell (l'autore di Mixmaster) per valutare la sicurezza degli anonymous remailer. Secondo Cottrell chi cerca di intercettare i nostri messaggi (l'attaccante) potrebbe disporre di una serie di capacità da non sottovalutare. Ipotizziamo cinque situazioni:

1) l'attaccante ha compromesso alcuni remailer (ma non tutti) e conosce punto di partenza, destinazione e contenuto di tutti i messaggi che passano attraverso gli anonymous remailer compromessi;

2) l'attaccante può monitorare tutti i messaggi al momento in cui lasciano la macchina del mittente originario e al momento in cui arrivano alla macchina del destinatario finale;

3) l'attaccante è in grado di monitorare tutti i messaggi in entrata e in uscita da tutti gli anonymous remailer, nonché l'ora di arrivo e di partenza;

4) l'attaccante può impedire ai messaggi di giungere a destinazione (denial of service attack);

5) l'attaccante è in grado di inviare un numero illimitato di messaggi attraverso gli anonymous remailer (spam attack) inclusi quelli precedentemente registrati (reply attack).

Ad evitare paranoie irrazionali, è bene sottolineare che questo modello teorico di minaccia fa riferimento, anche a detta dello stesso Cottrell, al classico "peggior scenario possibile" e ipotizza un attaccante estremamente potente e determinato a un impiego di risorse tale da risultare abbastanza improbabile e antieconomico, specie rispetto alle situazioni per cui facciamo comunemente uso delle tecniche per l'anonimato in rete.

Ma è bene sottolineare anche che l'attuazione pratica di questo modello non è affatto impossibile, specie se pensiamo ad esempio alle risorse di cui potrebbero eventualmente disporre agenzie governative o sovranazionali fortemente motivate a monitorare lo scambio in rete tra alcuni soggetti, o magari a rintracciare chi stia diffondendo in rete notizie particolarmente critiche.... Comunque sia, se l'attaccante dispone solo delle risorse di cui ai punti uno e due, abbiamo già visto come la tecnica di concatenamento insieme a quella di crittazione degli anonymous remailer cypherpunk sia già sufficiente a mantenere l'integrità del nostro anonimato a livelli più che accettabili. Ma se dispone anche della capacità di cui al punto tre (monitoraggio dei messaggi in entrata e in uscita da tutti i remailer e registrazione dell'ora) allora le cose potrebbero cambiare: se il nostro messaggio venisse rinviato in uscita dal remailer subito dopo l'arrivo del corrispondente messaggio in entrata, l'attaccante potrebbe correlare i due messaggi e procedere così al tracciamento lungo tutta la catena dei remailer.

Per questo motivo ormai tutti i remailer di tipo cypherpunk avanzato implementano una particolare funzione denominata reordering (questa funzione è svolta automaticamente dal remailer e non richiede comandi da parte dell'utente). Il tipo più semplice di reordering viene effettuato conservando ogni messaggio sul remailer per un periodo di tempo casuale prima di procedere al rinvio, eliminando attraverso questo ritardo casuale (detto latency - da non confondere con il comando <Latent-Time:>) la possibilità di correlare i messaggi in uscita a quelli in entrata basandosi sull'ora d'arrivo e partenza.

Tuttavia, la protezione offerta da questo tipo di reordering dipende in gran parte dal volume di traffico che passa attraverso il remailer. Se per qualche motivo dopo l'arrivo del nostro messaggio non ne arrivassero altri per un periodo di tempo più lungo di quello massimo previsto per il ritardo casuale - come potrebbe accadere in seguito al blocco dei successivi messaggi in arrivo da parte dell'attaccante (denial service attack, punto quattro del modello di minaccia) o anche solo per casuali fluttuazioni di traffico o problemi sulla rete - allora il messaggio rinviato in uscita sarebbe facilmente correlabile all'ultimo messaggio in entrata. E per ragioni di praticità la durata massima dell'intervallo casuale non può essere prolungata più di tanto.

Una tecnica di reordering più evoluta prevede invece che un determinato numero di messaggi, il cosiddetto "pool", venga sempre e comunque mantenuto in giacenza sul server. All'arrivo di un nuovo messaggio viene rinviato un messaggio in uscita scelto a caso tra tutti quelli giacenti nel pool, incluso quello appena arrivato. Questa tecnica - che può essere combinata a quella del ritardo casuale per una sicurezza ancora maggiore - è però anch'essa vulnerabile se l'attaccante possiede la capacità di inviare al remailer un gran numero di messaggi, superiore a quello dei messaggi che di default sono mantenuti nel pool (spam attack, punto cinque del modello di Cottrell). In seguito a questa massiccia ondata di arrivi, tutti i messaggi giacenti nel pool saranno rilasciati e sostituiti da quelli inviati dall'attaccante e a esso noti. All'arrivo del nostro messaggio l'attaccante farà seguire un ulteriore spam, provocando nuovamente il rinvio di tutti i messaggi e a questo punto gli saranno tutti noti tranne il nostro, che verrà così identificato e tracciato.

Un'ulteriore protezione contro questo tipo di attacchi ci è però offerta dal comando <Latent-Time:>. Con questo comando l'utente può richiedere al remailer che il suo messaggio venga in ogni caso trattenuto prima del rinvio, per un tempo specificato dall'utente stesso, indipendentemente dal reordering effettuato dal remailer stesso.

A causa della sua importanza daremo qui un esempio delle varie possibilità del suo impiego:

=====================================================
To: remailer@replay.com
From: joe@freemail.net
Subject: test
-----------------------------------------------------
::
Request-Remailing-To: h_tuttle@rigel.cyberpass.net
Latent-Time: +6:00

::
Request-Remailing-To: remailer@anon.efga.org
Latent-time: +3:15r

::
Request-Remailing-To: lex@luthorcorp.com
Latent-Time: 17.30

Pare che il SuperFesso ci stia dando la caccia anche su
Internet. Sta controllando la posta che ricevi, ma passando
attraverso un remailer non riuscira' a risalire fino al nuovo
indirizzo che sto usando.
=====================================================

In questo esempio di concatenamento non crittato il primo <LatentTime:> chiede a remailer@replay.com - a cui è indirizzato il primo messaggio della catena - un ritardo di 6 ore prima di procedere al remailing a h_tuttle@rigel. cyberpass.net. Notare il "+", l'assenza di spazi tra il "+" e la durata del ritardo e il formato con cui si indica la durata del ritardo in <ore>:<minuti> (durata massima 24 ore). Notare inoltre l'assenza di linea bianca tra Request-Remailing-to: e Latent-Time:

Il secondo <Latent-Time:> chiede a h_tuttle@rigel.cyberpass.net di ritardare il rinvio a remailer@anon.efga.org per un intervallo di tempo casuale non superiore a 3 ore e 15 minuti, indicato dalla lettera "r".

Infine il terzo <Latent-Time: indica a remailer@anon.efga.org di effettuare il rinvio a lex@luthorcorp.com alle 5 e mezzo del pomeriggio (ora locale). In questo caso l'ora non è preceduta dal "+", e deve essere specificata nel formato delle 24 ore.

Nella pratica reale, i vari comandi <Latent-Time:> verranno specificati per ogni singolo remailer della catena via via che si procede nei vari passaggi della crittazione. Dovrebbe risultare chiaro da quanto visto sinora che il rafforzamento della sicurezza offerto da questo comando sarà tanto maggiore quanto più lungo sarà il ritardo richiesto.

In conclusione, la sicurezza offerta dagli anonymous remailer cypherpunk, grazie alla tecnica di concatenamento associato a crittazione PGP, irrobustita dalle funzioni di reordering dei remailer e dall'uso del comando <Latent-Time:> risulta molto forte. In particolare risulta in grado di resistere anche alla compromissione di quasi tutti gli anonymous remailer della catena, al monitoraggio diretto della macchina da cui partono i messaggi e ad attacchi sofisticati che comportano la disponibilità di ingenti risorse, quali quelli basati sulla registrazione dell'ora di arrivo e partenza di tutti i messaggi che transitano attraverso la rete dei remailer.

La tecnica finora proposta potrebbe risultare teoricamente vulnerabile di fronte a tipi di attacco ancora più potenti di quelli appena visti, quali quelli basati sull'analisi della dimensione dei messaggi. Anche se il nostro messaggio è correttamente concatenato, crittato, riordinato dagli anonymous remailer della catena e ritardato su ognuno di essi con il comando <Latent-Time:>, esso comunque alla partenza è costituito da un numero preciso di byte difficilmente identico a quello di un altro - che diminuirà a ogni successivo passaggio della catena in modo prevedibile e conosciuto. Un attaccante che disponga delle risorse di cui al modello di Cottrell e di una notevole capacità di calcolo potrebbe tentare di identificarlo e tracciarlo basandosi proprio su questa caratteristica. Come contromisura sarebbe possibile pensare di inserire nel nostro messaggio delle "imbottiture", cioè del testo-spazzatura che i remailer potrebbero rimuovere ad ogni rinvio (cfr. comando <Cutmarks:>) rendendo così imprevedibile il rapporto tra la dimensione del messaggio in entrata con quella in uscita. Questa soluzione presenta però l'inconveniente di aumentare sensibilmente le dimensioni del messaggio, spesso sopra i limiti di accettazione degli anonymous remailer, in quanto, per essere veramente efficace, bisognerebbe che il messaggio cambiasse di dimensione per una grossa frazione ad ogni balzo.

Inoltre, essa potrebbe offrire informazioni a un attaccante che abbia compromesso il remailer: dato che questa soluzione è poco usuale, il nostro messaggio potrebbe benissimo essere il solo che presenta una diminuzione del numero di byte diversa da quella standard. La migliore soluzione sarebbe quella che tutti i messaggi avessero la stessa dimensione.

Un'altra possibilità di attacco potrebbe basarsi sulla tecnica del cosiddetto reply attack: l'attaccante registra il nostro messaggio al momento in cui lascia la nostra macchina e ne invia un gran numero di copie al primo remailer della catena. Un gran numero di messaggi identici verranno così rinviati al remailer successivo, che verrà identificato attraverso questo improvviso ed anomalo aumento del traffico tra i due remailer, ben visibile ad un'analisi basata sul volume dello stesso. In questo modo sarebbe possibile seguire il percorso del nostro messaggio sino al destinatario finale. Per questo motivo sarebbe opportuno che gli anonymous remailer non accettassero di rinviare più di una volta lo stesso messaggio. Come vedremo, i più recenti remailer del tipo mixmaster sono stati progettati le migliori proprio contro questo tipo di attacchi.

Mixmaster (tipo II) è il tipo più recente di remailer attualmente operativo su Internet. Concatenamento e crittazione sono predisposti in modo automatico al momento della preparazione del messaggio con l'apposito client. Mixmaster non usa la crittazione PGP ma il pacchetto RSAREF e alcuni formati proprietari in modo da implementare un processo di crittazione\decrittazione estremamente più complesso di quello "a cascata" degli anonymous remailer cypherpunk, come si può immediatamente intuire dal seguente schema grafico del pacchetto mixmaster, elaborato da Cottrell stesso.

(Se stai utilizzando un browser text-only clicca qui per visualizzare una versione semplificata dello schema grafico che segue)

schema grafico del pacchetto mixmaster

In pratica mixmaster scompone i messaggi, li sottopone a crittazione multipla e li incapsula in uno o più pacchetti di dati di uguale dimensione, rendendo così impossibile un'analisi efficace basata su questa caratteristica. I pacchetti vengono inviati separatamente lungo la rete dei remailer e sottoposti a un sofisticato reordering. Ogni pacchetto è interamente crittato a ogni rinvio con una chiave 3DES, in modo che nessuna informazione sia visibile a un osservatore esterno. Come per gli anonymous remailer cypherpunk, ogni remailer della catena, anche se compromesso, può conoscere solo il punto da cui arriva un pacchetto e la destinazione di rinvio, ma oltre a questo, soltanto l'ultimo remailer della catena è in grado di vedere quali pacchetti compongono un singolo messaggio, mentre per tutti gli altri essi sono completamente indipendenti tra loro. A ogni pacchetto di dati in transito viene casualmente assegnato un numero di identificazione che il remailer conserva in memoria. Il sistema è così in grado di riconoscere un pacchetto già transitato e rifiutarne il rinvio, proteggendosi da un possibile "reply attack" basato sulla cattura e ritrasmissione dei pacchetti. Infine, come ulteriore protezione, l'architettura di un remailer mixmaster prevede un traffico costante "di copertura" generato casualmente, in modo da nascondere la trasmissione dei pacchetti reali entro un "rumore di fondo" variabile.

A giudizio di chi scrive, questi notevoli miglioramenti sono però in certa misura controbilanciati dal fatto che Mixmaster, a differenza degli anonymous remailer tipo Cypherpunk, necessita di un apposito client per la preparazione dei messaggi, non utilizzabile sotto ogni sistema operativo. Al momento in cui scriviamo il client è disponibile per UNIX, in un unico pacchetto di distribuzione assieme al server. Le release più recenti di questo pacchetto contengono anche i sorgenti e le istruzioni per la compilazione del client sotto DOS, operazione però non facilissima per l'utente medio.

Questo svantaggio è in parte compensato dal fatto che gli anonymous remailer di tipo mixmaster possono accettare anche messaggi nel formato cypherpunk. Se nella catena il remailer successivo è anch'esso un mixmaster, allora i messaggi gli verranno comunque rinviati in forma "incapsulata", anche se non sarà possibile per l'utente disporre delle piene funzionalità mixmaster.

Va inoltre sottolineato che secondo recenti ipotesi di alcuni autori della comunita' "crittoanarchica" USA -- peraltro difficilmente verificabili -- la dimensione delle chiavi RSAREF da 1024 bits usate da mixmaster potrebbe risultare ormai insufficiente di fronte alla potenza di calcolo presumibilmente a disposizione delle maggiori agenzie di controllo e spionaggio statunitensi

Va infine segnalata una recente e suggestiva ipotesi sui motivi della crescente inaffidabilita' dei remailers, che potrebbe essere dovuta a forme sottili di sabotaggio da parte delle organizzazioni di spionaggio e controllo USA. Sebbene sia stata avanzata dall'autore di JBN e Potato, il che le conferisce una certa autorevolezza, essa necessita di ulteriori approfondimenti e verifiche. La riportiamo qui nella traduzione italiana fatta da Putro.