Denizione e valutazione di uno schema di prova di possesso dei dati. (Sintesi)

Transcript

1 Facoltà di scienze matematiche siche e naturali Corso di Laurea Magistrale in Matematica Tesi di Laurea Magistrale in Matematica Denizione e valutazione di uno schema di prova di possesso dei dati (Sintesi) Relatore: Prof. Roberto Di Pietro Candidata: Emanuela Iacobone mat Correlatore: Prof. Agustin Orla Anno Accademico 2011/2012

2 Introduzione Il Cloud Computing è al giorno d'oggi una parola molto usata nell'information Technology. Aziende come Amazon, Google e altre, stanno cercando di accelerare il passo nello sviluppo e nel miglioramento dei loro sistemi di Cloud Computing per fornire i loro servizi ad una maggiore quantità di utenti. Questo recente rapido aumento della fruibilità dei servizi Cloud insieme ai molti vantaggi derivanti dal suo utilizzo, rendono tali servizi attraenti ed economicamente convenienti. La loro adozione da parte di un numero sempre crescente di utenti ha portato ad un aumento del volume di dati memorizzati nei Cloud; si è cominciato dunque a sentire l'esigenza di implementare nuove tecniche che permettano di risparmiare spazio di memoria e larghezza di banda. Una promettente idea in questo contesto è la deduplication: con questo termine si indica quel processo che permette di evitare di dover memorizzare uno stesso dato più volte. La sua eettiva utilità è evidente dal fatto che spesso grandi quantità di dati mostrano un'alta ridondanza: ne sono un esempio i documenti nanziari, che hanno intestazioni comuni e campi semi-identici, oppure i contenuti multimediali più popolari, come musica e video, che aspirano ad essere posseduti da molti utenti. Alquanto semplice in teoria, l'implementazioni delle tecniche di deduplication introduce nuovi rischi riguardo la sicurezza. Harnik et al. [1] hanno identicato alcune delle possibili minacce che possono interessare un sistema Cloud Storage che si avvale di queste tecniche: oltre a compromettere la privacy e la condenzialità degli utenti del sistema, alcuni possibili attacchi sono in grado di sovvertire l'uso previsto per un sistema Cloud Storage, trasformandolo ad esempio in un Content Distribution Network (CDN). Un attacco di quest'ultimo tipo è stato realmente messo in atto, solo qualche anno fa, da Wladimir van der Laan contro uno fra i più popolari servizi di Cloud Storage, Dropbox; van der Laan ha creato un progetto open source, chiamato Dropship 1

3 [2], che consentiva agli utenti di scaricare contenuti dal server Dropbox pur non avendoli eettivamente mai posseduti. Il progetto è stato poi però ritirato dopo che il co-fondatore di Dropbox lo ha richiesto in un modo davvero civile. Per evitare attacchi di questo tipo, Halevi et al. [3] hanno introdotto la nozione di Proof of Ownership (POW), un protocollo di sicurezza che permette al sistema di autorizzare il ripristino di un determinato le solo agli utenti che eettivamente si sono dimostrati i reali possessori dello stesso. In questa tesi introdurremo e presenteremo un nuovo schema di proof of ownership e lo compareremo con i due precedentemente introdotti da Halevi et al. [3] e Di Pietro, Sorniotti [4]. La peculiarità del nostro schema riguarda l'utilizzo di una struttura dati probabilistica che, introdotta più di quarant'anni fa, ha avuto n da allora un notevole successo nelle applicazioni database: il ltro di Bloom. Nel corso del lavoro verranno descritte e confrontate fra loro le implementazioni di tutti e tre gli schemi di POW menzionati, insieme alla complessità computazionale, l'i/o, la quantità di memoria e la larghezza di banda necessarie per eseguire l'intero protocollo. L'analisi comparativa delle tre soluzioni verrà eettuata sia in maniera formale che avvalendosi dei tempi di esecuzione misurati nei test condotti utilizzando le implementazioni in linguaggio C++ dei tre schemi. 1 Cloud Computing e Cloud Storage Nonostante negli ultimi anni il Cloud computing è l'argomento di IT del quale si è più scritto, discusso e parlato, rimane tuttavia molta confusione riguardo a cosa esattamente esso sia. Società di analisi, docenti universitari, operatori del settore e aziende di IT, hanno fornito denizioni diverse di Cloud computing [5]. La denizione data dal National Institute of Standards and Technology (NIST) 2

