Write Access Control

Sebbene sia possibile limitarsi a sfruttare la struttura dati crittografica Read Ac- cess Control, alcune tipologie di servizi richiedono livelli di sicurezza maggiori. La struttura Read Access Control infatti, da sola, non è in grado di gestire si- tuazioni in cui privilegi di lettura possono essere diversi dai privilegi di scrittura. In un file system tradizionale ad esempio questa diversificazione è assolutamente

necessaria. Impedire l’accesso in scrittura su directory critiche (come quelle di sistema) a determinate categorie di utenti consente ad esempio di salvaguardare l’integrità dell’intero sistema e di proteggersi anche dai possibili effetti indotti dai comuni tipi di attacchi informatici (come un banale buffer overflow).

Per questi motivi viene presentato anche un approccio combinato che con- sente di differenziare le operazioni di lettura e di scrittura mediante un’ulteriore struttura dati crittografica denominata Write Access Control. Come nel caso del- la struttura di lettura (sezione 4.4.3), anche per la struttura dati crittografica di scrittura risulta molto più naturale e comprensibile presentare un reale esempio implementativo, per poi analizzarne in dettaglio ogni suo aspetto in modo da riuscire anche a non perdere l’impronta astratta usata in questa dissertazione. Per tale motivo si supponga che la struttura crittografica Write Access Control sia stata utilizzata per l’implementazione del file system di una grande azienda. L’esempio è il medesimo della sezione 4.4.3, ed file system sarà quindi caratteriz- zato da una grande mole di dati (file) suddivisi tra i vari dipartimenti e tra i vari gradi di privilegi dei dipendenti e manager dell’azienda.

Questa volta però il file system è più complesso e consente di gestire in modo separato i permessi di lettura e di scrittura sui vari file e directory. Uno snapshot di tale struttura viene proposto nella figura 4.18. Intuitivamente la figura è già sufficiente a capire quali sono le entità in gioco ed i loro ruoli. Brevemente, il CEO ha privilegi di lettura e scrittura su tutti i dipartimenti della sua azienda, il CTO invece è in grado di operare (sia in lettura che in scrittura) solo sul dipartimento informatico IT. A loro volta gli sviluppatori web hanno privilegi di lettura e scrittura sull’area Web del dipartimento IT, mentre lo sviluppatore di terze parti (esterno all’azienda) ha l’accesso solo in lettura al semplice file home.html. Resta da capire come tutto ciò sia effettivamente possibile e quali sono i principi (link) crittografici necessari affinché non ci siano situazioni critiche dal punto di vista delle sicurezza.

Partendo dalle collezioni, che nell’esempio in figura 4.18 corrispondono a direc- tory del file system, sono previste una coppia di chiavi crittografiche asimettriche ed una chiave simmetrica:

(k_sign) Private Signature Key è la parte privata della coppia di chiavi asimmetriche associate ad un’operazione di scrittura. Tale chiave serve a firmare una generica operazione sulla collezione, e quindi a provare che si posseggono i privilegi di scrittura su tale collezione. Avere il privile- gi di scrittura è sinonimo quindi di essere in grado di ottenere la k_sign associata ad una collezione. Il modo in cui si prova la legittimità di un’o- perazione dipende molto da chi implementa la struttura crittografica Write Access Control. A titolo informativo, una strategia comune è quella di crea- re un hash delle informazioni modificate e poi firmarle con k_sign, ma per ulteriori approcci si faccia riferimento a [21] e [46].

(k_verify) Public Signature Verification Key è la parte pubblica della cop- pia di chiavi asimmetriche associate ad un’operazione di scrittura. Tale chiave serve a verificare che una generica operazione sulla collezione sia sta- ta effettivamente eseguita da un cliente/gruppo (utente nell’esempio 4.18) a conoscenza della controparte k_sign e quindi avente i privilegi di scrittu- ra su tale collezione. La verifica dipende ovviamente dalla strategia usata per l’implementazione della firma della legittimità di un’operazione (o firma digitale).

(WSK) Write SubCollection Key è la chiave simmetrica che consente di ot- tenere le chiavi Private Signature Key di ogni collezione/risorsa contenute nella collezione a cui WSK fa riferimento, nonché la propria. Un cliente o un gruppo che ha accesso a tale chiave, sarà dotato quindi dei privilegi di scrittura sulla collezione a cui riferimento e su tutte le collezioni e risor- se in essa contenute. Nell’esempio di figura 4.18 il CEO ha i privilegi di scrittura su ogni dipartimento, mentre il CTO solamente sul dipartimento IT. Gli sviluppatori interni hanno accesso di scrittura alla directory Web del dipartimento IT, mentre lo sviluppatore di terze parti è provvisto dei soli privilegi di lettura del file home.html. Le operazioni di scrittura su una collezione comprendono ovviamente la possibilità di creazione di risorse (o collezioni) appartenenti a tale collezione.

