Izzie: principi generali

L’obiettivo del framework Izzie è riuscire a risolvere i problemi di performance analizzati nella sezione 4.1 per quelle categorie di soluzioni reali che richiedono un alto tasso di operazioni crittografiche asimmetriche; quindi servizi caratteriz- zati da un alto numero di clienti e risorse e da un alto grado di accoppiamento tra le due categorie. Affinché ciò sia possibile occorre trovare una strategia per diminuire in modo sostanziale il numero di operazioni crittografiche asimmetri- che coinvolte nella gestione e nell’utilizzo della struttura dati crittografica che si intende creare.

Intuizione dai dati sperimentali

La tabella 4.2 potrebbe fornire al lettore un’intuizione sul modo di procedere, forti del fatto che la visione non è più di tipo flat, anzi sono consentiti e promossi raggruppamenti e insiemi di clienti e risorse in gruppi e collezioni. La tabella 4.2 riporta infatti una comparazione tra numero di operazioni crittografiche sim- metriche (che coinvolgono informazioni dell’ordine massimo di qualche Kbyte) e tempo medio di esecuzione prendendo in considerazione tre tipologie diverse di client device: un pc di fascia bassa (entry-level), un pc di fascia media (mid- range) e uno di fascia alta (high-end). Per dettagli hardware aggiuntivi si faccia riferimento all’appendice A. Lo schema di cifratura simmetrica usato è il classi- co e diffuso AES con chiavi di cifratura della lunghezza di 256 bit (attualmente considerate adeguatamente sicure) e avvalendosi dell’ambiente di sviluppo (ed esecuzione) Java.

n op entry-level mid-range high-end 1000 0.725 0.01 0.01 10000 1.118 0.03 0.03 100000 1.554 0.16 0.108 1000000 4.761 1.07 0.505 10000000 37.519 10.187 4.663 Tabella 4.2: AES 256 bit time comparison (seconds)

La tabella riassume un fatto molto evidente, le operazioni crittografiche sim- metriche (che coinvolgono un ammontare di dati trascurabile e quindi dell’ordine massimo di qualche Kbyte) hanno notevoli performance anche su grandi volumi (a differenza di quelle asimmetriche già proposte in 4.1). É chiaro ora che un sensato modo di procedere è quello di studiare e approfondire metodologie e architetture che privilegino l’uso di link simmetrici piuttosto che asimmetrici, usufruendo di questi ultimi solo quando strettamente necessario, per operazioni meno frequenti e con un grado di privilegi più elevato rispetto a normali operazioni di routine.

Sfruttare le Collezioni

L’introduzione delle Collezioni di risorse non è motivata solo dal punto di vista delle feature offerte dalla struttura dati crittografica. Le collezioni infatti giocano un ruolo chiave nell’abbassamento della complessità delle operazioni crittografiche asimmetriche. La figura 4.14 introduce questa idea.

Figura 4.14: Idea: sfruttare le collezioni

Collegando un insieme di risorse ad una medesima Collezione mediante link simmetrici e a sua volta collegando una generica collezione ad un insieme di Clienti (utenti) l’ordine di complessità di operazioni come la lettura di più risorse diventa di O(1) operazioni asimmetriche e O(n_resource) operazioni simmetriche (dove n_resource è il numero di risorse della collezione in esame). Questa semplice idea è già sufficiente ad estendere la tipologia di servizi implementabili nel mondo reale. Basti pensare a raccoglitori di foto o immagini personali. Operazioni tanto semplici, quanto scontate, come l’anteprima delle immagini (Risorse) di un album (Collezione) possono essere ora implementate senza problemi. Attenzione, la figura 4.14 va considerata come una semplice idea, vengono mantenute infatti le nozioni sulle chiavi di risorsa (RK) e cliente (CKP) presentate nella sezione 4.3.2, ma è chiaro che queste da sole non bastano e per la realizzazione del framework