4 è la seguente: Denizione. Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of congurable computing resources (e.g., networks, servers, storage applications and services) that can be rapidly provisioned and released with minimal management eort or service provider interaction. La Berkeley RAD Lab dà una denizione più precisa riguardo a cosa il termine Cloud Computing si riferisce: indica sia le applicazioni fornite come servizi su internet sia i sistemi hardware e software nei data center che forniscono tali servizi; il data center hardware e software è detto Cloud [6]. Il Cloud Computing è quindi un grande pool di risorse virtualizzate di facile accesso e utilizzo, che possono essere dinamicamente ricongurate per adattarsi ad un carico variabile consentendo dunque in questo modo un ottimale utilizzo delle risorse. Poichè l'accesso alle risorse da parte dell'utente avviene solo con l'aiuto di internet e di un browser, la fruizione delle stesse è indipendente dal dispositivo utilizzato dall'utente o dalla sua posizione. Inoltre, dato che le infrastrutture alle quali si accede sono fornite da terze parti, l'utente le utilizza senza conoscerne le caratteristiche di dettaglio e senza occuparsi della loro gestione; la manutenzione è più facile e i costi per gli utenti sono ridotti proprio perchè le applicazioni non devono essere installate sui computer personali degli utenti. La modalità pay-per-use utilizzata, permette di misurare l'uso delle applicazioni per client su basi regolari; ed in più la condivisione sia dei costi che delle risorse tra un elevato numero di utenti, consente un utilizzo eciente delle infrastrutture. Il Cloud Storage ore agli utenti la possibilità di memorizzare i propri dati su uno spazio di archiviazione on-line scalabile ed elastico gestito da terzi, accessibile tramite la rete. Al suo livello più elementare, un sistema di Cloud Storage necessita solo di un le system connesso a Internet. Un cliente (ad esempio, un utente di computer 3

5 abbonato ad un servizio Cloud Storage) invia delle copie di alcuni le su Internet al server, che le memorizza. Quando il cliente desidera recuperare questi dati, accede al server attraverso un interfaccia Web-based. Il server puo' allora o inviare i le al cliente o consentire a questo di accedere e manipolare i le sul server stesso. L'utilizzo del Cloud Storage ha notevoli vantaggi dal punto di vista dei costi, della gestione e della qualità del servizio oerta: permette di semplicare drasticamente il mantenimento degli hardware, dei software e in generale delle infrastrutture che supportano l'archiviazione di dati, con la conseguente riduzione dei costi di gestione e del personale addetto; le soluzioni Cloud-based, inoltre, sono essibili e forniscono il necessario spazio di archiviazione. Dal punto di vista della sicurezza, il sistema di Cloud Storage ha però inevitabilmente creato nuove pericolose minacce per una serie di ragioni, che riguardano per lo più la sua architettura e il suo funzionamento, e per le quali sono state proposte diverse tecnologie in grado di fronteggiarle e sconggerle [7]. 1.1 Deduplication Nonostante le suddette questioni relative alla sicurezza, c'è stato negli ultimi tempi un rapido incremento nell'utilizzo del servizio di Cloud Storage, con un conseguente aumento del volume di dati memorizzati. Si è iniziato dunque a sentire l'esigenza di implementare nuove tecniche che permettano di risparmiare spazio di memoria e larghezza di banda. Una centrale e promettente idea in questo contesto è la deduplication: sono tecniche che permettono di memorizzare solo una singola copia dei dati ridondanti. La sua ecacia dipende da fattori quali il tipo di dato, il periodo di conservazione e il numero di utenti. Le strategie di deduplication si possono classicare a seconda delle unità dati di base che trattano [1]; si distingue la le-level deduplication, nella quale sono le 4

