Operazioni tipiche e Complessità - Una soluzione scalabile: Izzie

4.4 Una soluzione scalabile: Izzie

4.4.7 Operazioni tipiche e Complessità

Operazioni su singoli Utenti/Gruppi/Collezioni/Risorse

Operazioni su singole entità come Utenti, Gruppi, Collezioni e Risorse sono ovviamente le più frequenti data la loro natura altamente operativa. Il framework Izzie è stato concepito per favorire e privilegiare tali operazioni, che comprendo- no la lettura o la modifica di una Risorsa o delle informazioni associate ad una Collezione e in generale l’assegnazione di privilegi di lettura o scrittura ad un Cliente o un Gruppo. Ambedue le tipologie di operazioni richiedono un’operazione asimmetrica che funge da punto di accesso alla struttura dati crittografica di interesse (lettura o scrittura) e un numero di operazioni simmetriche per percorrere la catena simmetrica fino alla risorsa/collezione di interesse. A seconda dell’implementazione sarà poi necessaria un’ulteriore operazione asimmetrica per la firma (in modifca) o la verifica (in lettura) dei dati della collezione/risorsa. Tali operazioni hanno quindi una complessità trascurabile.

Lettura contemporanea di più risorse/collezioni

La lettura "contemporanea" di più risorse (ed eventualmente anche di collezioni di risorse) è un’altra tra le operazioni privilegiate dal framework Izzie. La natura simmetrica della catena crittografica di lettura permette un eﬃciente e veloce recupero delle informazioni (sfruttando link puramente simmetrici). A titolo di esempio, risulterebbe ora molto sensato usare l’approccio proposto dal framework per l’implementazione di un servizio di memorizzazione di album fotografici (stile galleria di uno smartphone). La visualizzazione delle anteprime delle foto (risorse) dei vari album (collezioni) ora non comporta i problemi analizzati nella sezione 4.3.3).

Tuttavia la lettura contemporanea di più risorse potrebbe portare a situazioni meno eﬃcienti se entra in gioco anche la verifica di integrità. Ogni operazione di modifica (compresa creazione) necessita infatti di una verifica mediante una strategia asimmetrica (secondo quanto visto nell’analisi della struttura Write Ac- cess Control nella sezione 4.4.6). Dal punto di vista implementativo quindi è molto importante non sottovalutare le performance e le tipologie di strategie di verifica di integrità dei dati, e le particolari tecnologie ed algoritmi. Va anche detto però che uno sviluppatore (anche alle prime armi nel campo crittografico e delle complessità relative) può trarre vantaggio dal fatto che i maggiori standard e algoritmi come RSA sono stati già ideati con la capacità per un’operazione di verifica di avere performance notevolmente superiori della relativa operazione di firma. Quindi in definitiva sebbene la presenza di un significativo numero di operazioni asimmetriche di verifica sia un problema dal punto di vista teorico, poi in pratica le operazioni crittografiche asimmetriche di verifica (e si sottolinea esclusivamente di verifica) riescono ad avere un peso minore delle corrispondenti operazioni di firma.

Complessità

Un’analisi astratta ma precisa della complessità non è un compito banale. Mol- to dipende dalla particolare natura implementativa del problema/servizio che si intende implementare. Per questo motivo viene proposta un’analisi che fa uso di valori medi, in cui:

- p: indica la media dei punti di accesso asimmetrici alla struttura crittografica di lettura (o scrittura) per un utente o un gruppo

- n: indica il numero medio di risorse/collezioni contenute in una collezione - l: indica la profondità media di una risorsa (foglia) da un generico punto di accesso della struttura crittografica di lettura (o scrittura)

In base a questi valori, otteniamo le seguenti valutazioni:

