Scenario 2: Valutazione dell’Elapsed Time e CPU Time

dovuto all’esecuzione di operazioni crittografiche (minori in numero rispetto alla cifratura per tutta la tabella).

Le TabelleD.21 D.17 D.25eD.29(AppendiceD) mostrano lo stato del sistema prima, durante e dopo l’esecuzione dei test.

Figura 5.11: SQL Interface - Confronto dell’Elapsed Time e CPU Time (INSERT) sulle tabelle da 10k tuple.

Figura 5.12: SQL Interface - Confronto dell’Elapsed Time e CPU Time (INSERT) sulle tabelle da 100k tuple.

SELECT

Le Figure5.13e5.14mostrano l’Elapsed Time e CPU Time riguardo l’operazione di SELECT.

La Tabella5.9mostra l’incremento percentuale dell’Elapsed Time e CPU Time per ogni soluzione analizzata. Anche in questo caso PostgreSQL è altamente inefficiente mentre l’impatto sulle performance per quanto riguarda Microsoft è minimo rispetto alle altre soluzioni. Riguardo Oracle l’impatto è significativo e 3DES è tendenzialmente più lento rispetto ad AES. Anche in questo caso Blowfish ha performance migliori rispetto ad AES.

Da questi risultati sperimentali si evince che l’utilizzo delle funzioni crittografiche, utilizzate per decifrare i dati, messe a disposizioni dalle librerie SQL Interface siano altamente inefficienti rispetto alle funzioni di cifratura (utilizzate nella INSERT) e alla TDE.

Le TabelleD.22 D.18 D.26eD.30(AppendiceD) mostrano lo stato del sistema prima, durante e dopo l’esecuzione dei test.

PostgreSQL MySQL Microsoft Oracle

AES Elapsed Time +3187% +384% +8% +650%

CPU Time +11970% +4076% +412% +1195%

COLUMN Elapsed Time +262% +190% +3% +292%

CPU Time +4487% +1829% +100% +492%

3DES Elapsed Time - - - +962%

CPU Time - - - +1415%

Blowfish Elapsed Time +2666% - -

-CPU Time +11037% - -

-Tabella 5.9

Figura 5.13: SQL Interface - Confronto dell’Elapsed Time e CPU Time (SELECT) sulle tabelle da 10k tuple.

Figura 5.14: SQL Interface - Confronto dell’Elapsed Time e CPU Time (SELECT) sulle tabelle da 100k tuple.

UPDATE

Le Figure5.15e5.16mostrano l’Elapsed Time e il CPU Time riguardo l’operazione di UPDATE.

La Tabella5.10mostra l’incremento percentuale dell’Elapsed Time e CPU Time per ogni soluzione analizzata. Anche in questo caso Blowfish appare più inefficiente rispetto ad AES. L’impatto sulle performance di Oracle è notevole con 3DES che aumenta le latenze rispetto ad AES. MySQL ha le migliori performance in questo caso. Microsoft e PostgreSQL hanno delle perdite contenute.

Rispetto alla INSERT, in questo caso si cifra una singola colonna e la si aggiorna sul database per questa ragione le operazioni crittografiche sono minori. Ciò comporta un aumento dell’overhead computazionale ma comunque minore rispetto alla INSERT.

Le TabelleD.23 D.19 D.27eD.31(AppendiceD) mostrano lo stato del sistema prima, durante e dopo l’esecuzione dei test.

PostgreSQL MySQL Microsoft Oracle

AES Elapsed Time +62% +9% +58% +196%

CPU Time +134% +48% +135% +942%

COLUMN Elapsed Time +21% +2% +5% +79%

CPU Time +34% +21% +43% +662%

3DES Elapsed Time - - - +273%

CPU Time - - - +1060%

Blowfish Elapsed Time +37% - -

-CPU Time +109% - -

-Tabella 5.10

Figura 5.15: SQL Interface - Confronto dell’Elapsed Time e CPU Time (UPDATE) sulle tabelle da 10k tuple.

Figura 5.16: SQL Interface - Confronto dell’Elapsed Time e CPU Time (UPDATE) sulle tabelle da 100k tuple.

DELETE