6 singole copie di le ad essere memorizzate, dalla block-level deduplication, in cui i le vengono suddivisi in blocchi ed è una sola copia di ogni singolo blocco ad essere salvata. Un'altra classicazione può essere fatta in base a dove si verica la deduplication; si parla di source-based o client-side deduplication se viene eseguita dal lato dell'utente, prima cioè che il dato venga trasferito: il software dell'utente comunica con il sistema, inviandogli un piccolo valore che identica il dato, per vericare l'esistenza o meno del le o del blocco nella memoria del sistema; se il le o blocco è già presente, il sistema lo sostituisce con un puntatore, e non è quindi necessario inviarlo sulla rete. Si parla invece di target-based o server-side deduplication se avviene dal lato del sistema; con questo approccio l'utente resta ignaro della eventuale deduplication che potrebbe vericarsi. Alquanto semplice in teoria, l'implementazione di questa tecnica presenta però molti rischi legati alla sicurezza. In [1], Harnik et al. hanno identicato e descritto alcune delle possibili minacce che potrebbero interessare un sistema Cloud Storage che esegue la client-side deduplication Proof of Ownership Uno dei rischi più gravi riguardo la sicurezza dovuto all'utilizzo della tecnica del client-side deduplication, deriva dal fatto che la dimostrazione che un utente possegga un dato le è basata unicamente su un piccolo valore (solitamente l'hash di quel le), la cui conoscenza automaticamente garantisce all'utente l'accesso all'intero le. Per evitare questo tipo di attacco, in [3], Halevi et al. hanno introdotto la nozione di Proof of Ownership (POW), un protocollo di sicurezza che permette al sistema di vericare (con un certo grado di garanzia) se l'utente possiede l'intero le o meno. Il protocollo di POW è un protocollo che si svolge tra client e server, su un le in input comune, e funziona in questo modo: in primo luogo il server agisce 5

7 sul le in input applicandogli una funzione di hash, il cui digest utilizzerà come identicatore del le, e generando poi una (piccola) informazione per la verica v. Successivamente, quando un client chiede di caricare un le che il server ha accertato di possedere già (utilizzando il digest inviatogli dal client), server e client avviano un protocollo interattivo, nel quale il client è in possesso del le mentre il server ha solo l'informazione v, al termine del quale il server accetta o riuta. Halevi et al. [3] hanno introdotto il primo pratico protocollo crittograco che implementa il POW. Successivamente Di Pietro e Sorniotti [4] hanno presentato un nuovo schema di Proof of Ownership più eciente del primo dal punto di vista delle performance sul lato del cliente, e la cui sicurezza, a dierenza del suo predecessore, deriva esclusivamente dalla teoria dell'informazione. Noi introdurremo ora un ulteriore schema di POW e lo confronteremo con i due precedenti per mostrarne le qualità e i punti di forza. 2 Gli schemi b-pow e s-pow 2.1 b-pow: algoritmo e sicurezza Halevi et al. [3] hanno presentato tre schemi che implementano il protocollo di POW, i quali dieriscono in termini di ecienza e sicurezza. Tutti e tre prevedono che il server sdi il client a presentare dei sibling path validi per un sottoinsieme di foglie di un albero di Merkle [8], scelte in modo random dal server. Sia il client che il server costruiscono l'albero di Merkle; il server memorizza solo la radice dell'albero e sda i client che aermano di possedere il le. La dimostrazione della sicurezza nell'utilizzo del protocollo di prova dell'albero di Merkle, appena descritto, si basa sul Lemma dell'albero di Merkle (per il cui enunciato e dimostrazione si rimanda all'appendice in [3]). Il Lemma aerma 6

