Sicurezza nella fase di storage

Quando viene utilizzato un algoritmo di sicurezza basato sul certificato, ogni coppia ID di risorsa/ID di tipo fornita, viene limitata da alcuni set ridotti di certificati. Per scrivere i dati in uno slot il possessore deve fornire la prova di essere in possesso della chiave privata di uno di questi certificati; in più tutti i dati salvati vengono firmati dal certificato che autorizza l’immagazzinamento. Questo set di regole rende le richieste di autorizzazione e di integrità dei dati relativamente semplici.

Quando viene utilizzato un algoritmo di sicurezza a chiave segreta condivisa, ogni peer verifica tutti gli altri, garantendo così il rispetto delle credenzialità per poter effettuare l’ingresso nel sistema.

Quindi, mentre nel secondo meccanismo di sicurezza prima introdotto non ci sono molti problemi riguardo a verifiche ed a correttezza nei meccanismi di scambio di informazioni tra i vari peer, nel primo meccanismo bisogna valutare attentamente le varie fasi che compongono lo storage.

• Autorizzazione

Se un client volesse salvare un particolare valore in uno slot, dovrebbe innan- zitutto firmare il valore con la sua chiave privata e quindi mandare una Store Request, contenente sia il valore che la firma, verso il peer dedicato all’imma- gazzinamento. Nel momento in cui il peer riceve la richiesta dovrà determinare se il client è autorizzato a salvare dati in quel particolare slot; per fare questo eseguirà un algoritmo di tipo Resource Name Construction, utilizzando come parametri il tipo del valore da salvare e le informazioni del certificato dell’u- tente. Al termine di questa operazione verrà calcolato l’ID di risorsa tramite il Resource Name e si verificherà la corrispondenza con lo slot nel quale l’utente ha deciso di immagazzinare l’informazione. Se questa è verificata allora si può con- cludere che l’utente sarà autorizzato a scrivere in quel particolare slot, altrimenti l’autorizzazione verrà negata e la richiesta sarà immediatamente bloccata.

3.4. CONSIDERAZIONI SULLA SICUREZZA

• Distribuzione di quote dei dati

Essere un peer all’interno di una rete di overlay comporta la responsabilità di immagazzinare dati per una data regione dell’overlay. Tuttavia, se i client fos- sero autorizzati a salvare quantità di dati illimitate, questo potrebbe portare il peer responsabile ad avere oneri inaccettabili ed essere, di conseguenza, molto esposto a varie tipologie di attacchi.

RELOAD risolve questo problema imponendo come caratteristica base di ogni usage una dimensione massima di dati immagazzinabili per ogni tipologia di da- ti. Tentativi di salvataggio di valori che eccedono questi limiti vengono respinti e nel caso in cui il peer risultasse inconsistente la rete è in grado di intervenire con un meccanismo tramite il quale viene cambiata la zona di responsabilità ed altri peer possono diventare responsabili dei dati troppo grandi; inoltre, siccome ogni slot è anche limitato ad un ristretto set di certificati, queste restrizioni sulla dimensione dei dati creeranno un meccanismo di distribuzione delle quote dei dati amministrato dal server di iscrizione centrale.

La caratteristica di permettere a differenti tipi di dati di avere restrizioni proprie sulle dimensioni conferisce agli usage la flessibilità di poter limitare la forma dei propri dati senza dover imporre un limite generale.

• Controllo della correttezza

Siccome ogni valore immagazzinato viene firmato, è banale per ogni peer verifi- carne l’integrità. Servono però altri interventi per prevenire attacchi di Rollback, che possono portare all’annullamento di tutti gli aggiornamenti effettuati nel corso della transazione. Questa tipologia di attacchi sullo storage viene evitata tramite l’uso di tempi di salvataggio e la creazione di lifetime value in ogni sin- gola operazione di immagazzinamento. Un lifetime rappresenta l’ultimo istante di tempo di validità del dato e la sua presenza riesce a limitare, anche se non previene completamente, attacchi di Rollback.

Per riuscire, invece, a prevenire l’attacco direttamente al momento della Store Request servirà un tempo di storage monotonicamente crescente; in questo mo- do gli storing peer potranno riuscire ad annullare tutte le richieste con tempo di storage minore o uguale a quello che stanno immagazzinando. In più, con questa modifica, se un nodo dovesse recuperare un valore e ne ricevesse uno con tempo di storage maggiore di quello relativo ad una ricerca precedente, riconoscerà un attacco di Rollback e permetterà quindi alla rete di isolare il nodo maligno. I meccanismi descritti garantiscono un alto livello di sicurezza, ma rimangono possibili comunque alcuni attacchi.

Un esempio di attacco molto semplice, ma devastante per l’efficienza della rete, si basa sul fatto che rimane comunque possibile per un nodo rifiutare l’immagazzinamento di un valore. Inoltre un nodo potrebbe fingere di non conoscere valori precedentemente accettati e salvati.

3.4. CONSIDERAZIONI SULLA SICUREZZA

Lo schema di autenticazione basato su certificato offre l’importante funzionalità di prevenire che un singolo peer sia in grado di realizzare dati indicando come autori altri peer; in questo modo un peer sovversivo non potrà immettere in rete dati forgiati da lui in quanto sarà sprovvisto dell’autenticazione per la registrazione, anche se potrà lo stesso danneggiare il sistema rifiutandosi di restituire dati dei quali è responsabile. Per cercare di aggirare questi attacchi la rete potrebbe immagazzinare più repliche dello stesso valore e poi, in fase di ricerca, andare a ricercarne più di una; l’affidabi- lità di questo meccanismo è statistica in quanto, in caso di bassa percentuale di peer compromessi, basterà solo un’esigua percentuale di repliche per rendere affidabile la rete, mentre in caso di molti nodi maligni collusi servirà un alto numero di repliche. Perciò questo procedimento risulta essere innanzitutto molto costoso ed inoltre un client non potrà sapere a priori quando comportarsi nella modalità standard e quan- do introdurre o ricercare le repliche e quindi bisognerebbe introdurre anche questo grado di conoscenza.

Inoltre, in caso di dati multivalore, come per esempio un array, il nodo che li imma- gazzina potrà fornire solamente alcuni sottogruppi di valori, polarizzando così le sue risposte. Questo può essere contrastato utilizzando valori singoli piuttosto che set, rendendo così il coordinamento tra salvataggi multipli più complesso; questo è co- munque un costo ineliminabile e, per incrementare le prestazioni relazionate al costo computazionale, è necessaria una valutazione in fase di design scegliendo il trade-off desiderato.