O(p) operazioni asimmetriche di accesso alla catena di lettura (scrittura) O(p_⇤ Pl

k=1

nk₎_{operazioni simmetriche di lettura}

O(p_⇤Pl

k=1n

k₎_{operazioni asimmetriche di verifica (a seconda dell’implementazione)}

Revoca dei privilegi di lettura/scrittura per una Risorsa

Revocare i privilegi di lettura per una Risorsa implica impedire ad un cliente/- gruppo che abbia accesso diretto alla risorsa (mediante link asimmetrico verso la sua chiave simmetrica RK) di continuare ad avere la possibilità di decifrarne il contenuto. Questo ovviamente si traduce nella creazione di una nuova chiave di cifratura simmetrica di risorsa RK (far riferimento alla figura 4.17 per la terminologia). Ma ciò non basta, occorre mantenere l’accesso in lettura ai clienti/gruppi ancora attivi. Per prima cosa è necessario mantenere la possibilità di accesso tramite catena simmetrica di lettura, aggiornando quindi il link simmetrico dalla chiave SK della collezione (in cui la Risorsa è contenuta) verso la nuova chiave della risorsa RK. Successivamente è necessario anche mantenere l’accesso ai clienti/gruppi che usino un accesso diretto verso la risorsa, aggiornando quindi i vari link asimmetrici (usando le chiavi pubbliche dei clienti/gruppi abilitati). Ricordo che l’aggiornamento del link simmetrico di risorsa (da RK alle vere informazioni della risorsa) può essere posticipato usando il meccanismo di lazy revocation, e quindi non viene considerato nell’analisi della complessità (anche se trascurabile). La revoca dei privilegi di scrittura per una Risorsa segue gli stessi principi, l’unica diﬀerenza è che si opera sulla struttura crittografica di scrittura e che di conseguenza cambiano le chiavi che entrano in gioco (WSK e k_sign se si fa riferimento alla figura 4.18).

Complessità

Un’analisi astratta ma precisa della complessità non è un compito banale. Mol- to dipende dalla particolare natura implementativa del problema/servizio che si

intende implementare. Per questo motivo viene proposta un’analisi che fa uso di valori medi, in cui:

- p: indica la media dei punti di accesso asimmetrici ad una singola risorsa in lettura (o scrittura)

In base a questi valori, otteniamo le seguenti valutazioni:

O(p) operazioni asimmetriche per la rivelazione della nuova chiave simmetrica (RK o WSK)

O(1) operazioni simmetriche (trascurabili)

Revoca dei privilegi di lettura per una Collezione

Per revoca dei privilegi di lettura per una Collezione si intende impedire ad un cliente/gruppo che abbia accesso diretto alla collezione (mediante link asimmetrico verso la sua chiave simmetrica SK) di continuare ad avere la possibilità di decifrarne il contenuto; che comprende sia le informazioni relative alla collezione, sia la possibilità di recuperare collezioni e risorse in essa contenute. Questo ovviamente si traduce nella creazione di una nuova chiave di cifratura simmetrica di sotto-collezione SK (far riferimento alla figura 4.18 per la terminologia). Ma ciò non basta, occorre mantenere l’accesso in lettura ai clienti/gruppi ancora attivi. Per prima cosa è necessario mantenere la possibilità di accesso tramite catena simmetrica di lettura, aggiornando quindi il link simmetrico dalla chiave SK della collezione padre (in cui la Collezione è contenuta) verso la nuova chiave della collezione in esame SK. Successivamente è necessario anche mantenere l’accesso ai clienti/gruppi che usino un accesso diretto verso la collezione, aggiornando quindi i vari link asimmetrici (usando le chiavi pubbliche dei clienti/gruppi abilitati). Ricordo che l’aggiornamento del link simmetrico da CK alle vere informazioni della collezione può essere posticipato usando il meccanismo di lazy revocation, e quindi non viene considerato nell’analisi della complessità (anche se trascurabile). Occorre però considerare cosa accade alle collezioni e alle risorse contenute nella collezione aﬀetta da revoca dei permessi. Questo non è un compito banale e molto dipende dall’implementazione e dal livello di strategie di lazy revocation e key regression che sono state utilizzate. Posticipare l’aggiornamento dei link della catena di lettura (SK –> SK, SK –> RK) potrebbe portare a situazioni di stallo o deadlock nel caso in cui le sotto-collezioni o sotto-risorse siano aﬀette da

ulteriori accessi diretti medianti link asimmetrici. L’analisi degli scenari plausibili tuttavia non è nello scopo della dissertazione, ma per approfondimenti si può far riferimento a [33]. Per l’analisi della complessità si usa un approccio più conservatore e si suppone che ogni chiave di sotto-collezione SK (della catena di collezioni contenute nella collazione aﬀetta da revoca) venga aggiornata insieme al relativo link simmetrico SK. L’aggiornamento di ogni chiave SK comporta la necessità di rivelare la nuova chiave SK agli utenti/gruppi che hanno il punto di accesso (link asimmetrico) alla catena mediante tale chiave. Per le informazioni di collezione (e relativa chiave CK, quindi link simmetrici SK–>CK e CK–>INFO) viene invece sfruttata la strategia di lazy revocation. Per quanto riguarda le risorse l’aggiornamento del link SK–>RK (con una nuova chiave RK) è necessario qualora ci siano dei punti di accesso diretti (asimmetrici) verso la risorsa (e quindi verso RK), altrimenti è possibile sfruttare la strategia di lazy revocation per ambedue i link simmetrici (SK–>RK, RK–>INFO).

Complessità

- p: indica la media dei punti di accesso asimmetrici ad una singola collezione in lettura

In base a questi valori, otteniamo le seguenti valutazioni: O(Pl

k=1n

k₎ _{operazioni simmetriche di aggiornamento dei link}

O(Pl

k=1n

k_{⇤ p) operazioni asimmetriche per la rivelazione delle nuove chiavi}

NB: questi studi sulla complessità devono essere valutati (specialmente per questa operazione) esclusivamente come un’indicazione astratta e teorica (al caso medio). Si ribadisce che le performance eﬀettive dipendono in larga parte dalla natura del servizio che si intende implementare e dalle tecnologie e strategie di ottimizzazione

(come lazy revocation) utilizzate.

Revoca dei privilegi di scrittura per una Collezione

Per revoca dei privilegi di scrittura per una Collezione si intende impedire ad un cliente/gruppo che abbia accesso diretto alla collezione (mediante link asimmetrico verso la sua chiave simmetrica WSK) di continuare ad avere la possibilità di ottenere la chiave asimmetrica per la firma delle modifiche (k_sign se si fa riferimento alla figura 4.18). Il principio è il medesimo visto per la revoca in lettura per una Collezione (e non viene quindi ripetuto). Tuttavia è bene ricordare che in questo caso non devono essere considerati ulteriori meccanismi di lazy revocation, non è possibile infatti posticipare alcuna operazione o si ridurrebbe la sicurezza intrinseca nell’approccio utilizzato.

Eliminazione di un gruppo/cliente

Eliminare un gruppo o un cliente dal framework significa essenzialmente impedir- gli di riuscire a percorrere le catene crittografiche di lettura e scrittura (in base ai privilegi). Questo comporta un’evidente necessità di aggiornamento delle chiavi e dei link che riesce a percorrere. L’aggiornamento comporta inevitabilmente l’e- sigenza di rivelare le nuove chiavi ai clienti e gruppi che ancora hanno i privilegi sulle collezioni e risorse aﬀette da questa operazione. Calcolare la complessità non è quindi banale, e va detto che questa operazione è una tra le più privilegiate per il framework. É bene quindi fare in modo che solo gli amministratori abbiano tali privilegi. Inoltre, data la struttura del framework, questo tipo di operazione diventa critica solo all’aumentare dell’importanza del cliente/gruppo aﬀetto da eliminazione. Nella realtà (anche aziendale) quindi è molto raro che un cliente o un gruppo importante per il framework (ovvero con punti di accesso molto vicini alla radice) venga eliminato.

Altre operazioni

Tutte le altre operazioni sulle catene crittografiche seguono i principi appena analizzati. É importante ricordare e sottolineare il fatto che l’approccio usato dal framework Izzie fa si che le operazioni comuni e altamente frequenti siano di fatto trascurabili come complessità e tempi eﬀettivi di esecuzione. Mano a mano che

crescono i privilegi sulle catene crittografiche le operazioni di gestione si fanno più complesse e critiche, ma molto meno frequenti. La struttura dati copre quindi la grande maggioranza delle situazioni implementative, dove un’entità con alti privilegi ed alte responsabilità è consapevole delle caratteristiche di funzionamento del framework e riesce ad sfruttarlo al meglio in ogni situazione, nonostante la presenza di alcune operazioni molto critiche. L’utente medio invece, dati i privilegi più ridotti non è abilitato ad operazioni critiche che potrebbero compromettere le performance e la scalabilità dell’intera struttura.

Nel documento SSaaS: a proposal for Secure Software as a Service (pagine 110-116)