Temporalità e Double-Spending

In quest'ultima sezione introdurremo il problema dei replay attack che presenta varie sfumature su molteplici contesti.

Mario Raciti (tsumarios)

29 dic 2019 • 8 min read

The most certain way to succeed is always to try just one more time. - Thomas A. Edison

Introduzione

Quando si effettua shopping online molti di noi sono soliti fornire le informazioni delle proprie carte di credito in modo naturale o, in ogni caso, questa pratica è stata ormai accettata, talvolta a malincuore. Un po' di tempo fa, intorno agli anni '90-2000, ciò non era assolutamente immaginabile, in quanto i consumatori erano incerti ed esitanti a causa degli ancora emergenti standard per i protocolli crittografici. Nello specifico, era considerata una vera e propria follia affidare la propria carta di credito a venditori online di dubbia provenienza su un canale insicuro. Non è un caso che in un ambiente del genere ci fosse molto interesse nel definire una struttura che fungesse - un po' come abbiamo visto nel problema della certificazione dove vi è bisogno di una terza parte certificante - da intermediario. In effetti al giorno d'oggi conosciamo bene questa "terza entità" che si frappone tra l'acquirente ed il venditore. Le ormai famose PayPal e Amazon, che gestisce anche l'acquisto di prodotti venduti da terzi, ne rappresentano due eclatanti esempi.
Il grande fisico e matematico Carl Friedrich Gauss disse, una volta, che

La matematica è la regina delle scienze e la teoria dei numeri è la regina della matematica.

Nel corso del nostro iter abbiamo più volte richiamato una disciplina basata sulla matematica - in particolare sulla matematica discreta - che rappresenta uno strumento fondamentale nell'ambito della sicurezza: la Crittografia.

In quest'ultima sezione introdurremo il problema dei replay attack che presenta varie sfumature su molteplici contesti - ne vedremo per esempio una istanziazione in ambito finanziario - e descriveremo alcune possibili soluzioni in grado di prevenire queste tipologie di attacchi. In particolare faremo riferimento al protocollo per l'autenticazione Kerberos, il quale necessita di una struttura centralizzata, e alla blockchain utilizzata nei Bitcoin, in cui ci si avvicina molto a prevenire i replay attack nonostante si tenda ad avere una struttura decentralizzata.

Problema

Ricordiamo che la temporalità è cruciale nell'ambito della cybersecurity, specie quando parliamo di networking - si veda Attacking the Network Time Protocol come esempio. Uno dei problemi principali nel mondo della sicurezza informatica è costituito dai replay attack. Conosciuto anche come playback attack, si tratta di un attacco di rete in cui un dato trasmesso viene intercettato e, in modo malevolo o fraudolento, riproposto. Il replay attack è simile al Man in the Middle, in quanto l'attaccante si pone in mezzo alla comunicazione di due (o più) entità, ma può essere effettuato anche in modo asincrono. Per chiarire meglio le idee, un esempio banale potrebbe essere descritto dal seguente scenario:

Alice invia una credenziale di autenticazione a Bob.
Carl intercetta tale credenziale e la ripropone, successivamente, a Bob.
In tal modo Carl farà credere a Bob di essere Alice.

Nell'ambito delle finanze un replay attack viene esemplificato come double‐spend attack. Il principio è analogo a ciò che abbiamo appena osservato, ma il dato replicato stavolta consiste in una transazione di pagamento. Nell'economia tradizionale sono stati gli istituti finanziari centralizzati a fornire un controllo che evitasse la doppia spesa, mentre questo risulta un potenziale problema in uno schema di cassa digitale in cui uno stesso singolo token digitale potrebbe essere speso più di una volta presso venditori diversi, in mancanza di un organo o di un sistema certificatore. Come nel caso del denaro contraffatto, la doppia spesa porta all'inflazione creando una nuova quantità di valuta fraudolenta che in precedenza non esisteva.
In questo contesto, in riferimento alle crittovalute, il double-spending prende anche il nome di 51% attack. È necessario evidenziare che il termine scelto è funzione dell'idea che sta alla base dei Bitcoin e, più in generale, delle crittovalute che possiamo considerare - chiariremo meglio quando parleremo delle possibili soluzioni - "sicure": il consenso.