8 che chiunque superi con successo questo protocollo, con un alta probabilità puo' essere convertito in un estrattore che è in grado di estrarre la maggior parte delle foglie dell'albero. L'albero di Merkle è costruito su un buer, il cui contenuto viene derivato dal le, e pre-processato in tre dierenti modi per i tre diversi schemi presentati. Il primo schema applica sul contenuto del le originale un erasure code; sul le codicato viene poi costruito l'albero di Merkle. Il secondo schema, invece, pre-processa il le con una funzione di hash universale che, applicata sull'intero le, genera un output che va a riempire un buer ridotto intermedio, la cui dimensione è abbastanza grande da scoraggiarne lo scambio tra client maliziosi, ma non così tanto da renderlo non pratico: gli autori hanno stabilito una dimensione di 64 MiB. Il buer ridotto ottenuto viene poi usato come input per la costruzione dell'albero di Merkle. Il terzo schema, che è quello con cui confronteremo la soluzione presentata in questa tesi, segue lo stesso approccio, ma sostituisce la funzione di hash universale con una procedura che prevede una fase di riduzione e di miscelazione in grado di generare un buon hash sul buer ridotto intermedio, utilizzato poi per costruire l'albero di Merkle. Nel resto della tesi ci riferiremo a questo schema utilizzando la sigla b-pow. Questo schema ha due fasi: la prima fase (reduction) popola il buer ridotto XORando ogni blocco, in cui il le viene diviso, in quattro posizioni scelte in modo random nel buer (dopo aver eseguito uno shift di bit). La fase successiva di mixing amplica la confusione e diusione nel buer ridotto XORando insieme i contenuti delle posizioni nel buer, scelte in modo random. A dierenza dei due schemi precedenti, gli autori sono in grado di provare la sicurezza del terzo schema solo per un numero ristretto di distribuzioni in input e sotto un'ipotesi sul codice che si ottiene dopo la trasformazione. 7