Le risorse non aggiungono nulla in particolare a quanto detto per le collezioni, ogni risorsa è provvista quindi di una coppia di chiavi asimmetriche (k_sign e k_verify) per la firma di una generica operazione di scrittura sulla risorsa. Non è necessaria invece una chiave simmetrica WSK dato che una risorsa rappresenta una foglia nell’albero crittografico e non è di conseguenza dotata di sotto collezioni o sotto risorse.

Il lettore possiede ora gli strumenti necessari per comprendere appieno la semantica della struttura dati crittografica usata nell’esempio in figura 4.18, il tutto si basa su due tipologie di link crittografici:

Resource/Collection Write Symmetric Links link crittografici simmetrici necessari a percorrere la catena crittografica simmetrica di scrittura e rag- giungere la chiave privata di firma (k_sign: Private Signature Key)

User/Group Write Asymmetric Links link crittografici asimmetrici neces- sari a fornire a clienti e gruppi un punto di accesso alla catena crittografica simmetrica di scrittura in base al loro livello di privilegio. Clienti e gruppi più privilegiati avranno un punto di accesso vicino alla radice dell’albero delle collezioni (CEO e CTO nell’esempio in figura 4.18), mentre clienti e gruppi meno privilegiati avranno un punto di accesso vicino alle foglie del- l’albero delle collezioni o in alternativa nessun punto di accesso se i privilegi si limitano alla lettura.

Problemi

La struttura dati crittografica Write Access Control evidenzia un fatto tipico quando si parla di sicurezza. L’aggiunta di meccanismi di protezione, come la possibilità di gestire in modo separato privilegi di lettura e di scrittura porta ad un’inevitabile aggiunta di complessità. Il lettore attento avrà notato che sebbene nella struttura Read Access Control 4.4.3 si è cercato di limitare il più possibile l’utilizzo di link asimmetrici, ora di fatto sono state introdotte ulteriori chiavi asimmetriche (k_sign e k_verify) per ogni collezione/risorsa (directory e file nel- l’esempio in figura in figura 4.18) necessarie per la firma di ogni operazione di scrittura. Questo potrebbe sembrare un grosso problema, ed in effetti lo è dal punto di vista teorico. Una generica operazione di lettura infatti ora necessita di un overhead dovuto alla verifica della legittimità dell’ultima operazione di scrit- tura eseguita sulla collezione/risorsa target. Inevitabilmente si è reintrodotto il problema del numero di operazioni crittografiche asimmetriche.

Tuttavia dato che tale problema si limita alla sola verifica di integrità, a livello implementativo possono essere usate delle strategie intelligenti per "razionare" o "bufferizzare" le operazioni di verifica in base al carico di lavoro del device su cui si sta operando. Presentare possibili soluzioni non è nello scopo di questa dis- sertazione, che vuole rimanere astratta per non precludere ogni possibile scelta implementativa e ulteriori stimoli di ricerca. Va detto tuttavia che questo proble- ma è molto legato non solo alle scelte implementative (in fattispecie gli algoritmi e le tecnologie crittografiche) ma anche alla tipologie di servizio SaaS che si in- tende sviluppare e ai suoi gradi di accoppiamento e di sicurezza tra clienti/gruppi e collezioni/risorse. Inoltre algoritmi come l’RSA (tra le più diffuse soluzioni crittografiche di tipo asimmetrico) presentano la particolare caratteristica che operazioni di verifica e di cifratura sono molto più veloci delle operazioni di firma e decifratura. Questo è un risultato prettamente matematico, che deriva dal- l’ordine di grandezza dell’esponente usato per le operazioni di firma/decifratura (decisamente più grande) e verifica/cifratura (più piccolo). Per approfondimenti matematici e dimostrazioni si faccia riferimento a [21] e [46]. Se si vuole avere un risultato più immediato si può fare riferimento ai vari Benchmark disponibili in rete [47] [19] .

Ottimizzazioni

La struttura Write Access Control non consente di vaste possibilità di ottimiz- zazione. A differenza di quanto analizzato nella sezione 4.4.8, strumenti come lazy revocation o key regression risultano molto difficili da applicare e da astrar- re. Di fatto quando si revoca il permesso in scrittura di una collezione/risorsa occorre immediatamente invalidare la coppia crittografica asimmetrica necessa- ria per la firma. Questo comporta la generazione di una nuova coppia di chiavi crittografiche di firma/verifica e il conseguente aggiornamento dei link crittogra- fici (asimmetrici/simmetrici) verso quest’ultima (ovviamente senza considerare il cliente/gruppo appena rimosso dai permessi). Soluzioni di ottimizzazione sono quindi incoraggiate ad un livello più implementativo, in base ai requisiti del ser- vizio che si sta realizzando, alle tecnologie utilizzate e alla strategia di gestione della legittimità di un’operazione.