L'istanziazione in ambito finanziario è utile a comprendere un fatto: se da un punto di vista morale appare chiara la differenza fra una transazione di pagamento da parte di Alice verso Bob e la stessa effettuata, però, da Carl, non è altrettanto evidente dal punto di vista tecnologico, in quanto le due transazioni risultano essere identiche e valide entrambe. Osserviamo quindi che la distinzione viene da noi dedotta in base alla conoscenza dell'accaduto. Questo punto è cruciale in quanto mette in luce la pericolosità dei replay attack.

Esempio

Vi sono diversi esempi, basati su attacchi reali o su semplici esperimenti, sull'utilizzo di attacchi di replay che possono spaziare su ambiti differenti, alcuni dei quali si ricollegano alla questione sulla sicurezza dell'Internet of Things:

Verge 51% attack: per rimanere in tema economico, il 4 aprile 2019 fu annunciato che la crittovaluta Verge (XVG) avrebbe subito un attacco 51%. Un bug avrebbe permesso ad un attaccante di falsificare i timestamp e di produrre ogni nuovo blocco usando lo stesso algoritmo. C'è da precisare, comunque, che i 51% attack si possono verificare "raramente" in un sistema che segue le dovute precauzioni - un altro po' di pazienza e chiariremo meglio anche questo passaggio.
Remote keyless-entry system per veicoli: molti veicoli su strada utilizzano un sistema remoto keyless per questioni di comodità - come già ampiamente discusso nella sezione sull'IoT - dell'utente. I sistemi moderni sono hardenizzati contro semplici attacchi di replay, ma sono vulnerabili ai replay attack bufferizzati. Per la vasta quantità di esempi che sono facilmente reperibili online - su YouTube ad esempio - non forniamo un esempio eclatante, ma descriviamo comunque il funzionamento dell'attacco. Noto anche come Rolljam attack, esso viene eseguito posizionando un dispositivo in grado di ricevere e trasmettere onde radio (jammer) nel raggio d'azione del veicolo bersaglio. Il trasmettitore tenterà di catturare qualsiasi segnale RF di sblocco del veicolo inviatogli, salvandolo in un buffer per un uso successivo. Dopo varie iterazioni, il dispositivo catturerà un nuovo segnale, lo memorizzerà nella cache e riprodurrà quello vecchio, creando un rolling buffer che sarò uno step avanti rispetto al veicolo. In un secondo momento, l'attaccante potrà utilizzare questo codice bufferizzato per sbloccare l'obiettivo.

Text-dependent speaker verification: vari dispositivi utilizzano il riconoscimento vocale per verificare l'identità di un utente. Nei sistemi text-dependent, un utente malintenzionato A potrebbe registrare il discorso di un individuo target B che è stato correttamente autenticato dal sistema. In questo modo quindi, l'attaccante potrebbe riprodurre nuovamente la registrazione al sistema, il quale lo autenticherà come B.

Soluzioni

Nel corso di questa sezione abbiamo lasciato varie questioni in sospeso, nello specifico riguardanti le crittovalute e i 51% attack. Tuttavia, prima di procedere e spiegare quali siano le possibili soluzioni ai replay attack, è fondamentale introdurre il concetto di freshness. Trattasi di una meta-proprietà di sicurezza che mette in gioco la temporalità degli eventi e permette, grazie ad essa, di prevenire gli attacchi di replay. In genere, la freshness si può ottenere mediante l'utilizzo delle nonce, un numero casuale o pseudo-casuale che può essere usato una sola volta, o i timestamp, marche temporali. Ricordiamo inoltre che queste ultime vengono ampiamente utilizzate negli ambiti della Digital Forensics per certificare data e orario relativamente ad una precisa azione o evento.
Avanziamo adesso con ordine ed esaudiamo i dubbi pendenti. Brevemente, le crittovalute sono valute digitali basate, come anche il nome suggerisce, sulla crittografia. Nello specifico intervengono strutture dati crittografiche particolari - se ricordiamo abbiamo già citato i Merkle Tree parlando di Certificate Transparency - che garantiscono, fra le altre cose, la proprietà di integrità grazie alla loro composizione a blocchi, ognuno dei quali ingloba, oltre ai dati, anche il digest (hash) del blocco successivo (se facciamo riferimento alle blockchain) o figlio (per quanto riguarda i Merkle tree). L'idea, che sta alla base delle blockchain utilizzate nei Bitcoin per tentare di prevenire il double-spending, è quella di eseguire dei timestamp su gruppi di transazioni per poi successivamente inviarle in broadcast a tutti i nodi della rete.

