RICERCA ITALIANA     

Programma di ricerca

Basi di dati crittografate

Università di riferimento

Università degli Studi di BERGAMO - INGEGNERIA GESTIONALE E DELL'INFORMAZIONE - ()

Responsabile dell'Unità di ricerca

Stefano Paraboschi

Descrizione

L'unita' UNIBG coopera con UNIMI e UNISA in WP0 e WP8, supporta il lavoro di UNISA in WP3 e di UNIMI in WP4, e' responsabile di WP6 (con il supporto di UNIMI) e di WP7 (con il supporto di UNISA). Ciascuno dei workpackage principali (da WP1 a WP7) e' focalizzato su un differente aspetto che emerge nella realizzazione di un servizio di base di dati sicuro ospitato da una untrusted third party.

WP0: Stato dell'arte

Questo workpackage ha l'obiettivo di valutare lo stato dell'arte del campo di ricerca. Benche' l'unita' UNIBG abbia una esperienza pregressa diretta nel contesto del progetto, il campo e' in rapida evoluzione e una precisa analisi della situazione riguardo alle principali direzioni di ricerca e risultati recenti e' estremamente utile come preparazione per il lavoro dei workpackage successivi. Il contributo dell'unita' UNIBG al workpackage WP0 sara' un report intermedio WP0-BG-D1-R. Sara' responsabilita' dell'unita' UNIBG combinare questo rapporto con i rapporti prodotti dalle unita' UNIMI e UNISA, per produrre il rapporto di progetto WP0-BG-D2-R che rappresenta il principale deliverable di questo workpackage.

WP3: Prototipo dei servizi crittografici

Questo workpackage ha l'obiettivo di implementare un prototipo delle funzioni crittografiche sviluppate dall'unita' UNISA. Il ruolo dell'unita` UNIBG in questo WP e` di fornire i requisiti che consentano una facile integrazione di questo prototipo all'interno del sistema software costruito in WP7.

WP4: Modelli di controllo dell'accesso per database crittografati