altri link e strumenti devono essere introdotti e formalizzati (sarà il compito delle sezioni successive).

A sua volta una collezione può essere collegata ad altre collezioni (sempre mediante link simmetrici) come mostrato in figura 4.15. Questo per evitare che il collo di bottiglia (e il punto debole) si sposti dalle risorse alle collezioni per strutture dati (a grafo) di grandi dimensioni e complesse.

Figura 4.15: Idea: collezioni di collezioni

Immaginando una struttura dati ad albero (come un file system tradizionale) l’idea vincente è quindi quella di limitare i link asimmetrici al collegamento tra clienti (utenti) e collezioni tanto il più possibile al vertice dell’albero quanto sia il grado di privilegi che ha l’utente verso la struttura dati. Un amministratore ad esempio sarà collegato al vertice (root) dell’albero, mentre mano a mano che i

privilegi diminuiscono i collegamenti asimmetrici saranno a loro volta in posizioni più basse. Attenzione, anche la figura 4.15 va considerata come una semplice idea, per semplicità (rispetto alla figura 4.14) sono state eliminate le chiavi simmetriche e asimmetriche di risorse e clienti , ma è chiaro che la struttura necessita di essere arricchita e formalizzata (sarà il compito delle sezioni successive).

Sfruttare i Gruppi

L’idea di usare le collezioni tuttavia non è sufficiente. All’aumentare degli utenti di una collezione si presenterebbe infatti ancora il problema dell’eccessivo numero di operazioni crittografiche asimmetriche coinvolte (per certe categorie di opera- zioni sulla struttura dati crittografica). Una strategia vincente è quindi quella di usare anche insiemi di clienti, d’ora in poi riferiti come Gruppi. Collezioni o risorse caratterizzate da un grande numero di clienti (quindi con molti link asim- metrici) possono essere ora collegate direttamente a Gruppi di clienti (utenti) con una conseguente diminuzione dei link crittografici asimmetrici coinvolti. La figura 4.16 schematizza questo concetto. Operazioni come l’aggiunta di risorse e collezioni ad un insieme di clienti ora può essere gestita con O(1) operazioni asim- metriche, è necessario infatti un semplice link asimmetrico tra la nuova collezione (o risorsa) e il Gruppo di clienti in questione.

Attenzione però, anche la figura 4.16 va considerata come una semplice idea, è chiaro che la struttura necessita di essere arricchita e formalizzata per poter essere pienamente operativa e soddisfare sia i vincoli funzionali che quelli di scalabilità (sarà il compito delle sezioni successive).

Verso il framework completo

Risorse, Clienti, Collezioni e Gruppi sono le entità principali che entrano in gio- co nella costruzioni della struttura dati crittografica completa denominata Izzie. I vincoli sia funzionali che di scalabilità vengono rispettati sfruttando in modo intelligente link crittografici simmetrici e link crittografici asimmetrici astraendo di fatto importanti principi e protocolli crittografici alla base della sicurezza del- l’intero framework. Affinché il framework sia sufficientemente astratto ed adatto ad ogni tipologia di servizio (reale), nelle sezioni successive vengono introdotti strumenti, definizioni e flussi che consentono di gestire e diversificare operazioni tipiche effettuabili su strutture dati astratte: come lettura, scrittura, aggiunta e

Figura 4.16: Idea: gruppi di clienti

revoca di privilegi. A titolo di esempio, basti pensare al semplice concetto di base di dati: è possibile creare entità e relazioni (tabelle e righe) ed operare su di esse sia in lettura che in scrittura in base ai privilegi a disposizione, per un utente è possibile inoltre avere i privilegi necessari a concedere o revocare categorie di privilegi ad altri utenti, e così via. Al momento la struttura dati classica ACL introdotta nella sezione 4.3 non consente un tale livello di flessibilità e potenza, che di fatto è un problema anche dal punto di vista della sicurezza, dell’integrità e dalla consistenza della struttura dati stessa.