Poichè le transazioni sono state marcate temporalmente e sono matematicamente legate alle precedenti - ricordiamo la presenza dell'hashing - risulterà "impossibile" riuscire a manometterle. In effetti - e i 51% attack ne sono la prova - vi è comunque la probabilità non nulla che si riesca a performare un replay attack. Questo giustificherà quel "51%": la rete dei Bitcoin è una rete decentralizzata - ribadiamo che gli attacchi di replay sono facilmente prevenuti da strutture centralizzate - basata sul consensus. Per questo motivo se un attaccante riuscisse a possedere (o corrompere) il 51% dei nodi "onesti", sarebbe in grado di ingannare il sistema. Chiudiamo il discorso economico riflettendo che, per convenienza degli utenti, solitamente i nodi onesti sono in maggior numero e pertanto questo tipo di attacco può essere considerato molto raro in presenza di un sufficiente numero di utenti nella rete della crittovaluta.
Nella prima sezione, quando in riferimento al Single Sign On, abbiamo accennato al protocollo di autenticazione Kerberos, il quale ha lo scopo di garantire confidenzialità, autentica (ad accesso singolo) e temporalità. Kerberos rappresenta una possibile soluzione contro i replay attack nel contesto in cui opera, in quanto le chiavi utilizzate hanno validità limitata. Il protocollo fa uso dei timestamp, che richiedono macchine sincronizzate. Nel dettaglio Kerberos è caratterizzato da tre fasi: autenticazione, autorizzazione e servizio. È da notare che solo le ultime due sono opzionali e trasparenti all'utente e che ognuna delle fasi fornisce delle chiavi, che hanno una durata di validità limitata, da utilizzare nella successiva. Sebbene sia un'ottima soluzione ai replay attack, bisogna tuttavia puntualizzare che questo protocollo risentiva nella versione 4 di cascade attack - un attacco ne provoca altri in modo diretto - nel caso in cui le chiavi di sessione scadute fossero insicure. Ciò è stato risolto in Kerberos 5 , il quale rappresenta uno standard (RFC1510) largamente utilizzato, mediante un controllo accurato - non ci addentriamo nel dettaglio - sui tempi di validità effettuato dal Ticket Granting Server (TGS). Terminiamo il discorso su questo protocollo ricordando che Kerberos rappresenta anche una contromisura agli insider threat, ai quali abbiamo fatto riferimento più volte. Infine, ricollegandoci all'ultimo degli esempi di attacco riportati, possiamo ricordare che una contromisura agli attacchi sulle text-dependent speaker verification è stata ideata costruendo delle bitmap spettrali dal discorso memorizzato degli utenti verificati. In questo modo, poiché il campione originale ha uno schema diverso rispetto a quello riprodotto (replayed), quest'ultimo verrà rifiutato dal sistema.

Conclusioni

Riassumendo, abbiamo approfondito l'importanza della temporalità che risulta fondamentale su molte applicazioni che riguardano ambiti e concetti delicati, quali quello l'autenticazione e le crittovalute. Kerberos rappresenta sicuramente una potente contromisura ai replay attack in quanto offre freshness su più livelli. Per concludere, possiamo affermare che da quest'analisi possiamo dedurre come il problema del trust risulti spesso centrale - l'abbiamo visto in altre sezioni -, in particolare nella struttura dei Bitcoin la quale è basata, come abbiamo esposto, sul consenso. Con quest'ultima sezione si conclude il nostro excursus sugli aspetti salienti della cybersecurity.

Le tematiche incluse sono state scelte con cura ed organizzazione, in modo da poter coprire al contempo gli argomenti più in voga ma anche più rilevanti nel corso della storia dell’informatica. Il concetto di Security by Design e la crittografia sono stati quasi onnipresenti durante la trattazione e ciò ne testimonia l’estrema importanza. Per mia personale scelta ho deciso di non dedicare una sezione - ne ho parlato in minima parte ed in riferimento ad un esempio - circa il Penetration Testing, che ricordiamo non va mai citato da solo ma va affiancato al Vulnerability Assessment (VAPT), in quanto questo viene spesso confuso, specie da chi non è del campo, come sinonimo di sicurezza informatica.

Vorrei concludere questo viaggio invitandovi a riflettere sulla citazione di Stephane Nappo che ho scelto di inserire come sottotitolo dell'abstract.