Il lavoro in WP4 parte dalla considerazione che per molte applicazioni di accesso a database vi e' la necessita' di gestire una molteplicita` di utenti, ciascuno con propri requisiti di confidenzialita' e integrita'. Questa e' una linea di ricerca che recentemente e' diventata oggetto di un significativo interesse.

I DBMS relazionali adottano un modello di controllo dell'accesso che e' basato sulla descrizione di autorizzazioni per mezzo di triple (soggetto,oggetto,azione) che sono memorizzate in una tabella del data dictionary. Questo meccanismo richiede che un componente di sistema con i privilegi di database owner implementi un meccanismo di controllo (reference monitor) con la responsabilita' di valutare ciascuna richiesta di accesso proveniente dagli utenti. Nello scenario che stiamo studiando, questo approccio sarebbe extremamente limitativo, dato che imporrebbe ad ogni utente del database di contattare il database owner per sapere esattamente se l'utente ha il diritto di accesso, proibendo all'utente di accedere direttamente al database. Invece, la piena realizzazione del potenziale di questa architettura richiede la definizione di meccanismi che consentono agli utenti di accedere direttamente al database, proteggendo da accessi scorretti di lettura/scrittura per mezzo di adeguate soluzioni crittografiche.

Il lavoro dell'unita' UNIBG in WP4 supportera' l'iniziativa di UNIMI nella definizione di meccanismi che consentiranno la gestione di una pluralita' di utenti con differenti privilegi di accesso. I requisiti di confidenzialita' probabilmente richiederanno di introdurre famiglie di chiavi per crittografare differenti porzioni dei dati, dove ciascuna chiave protegge dati caratterizzati dagli stessi requisiti di protezione. L'integrita' sara' probabilmente basata sulla definizione di servizi di firma che permetteranno agli utenti di verificare se le informazioni ottenute dal database sono corrette o meno.

Uno degli ostacoli piu' grandi nella realizzazione di un sistema che supporti i requisiti di confidenzialita' e integrita' in questo contesto e' probabilmente la definizione di una adeguata soluzione di gestione delle chiavi. Molta attenzione si dovra' prestare ai lavori recenti su questi argomenti. Un altro punto importante che sara' considerato in WP4 e' l'introduzione di servizi di "trust management" in questo contesto, che offrirebbe l'opportunita' di costruire diversi servizi distribuiti innovativi.

WP6: Integrazione della crittografia dei dati con i sistemi relazionali attuali

L'obiettivo di WP6 e' l'identificazione di tecniche capaci di supportare la realizzazione di uno scenario denominato "database-as-a-service". Partiremo dall'attuale stato della tecnologia dei database, al fine di identificare i problemi chiave che devono essere affrontati per permettere una realizzazione completa del potenziale di questa architettura. Vi sono diverse problematiche che devono essere risolte per dispiegare in un ambiente reale questa architettura. Il lavoro in questo workpackage sara' organizzato in 4 task; il task 2 e' decomposto in due sub-task.

Task 1: Strutture di indicizzazione

Benche' i sistemi informatici incrementino continuamente le prestazioni con costi che continuano a ridursi, un livello di prestazioni adeguato rimane sempre un fattore critico nella costruzione di una soluzione centrata su DBMS. Un'architettura che si appoggia sul paradigma "database-as-a-service" non e' competitiva se offre i suoi servizi sicuri al costo di una riduzione significativa delle prestazioni. infatti, molte soluzioni di sicurezza non sono effettivamente sviluppate a causa della impossibilita' di offrire un livello di efficienza adeguato a quanto gli utenti si aspettano. La crittografia necessariamente impone un incremento delle elaborazioni svolte dal sistema; e' importante progettare un sistema il cui impatto sulle prestazioni noa sia considerevolmente superiore a quello motivato dalla presenza del servizio di crittografia.

L'accesso ai dati contenuti nei database relazionali avviene con un approccio set-oriented. Partendo da una specifica dichiarativa della richiesta dell'utente (tipicamente, una query SQL), l'ottimizzatore traduce la query in una rappresentazione algebrica interna, che fa uso degli operatori supportati dal motore relazionale. Le prestazioni della query normalmente dipendono dalla presenza di indici adeguati, i quali sono contenuti nel database.

La strategia che intendiamo seguire per soddisfare questo requisito consiste nel progettare strutture di indicizzazione innovative. Queste strutture di indicizzazione devono avere come punto di partenza le soluzioni che sono attualmente supportate dai motori relazionali (alberi nelle loro molteplici varianti, strutture hash, indici bitmap, indici spaziali), adattandole alle specifiche caratteristiche di questo ambiente. Il workpackage WP3, di responsabilita` UNIMI, si occupera` di verificare il livello di protezione della confidenzialita` offerto da queste strutture, mentre in questo WP se ne valuteranno le prestazioni.

Task 2: Integrazione con l'ottimizzatore di query

Un altro aspetto da considerare e' l'identificazione di una strategia che permetta l'integrazione delle strutture di indicizzazione sopracitate con gli ottimizzatori delle query dei DBMS esistenti. Ci sono due principali problematiche che devono essere risolte per realizzare l'integrazione:
<br />- Task 2.1, Modello di costo: deve essere costruito un modello di costo per gli operatori che implementano l'accesso remoto;