9 2.2 s-pow: algoritmo e sicurezza In [4], R. Di Pietro e A. Sorniotti hanno presentato un nuovo schema di Proof of Ownership che è più eciente del suo predecessore dal punto di vista delle performance; l'i/o e i costi computazionali non dipendono dalla grandezza del le in input ed inoltre, a dierenza dello schema b-pow, la sua sicurezza deriva esclusivamente dalla teoria dell'informazione. Ci riferiremo a questo schema usando l'acronimo s-pow. L'idea di base sul quale poggia lo schema s-pow, è che la probabilità che un utente malintenzionato è in grado di produrre il valore corretto di K bit del le, con ogni bit scelto in una posizione casuale del le, è trascurabile nel parametro di sicurezza k (se si assume un limite superiore al sottoinsieme di bit del le conosciuti dall'attaccante). La soluzione proposta dagli autori, consiste di due fasi separate. Nella prima fase, il server riceve il le per la prima volta e pre-computa le risposte per un numero di sde POW relative al le. Per la considerazione su esposta, la risposta ad una sda sarà una stringa di bit di dimensione K, costruita con la concatenazione dei K bit del le originale, presi nelle K posizioni casuali. La computazione delle sde POW per un dato le è eettuata sia quando viene richiesto di caricare il le che non è ancora presente tra quelli memorizzati dal server, ma anche quando la riserva di risposte alle sde calcolate in precedenza si esaurisce. La seconda fase è attivata dal client quando invia al server un identicatore univoco per un le di cui desidera dimostrarne il possesso. Il server sceglie una sda ancora inutilizzata tra quelle pre-computate per quel le e la invia al client; il client calcola la risposta in base alla sua conoscenza del le e la invia al server. Il server quindi controlla se la risposta ricevuta dal client coincide con quella pre-computata. Nell'analisi della sicurezza dello schema s-pow, gioca un ruolo il limite su- 8

10 periore della frazione di le conosciuta dall'attaccante. Assumendo che il client malizioso non possieda il le nella sua interezza, nella loro analisi gli autori hanno ipotizzato che la frazione di le conosciuta dall'attaccante sia pari a p = (1 ε). Analizzando una sda su un singolo bit proposta dal server, hanno ipotizzato il vericarsi di due casi: o il bit richiesto appartiene alla porzione di le conosciuta dall'attaccante (evento ω), il che puo' accadere con probabilità P (ω) = (1 ε), oppure, in caso contrario, l'attaccante tirare ad indovinare avendo una probabilità di successo pari a g. Con queste premesse si ha dunque che la probabilità di successo dell'attaccante nella sda su un singolo bit lanciata dal server (P (succ 1 )), assumendo ε > 0 è pari a: P (succ 1 ) = P (succ 1 (ω ω) = 1 ε(1 g) Tuttavia l'attaccante deve confrontarsi con K sde, ognuna i.i.d. rispetto alle altre; quindi la probabilità che l'attaccante riesca a passare la sda con successo è: P (succ) = (1 ε(1 g)) K (1) da cui un valore appropriato per il parametro K puo' essere facilmente dedotto come: K = k ln 2 ε(1 g) Con l'obiettivo di migliorare l'ecienza dello spazio utilizzato, nell'implementazione dello schema s-pow, gli autori hanno calcolato i seed per generare le sde utilizzando il server master secret; questa scelta gli ha precluso il raggiungimento della sicurezza incondizionata che puo' essere però semplicemente ottenuto, come hanno fatto notare, generando per ogni nuova sda un nuovo seed. (2) 9

11 3 Un nuovo schema di POW: bf-pow Introdurremo ora il nostro nuovo schema di Proof of Ownership, al quale ci riferiremo con la sigla bf-pow. La peculiarità del nostro schema riguarda l'utilizzo dei ltri di Bloom [9], una struttura dati probabilistica che fornisce una space-ecient memorizzazione di insiemi ed è concepita per poter garantire una facile verica di appartenenza di un dato elemento all'insieme memorizzato (al costo di una probabilità di falsi positivi ma mai di falsi negativi). Halevi et al. [3] hanno aermato che, per dissuadere dagli attacchi CDN, la quantità di informazione sul le che deve essere nota al client per poter superare la sda con il server, deve essere di grandezza pari ad almeno 64 MiB, per le di dimensione superiore a 64 MiB; per le più piccoli riconoscono sia suciente una conoscenza pari almeno alla dimensione del le in questione. Nel progettare la nostra soluzione, abbiamo tenuto conto di questo. 3.1 Filtri di Bloom Un ltro di Bloom per rappresentare un insieme S = x 1, x 2,... x n di n elementi è costituito da un array di m bit, inizialmente settati a 0. Un ltro di Bloom utilizza k funzioni hash indipendenti h 1,..., h k con output nell'insieme 1,..., m. Assumiamo che queste funzioni hash mappino ogni elemento in un numero random uniformemente scelto nell'insieme 1,..., m. Per ogni elemento x S, vengono settati a 1 i bit h i (x) per 1 i k. Per vericare se un elemento y appartiene all'insieme S, si controlla che tutti gli h i (y) siano settati a 1. Se non è così, allora chiaramente y non è un elemento di S. Se tutti gli h i (y) sono settati a 1 invece, si assume che y appartiene ad S, con una certa probabilità di errore. Dunque un ltro di Bloom puo' generare un falso positivo quando insinua che un elemento x appartiene ad S anche se così non è. Per evitare banalità, si 10

12 assumerà n da adesso kn < m. La probabilità di un falso positivo per un elemento non nell'insieme, il false positive rate (FPR), puo' essere stimata in modo semplice, sotto l'ipotesi che le funzioni hash utilizzate abbiano la caratteristica sopra descritta. Dopo che su tutti gli elementi dell'insieme S sono stati calcolati gli hash e il ltro di Bloom è stato aggiornato di conseguenza, la probabilità che un bit specico sia ancora settato a 0 è: ( 1 1 ) kn e kn/m m Quindi la probabilità che i k indici individuati dalle funzioni di hash siano tutti settati a 1, e dunque si incorra in un falso positivo è: fpr = ( 1 e kn/m) k Si supponga ora di avere m e n e di voler ottimizzare il numero di funzioni hash da utilizzare. Il valore ottimale del numero di funzioni hash che minimizza la probabilità di un falso positivo fpr come funzione di k puo' essere facilmente trovato utilizzando le derivate, ottenendo per k il valore di k = ln 2 (m/n) (3) Un modo per determinare quanto siano ecienti i ltri di Bloom è di considerare quanti bit sono necessari per rappresentare tutti gli insiemi di n elementi in un insieme universo, in modo da permettere falsi positivi per al più una frazione ɛ dell'insieme universo ma da non consentire falsi negativi. Il limite inferiore per m che si ottiene è pari a n log 2 (1/ɛ). Ricordando il valore del false positive rate e di k, prima calcolati, dopo alcune manipolazioni algebriche si ottiene: m = n log 2 e log 2 (1/ɛ) (4) Tra le tante interessanti proprietà che i ltri di Bloom possiedono, una delle caratteristiche importanti per l'utilizzo che noi ne faremo nel nostro schema, 11

13 riguarda il tempo necessario per aggiungere un elemento e per vericare che un dato elemento sia presente nell'insieme: in entrambi i casi si tratta di una costante ssa, O(h), completamente indipendente dal numero di elementi già inseriti nell'insieme. Inoltre poichè il controllo degli h indici sono indipendenti fra loro, nelle implementazioni hardware possono essere eseguiti in parallelo, migliorando ulteriormente le performance. 3.2 Algoritmo bf-pow Sia h una funzione di hash crittograca; sia invece h C una funzione di hash crittograca che prende in input una stringa e restituisce un output di dimensione C; consideriamo inoltre una funzione pseudo-random R s che utilizza s come seed. L'Algoritmo 1 descrive le operazioni che avvengono sul lato server ogniqualvolta un client carica per la prima volta un le. Dopo aver diviso l'intero le in blocchi indicizzati di dimensione N (ottenendo n blocchi) e calcolato su ogni blocco l'hash, applica la funzioni di hash crittograca h C ; il digest ottenuto è successivamente utilizzato come seed per la funzione pseudo-random R s, che prende in input il valore dell'indice del blocco considerato. Sull'ultimo output ottenuto (con Bloom), vengono applicate le k funzioni di hash del ltro di Bloom e viene poi aggiornato il ltro settando a 1 i bit nelle posizioni ottenute. Associando ad ogni blocco di le il suo indice, con la funzione di hash crittograca h C, si elimina la possibilità che un eventuale attaccante possa utilizzare, per superare la sda, dei blocchi di cui è in possesso, e non quelli richiesti dal server. L'utilizzo della funzione pseudo-random R s, invece, con la giusta dimensione dell'output impostata, permette di ottenere una quantità di contenuto totale, necessaria per superare ogni sda lanciata dal server, pari a 64 MiB: come asserito da Halevi et al. [3], questa è la dimensione necessaria per scoraggiare eventuali client maliziosi dall'attuare un attacco CDN. 12

14 Algoritmo 1: Lato server: il server costruisce il ltro di Bloom del le Input: il le, la dimensione del le F e la dimensione dei blocchi N, il numero di funzioni hash del ltro di Bloom k Output: il ltro di Bloom aggiornato n F/N; for i 0 to n 1 do end hash h(le[i]); seed h C (hash); ToBf R seed (i); for ii 0 to k do end Bloom ii (ToBF); update Bloom lter ; L'Algoritmo 2 fornisce invece una descrizione delle operazioni messe in atto dal client quando viene sdato dal server a dimostrare di possedere eettivamente il le che chiede di poter caricare ma che è già presente nella memoria di back-end del server (ricordiamo che questa verica avviene grazie all'hash del le che il client invia al server come identicatore dello stesso). Ogni volta che sda un client, il server sceglie in modo random j indici (il valore di j verrà discusso nel prossimo paragrafo) corrispondenti a j blocchi di le. Utilizzando le j posizioni ricevute, il client ripete i primi due step eseguiti dal server, solo sui blocchi denotati dagli indici; gli output ottenuti formano l'array di risposta che il client invia al server. 13

15 Algoritmo 2: Lato client: il client calcola la risposta alla sda lanciata dal server Input: il le, la dimensione dei blocchi N, un array di j indici scelti dal server (pos[j]) Output: l'array di risposta del client for i 0 to j 1 do end hash h(f[pos[i] N]); res[i] h C (hash); In fase di verica, descritta dall'algoritmo 3, il server applica la funzione pseudo-random R s utilizzando come seed ogni elemento dell'array di risposta ricevuto dal client e, come messaggio in input, il valore dell'indice del blocco sul quale quella risposta è stata calcolata. Algoritmo 3: Lato server: il server calcola le posizioni nel ltro di Bloom ottenute considerando la risposta inviata dal client Input: il numero di funzioni hash del ltro di Bloom k, l'array degli j indici (pos[j]) e l'array di risposta alla sda inviato dal client Output: le j k posizioni nel ltro di Bloom calcolate sulla risposta del client for i 0 to j 1 do end ToBf R res[j] (pos[i]); for ii 0 to k 1 do end Bloom ii (ToBF); 14

16 Se tutte le j k posizioni del ltro di Bloom ottenute applicando le k funzioni di hash (le stesse utilizzate in precedenza per costruire il ltro di Bloom di f), sono settate a 1 nel ltro di Bloom del le memorizzato dal server, allora la sda è superata e il client viene riconosciuto dal server come un legittimo proprietario del le. 3.3 Sicurezza bf-pow Analizziamo la sicurezza dello schema assumendo che un eventuale attaccante conosca una frazione p = (1 ε) del le originario e venga sdato su un numero j di blocchi di le (di dimensione in bit B) di un le di dimensione (in bit) F. Facciamo prima di tutto una considerazione. Ad una prima analisi, quando l'avversario viene sdato dal server su un blocco di le, possono presentarsi due casi: o l'avversario possiede quel blocco nella sua interezza, e quindi vince sicuramente la sda, oppure no, ed allora cerca di ricostruirlo indovinando i bit che lo formano. Supponiamo che l'attaccante conosca n B blocchi di le e n b bit tra i blocchi che non conosce. Si ha allora che p = (1 ε) = n B B F + n b F Indichiamo con p B = n B B F e con p b = n b F la probabilità che l'attaccante conosca un dato blocco la probabilità che conosca un singolo bit di un blocco che non possiede. Indichiamo con guess B l'evento in cui l'avversario riesce a ricostruire l'intero blocco. Dopo alcuni calcoli si ottiene: P (guess B ) = p B + (1 p B )(p b + (1 p b )g) B dove g è la probabilità che l'attaccante indovini un singolo bit sconosciuto. Nel calcolare la probabilità di vittoria dell'attaccante su una singola sda, bisogna tenere conto anche del false positive rate: se l'attaccante non riesce a 15

17 ricostruire esattamente l'intero blocco puo' comunque riuscire a superare la sda avvalendosi dei falsi positivi che l'uso del ltro di Bloom comporta. allora: Indichiamo con win l'evento in cui l'attaccante vince la singola sda. Si ha P (win B ) = P (win B (guess B guess B )) = p B + (1 p B )(fpr + (p b + (1 p b )g) B (1 fpr)) Ricordando che l'attaccante viene sdato su j blocchi, si ha: P (win) = P (win B ) j = (p B + (1 p B )(fpr + (p b + (1 p b )g) B (1 fpr))) j (5) Da questa equazione possiamo ricavare un limite inferiore per il numero di sde j: k ln2 j = (1 p B ) (1 (fpr + (p b + (1 p b )g) B (1 fpr))) Attraverso quest'ultima equazione si deduce che la miglior strategia che l'avversario puo' mettere in atto, quella che richiede il più alto valore per j, corrisponde a quella in cui l'avversario raggruppa tutta la sua conoscenza del le in blocchi di dimensione B; eguagliando a zero p b (p b = 0) e, di conseguenza, p B = p = (1 ε) si ha dunque: k ln2 j = ε (1 fpr) (1 g B ) 4 Implementazione e analisi 4.1 Scelte implementative Allo scopo di valutarne l'ecacia, abbiamo implementato il nostro schema bf- POW confrontandone le performance misurate con quelle ottenute utilizzando le implementazioni degli schemi b-pow e s-pow. 16 (6) (7)

18 Tutti i codici sono stati sviluppati in C++ ed è stata utilizzata la libreria OpenSSL Crypto per tutte le operazioni crittograche. Nell'implementazione dello schema bf-pow abbiamo preso come funzione di hash crittograca la funzione di cifratura RC4: per generare l'output della dimensione voluta, abbiamo passato alla funzione una stringa di zeri della dimensione dell'output impostata ed utilizzato come chiave il digest del blocco di le precedentemente calcolato; come funzione pseudo-random (R s ), è stata invece scelta la funzione HMAC. Per i ltri di Bloom è stata utilizzata l'implementazione fornita da Nicolas Bernard in [10]. 4.2 Scelta dei parametri Per misurarne le performance, le implementazioni dei tre schemi sono state fatte girare su una macchina a 64 bit con SO Ubuntu 12.10, processore Pentium(R) Dual-Core CPU E GHz(x2), 3,9 GiB di RAM. Tutti e tre gli schemi sono stati testati su le generati in modo random; la dimensione dei le in input inizia da 1 MiB no ad arrivare a 2 GiB, raddoppiando ad ogni step. La scelta del valore dei parametri dello schema b-pow, così come dello schema s-pow, sono state fatte attenendosi rispettivamente alle scelte adottate in [3] e in [4]. Per garantire un giusto confronto, anche per lo schema bf-pow il valore del parametro di sicurezza è stato ssato, come negli altri schemi, a 66, così come i valori p delle frazioni di le conosciute dall'attaccante sono stati presi nello stesso insieme utilizzato per s-pow (p {0.5, 0.75, 0.9, 0.95}). Il nostro schema ha inoltre altri due parametri liberi: il false positive rate e la dimensione dell'output della funzione RC4. Il valore di tutti quanti questi quattro parametri 17

19 sono necessari per derivare poi un valore per il numero di blocchi j richiesti in ogni sda, dall'equazione 7. Al false positive rate abbiamo assegnato il valore 0.1. Per quanto riguarda la dimensione dell'output dell'algoritmo di cifratura RC4 invece, abbiamo scelto i valori (espressi in Byte) nell'insieme {16, 256, 512}. Altri parametri del nostro schema sono la dimensione del ltro di Bloom m, utilizzato per rappresentare il le, e il numero di funzioni di hash utilizzate dal ltro, k. Una volta calcolato il numero di blocchi in cui il le viene diviso (n) e scelto il false positive rate, abbiamo utilizzato rispettivamente le formule 4 e 3 per calcolare i valori ottimali. Ricordiamo che, per garantire i 64 MiB di contenuto indispensabile per superare ogni sda, necessari per dissuadere i client maliziosi dall'attuare un attacco CDN (come asserito da Halevi et al. [3]), il valore della dimensione dei blocchi è stato derivato utilizzando la dimensione dell'output dell'rc4: per le inferiori a 64 MiB, la dimensione dei blocchi coincide con quella dell'output dell'rc4 mentre per le più grandi, ssata la dimensione del le, la dimensione dei blocchi è direttamente proporzionale alla dimensione del le in input con costante di proporzionalità pari a C/64M ib. Ogni congurazione è stata fatta girare per 100 volte. Tutti i graci di questa tesi sono stati generati riportando il valore medio e la deviazione standard (utilizzando un box-plot) del numero dei cicli di clock estratti utilizzando l'istruzione assembly RDTSC. 4.3 Lato client Analizziamo e confrontiamo ora le performance del lato client dei tre schemi b-pow, s-pow e bf-pow. Per tutti e tre gli schemi, il lato client prevede il calcolo dell'hash dell'intero le seguito, in b-pow, dall'esecuzione della fase di reduction e mixing ed il 18

20 calcolo dell'albero di Merkle, in s-pow, dalla generazione degli array di bit di risposta, mentre in bf-pow, dall'esecuzione dell'algoritmo 2. La Figura 1 mostra i risultati dei test condotti sui tre schemi per il lato client mentre in Figura 2 sono riportati i diversi tempi di esecuzione del nostro schema, misurati per i diversi valori della dimensione dell'output dell'rc4 settati. Tutte e tre le soluzioni mostrano una crescita lineare rispetto alla dimensione dei le in input; la ragione di ciò è dovuta al fatto che, per tutti e tre gli schemi, leggere e calcolare l'hash del le sono le operazioni predominanti. bf-pow è da un minimo di 1,2 no ad un massimo di 4 volte più veloce di b-pow; s- POW invece computazionalmente più vantaggiosa della nostra soluzione no ad un massimo di 1,4 volte. Figura 1: Confronto tra i tempi di esecuzione del client di bf-pow con valore della dimensione dell'output dell'rc4 impostato a 512 Byte, per i diversi valori di j, con quelli di b-pow e di s-pow, per dierenti valori di K, al crescere della dimensione dei le in input. 19