Le Figure5.17e5.18mostrano l’Elapsed Time e il CPU Time riguardo l’operazione di DELETE.

La Tabella5.11mostra l’incremento percentuale dell’Elapsed Time e CPU Time per ogni soluzione analizzata. Come si può notare dai grafici l’andamento del CPU Time non segue un criterio e l’incremento percentuale è circa nullo e costante. Ciò è dovuto al fatto che in questa operazioni non si effettuano operazioni crittografiche che non apportano overhead computazionale.

PostgreSQL MySQL Microsoft Oracle

AES Elapsed Time +74% +122% +113% -3%

CPU Time -1% 0% +1% +2%

COLUMN Elapsed Time -33% +10% +77% -41%

CPU Time +4% 0% +7% -28%

3DES Elapsed Time - - - -9%

CPU Time - - - -12%

Blowfish Elapsed Time +28% - -

-CPU Time +1% - -

-Tabella 5.11

Figura 5.17: SQL-Interface - Confronto dell’Elapsed Time e CPU Time (DELETE) sulle tabelle da 10k tuple.

Figura 5.18: SQL Interface - Confronto dell’Elapsed Time e CPU Time (DELETE) sulle tabelle da 100k tuple.

Sviluppo soluzione Client-side

In questo capitolo si mostrerà l’architettura e la Key Management adottata durante lo sviluppo del driver software per l’abilitazione della client-side encryption. Il repository che contiene il codice sorgente si trova al seguente URL https://github.com/LorenzoCeccarelli/Tesi. È stata utilizzata la versione 11 di Java, tutte le classi utilizzate si riferiscono a questa versione.

L’appendice A contiene il Manuale Utente. Questo fornisce tutte le informazioni necessarie per installare e utilizzare il software sviluppato.

L’appendiceBcontiene il Manuale Programmatore. Questo, invece, fornisce la documentazione del codice e delle classi sviluppate. Inoltre sono descritte anche tutte le dipendenze necessarie per far funzionare il driver.

6.1 Architettura

La Figura6.1mostra lo scenario di utilizzo del software sviluppato per l’abilitazione della client-side encryption.

CORE

CRYPTOGRAPHY MANAGER

DATABASE MANAGER CLIENTSIDE ENCYPTION

PACKAGE

CRYPTODATABASE ADAPTER

DIRECT USAGE TRANSPARENT USAGE

CLIENT APPLICATION CLIENT

EXTERNAL

DATABASE KEYSTORE

MANAGER

CLIENT FILESYSTEM

KEYSTORE

Figura 6.1: Scenario

Il software sviluppato, contenuto nel package ClientsideEncryption, si comporta come un driver (o adattatore) che si interfaccia con il database. Un’applicazione client può utilizzare le classi fornite dal package in due possibili modalità:

• Trasparente: consiste nell’utilizzare la classe CryptoDatabaseAdapter che permette di richiamare i metodi forniti dal package Core in modo trasparente all’applicazione client;

• Diretto: consiste nell’utilizzare direttamente le classi fornite dal package Core che rappre-sentano il nucleo di funzionamento del driver. In questo modo il programmatore ha maggiore flessibilità aumentando però la complessità del codice.

È stata fatta una semplificazione nell’architettura ovvero è stato assunto che l’applicazione client comunicasse direttamente con il DBMS senza terze parti nel mezzo (ad esempio un web server).

Il package Core è composto da:

• CryptographyManager: fornisce dei metodi per la gestione delle operazioni crittografiche;

• KeystoreManager: fornisce dei metodi per la gestione del keystore;

• DatabaseManager: fornisce dei metodi per gestire la connessione con il database e l’esecu-zione delle query.

Riguardo al keystore, viene utilizzato un file PKCS12. Come discusso nel Capitolo 3, ciò rappresenta una buona soluzione in fase di sviluppo ma non fase di produzione in quanto il file .p12 non è l’alternativa più sicura a differenza dell’utilizzo di un HSM, che invece rappresenta la soluzione più efficace in termini di sicurezza. Dato che viene usata la classe Keystore del package java.security [87], la migrazione verso altre soluzioni (ad esempio HSM) in fase di produzione richiede un basso sforzo in quanto questa classe astrae rispetto alla tipologia di keystore utilizzato.