- Task 2.2, Trattabilita` computazionale della ottimizzazione: deve essere identificato un approccio che limiti l'incremento dello spazio delle soluzioni che potrebbe derivare dall'inroduzione di un servizio di accesso remoto.

Task 2.1: Modello di costo

La costruzione di un nuovo modello per la rappresentazione del costo degli operatori per l'accesso remoto e' necessaria per supportare l'integrazione della memorizzazione di dati crittografati all'interno di un database remoto. Una importante differenza tra il modello di costo di questo contesto e quelli che caratterizzano i DBMS odierni e' il fatto che i modelli di costo dei DBMS sono tradizionalmente focalizzati sull'identificazione del numero e sull'organizzazione (casuale o sequenziale) degli accessi al disco, cioe' il parametro che ha l'impatto piu` significativo sulle prestazioni del motore relazionale. Al contrario, nella maggior parte dei contesti in cui questo paradigma verra' usato, possiamo assumere che il principale collo di bottiglia del sistema sia la larghezza di banda della rete disponibile per trasferire i dati tra il server e il client. Quindi, il principale parametro da controllare e' la quantita' di dati che devono essere trasferiti al client in risposta alla richiesta di accesso; un altro parametro con un importante impatto sulle prestazioni e' la latenza dell'accesso al database remoto, cioe' il ritardo atteso per ricevere il primo risultato.

La definizione di un tale modello di costo richiedera' di progettare un modello astratto che rappresenti il comportamento dei differenti componenti dell'architettura. Le euristiche che sono attualmente usate per risolvere il problema di ottimizzare le query relazionali dovrebbero essere adattate a questo contesto. Infine, si devono effettuare esperimenti per verificare in modo concreto la qualita' fornita dal nuovo modello di costo.

Task 2.2: Trattabilita` dell'ottimizzazione

L'obiettivo di questo task e' l'identificazione di una strategia che riduca la complessita' del problema di ottimizzazione delle query. E' utile considerare le similarita' e le differenze di questo contesto rispetto a uno scenario di database distribuito. Similmente a un database distribuito, in questo scenario vi sono motori relazionali in rete che devono cooperare nella elaborazione delle query. Precedenti ricerche sull'ottimizzazione di query distribuite hanno dimostrato che il problema e' estremamente difficile, dato che lo spazio delle soluzioni e' considerevolmente piu' grande di quanto avvenga nella situazione centralizzata e l'applicazione delle strategie standard di ottimizzazione delle query in questo contesto e' troppo costosa. Fortunatamente, sembra che in questo scenario sia possibile considerare come significativa solo l'ottimizzazione delle query sul client (il costo delle query sul server puo' essere considerato un problema di secondo livello riguardante il fornitore del servizio); inoltre, la minimizzazione dei costi di rete dovrebbe minimizzare la dimensione dell'informazione che il server untrusted deve fornire, minimizzando anche i suoi costi. Queste considerazioni rendono ottimisti sulla possibiilita' di definire un framework capace di offrire prestazioni adeguate nella fase di ottimizzazione. Anche questa attivita` ha la necessita` di trovare un riscontro sperimentale.

Task 3: Modularizzabilita`

Un altro aspetto importante che la ricerca nel WP6 deve considerare e' il progetto di una infrastruttura che consenta la facile integrazione di questo approccio all'interno dei DBMS esistenti.Gli attuali DBMS sono spesso software di grandi dimensioni, che implementano molti servizi sofisticati con un adeguato livello di prestazioni. L'uso di un untrusted server remoto e' ragionevole solo se questo continua a offrire la maggior parte dei servizi di un DBMS attuale, altrimenti non sarebbe in grado di supportare i requisiti della maggior parte delle applicazioni.

La reimplementazione da zero di tutti i servizi di un DBMS all'interno di un sistema che supporta server untrusted remoti non e' proponibile, in quanto richiederebbe uno sforzo enorme. Una strategia che intendiamo investigare e' quella che si pone l'obiettivo di modularizzare i componenti che implementano l'accesso agli untrusted server remoti, per consentire una integrazione quasi trasparente dei nuovi servizi all'interno di un DBMS esistente.

Idealmente, l'architettura software di un DBMS dovrebbe consentire l'identificazione di alcuni moduli da adattare per introdurre questo nuovo servizio. Intendiamo svolgere questa analisi usando come riferimento dei DBMS che sono caratterizzati da un progetto aperto. Dato che il servizio di un untrusted server remoto puo' essere considerato come la semplice memorizzazione di tabelle, nello specifico investigheremo l'integrazione di questo servizio in termini di introduzione di nuovi operatori di accesso fisico ai dati. In questo modo, questo servizio verrebbe introdotto come un'opzione di progetto fisico, mirando a incrementare la robustezza nella memorizzazione. Sembra quindi che, al costo di una perdita di efficienza che richiede di essere quantificata, vi sia la possibilita' di introdurre un layer astratto che separi il servizio di accesso dal database untrusted e renda possibile integrarlo all'interno dei DBMS esistenti.

Task 4: Nuova metodologia di progetto fisico

Il modello prodotto nel task precedente, che presenta l'uso di server untrusted remoti come un'opzione di progetto fisico, fornisce l'opportunita' per la definizione di una metodologia di progetto fisico aggiornata. Una efficace focalizzazione di questo approccio, all'interno della fase di progetto fisico del processo di progettazione del database, presenterebbe il grande vantaggio di una riduzione dell'impatto suile attuali metodologie di progetto dei database; permettendo una relativamente facile introduzione di questo paradigma all'interno delle applicazioni esistenti.

WP7: Implementazione del prototipo

L'obiettivo del workpackage WP7 e' l'implementazione di un prototipo che sara' usato come testbed per la valutazione della fattibilita' e applicabilita' delle soluzioni prodotte negli altri workpackage. Procederemo in due fasi.

La prima fase sara' focalizzata sulla costruzione di un'architettura che costruira' da zero un semplice motore relazionale, al fine di dimostrare il comportamento del sistema. Questo prototipo estendera' il motore relazionale che e' stato descritto in [DDFPSJ-03].

La seconda fase invece mirera' a dimostrare come l'approccio puo' essere integrato all'interno di un DBMS esistente. Questo lavoro estendera' un motore di database relazionale esistente open source. La nostra unita' di ricerca ha gia` avuto esperienza nell'estensione di motori di DBMS open source. Nello specifico, recentemente e` stato analizzato il supporto di trigger in PostgreSQL e si e` prodotta una variante che ha incrementato il livello di supporto che PostgreSQL offre per le priorita' dei trigger e per la loro elaborazione set-oriented. Un'altra iniziativa ha invece operato sulla parte di PostegreSQL che gestisce l'autenticazione tramite certificati. Questo prototipo integrera' anche le funzioni crittografiche realizzate dal'unita' UNISA nell'ambito di WP3.

L'idea di lavorare sia su un prototipo di ricerca, sia sulla estensione di un motore esistente di DBMS, e' ispirata dall'esperienza nello scenario delle basi di dati attive, dove, all'inizio degli anni 90, diversi prototipi di ricerca furono costruiti da parte dei membri di UNIBG (ai tempi al Politecnico di Milano) per dimostrare le caratteristiche avanzate che i trigger potevano realizzare; allo stesso tempo, lo stesso gruppo di ricercatori analizzo' l'introduzione di trigger innovativi all'interno dei DBMS commerciali esistenti. Questo WP portera` al rilascio di diversi deliverable software.

WP8: Divulgazione dei risultati

L'organizzazione di un workshop alla fine del progetto reppresenta un modo interessante per promuovere i risultati della ricerca.

Oltre al workshop, i membri di tutte le unita' di progetto hanno una significativa esperienza di ricerca a saranno capaci di promuovere i risultati del progetto con pubblicazioni nelle maggiori conferenze e riviste. Questa attivita' di divulgazione dei risultati, cruciale per il successo del progetto, verra' svolta durante tutte le fasi e produrra' un significativo numero di pubblicazioni. I feedback continui che la comunita' scientifica dara' dopo una sottomissione a una rivista o a una conferenza saranno di grande aiuto nell'identificare la strada da seguire e aiuteranno nella verifica del potenziale del progetto. Incontri frequenti e le attivita' di coordinamento tra le unita' di ricerca consentiranno al coordinatore nazionale di monitorare i progessi rispetto agli obiettivi fissati.