Uso della crittografia con i database SQL

La crittografia è utile ogni volta che desiderate limitare l'accesso alle informazioni archiviate in un database. La funzionalità di crittografia del database inclusa in Adobe AIR può essere usata per vari scopi. Di seguito sono riportati alcuni esempi di casi in cui è opportuno usare un database crittografato:

• Cache di sola lettura di dati privati di un'applicazione scaricati da un server

• Archivio dell'applicazione locale per dati privati che vengono sincronizzati con un server (i dati vengono inviati e caricati sul server)

• File crittografati usati come formato di file per i documenti creati e modificati dall'applicazione. I file possono essere riservati a un solo utente o progettati per la condivisione tra tutti gli utenti dell'applicazione.

• Qualsiasi altro uso di un archivio dati locale, come quelli descritti in Vari usi dei database SQL locali , in cui i dati devono essere mantenuti privati e salvaguardati dagli utenti che hanno accesso al computer o ai file di database.

L'individuazione del motivo per cui è opportuno utilizzare un database crittografato vi permetterà di decidere più facilmente come progettare l'architettura di un'applicazione. In particolare, può incidere sul modo in cui l'applicazione crea, ottiene o archivia la chiave di crittografia per il database. Per ulteriori informazioni su tali considerazioni, vedete Considerazioni sull'uso della crittografia con un database .

Oltre a un database crittografato, un meccanismo alternativo per mantenere privati i dati riservati consiste nell'usare un archivio locale crittografato . In un archivio locale crittografato, potete archiviare un singolo valore ByteArray usando una chiave in formato stringa. Solo l'applicazione AIR che memorizza il valore può accedervi e solo nel computer in cui il valore è memorizzato. Con l'archivio locale crittografato non è necessario creare una chiave di crittografia personalizzata. Per questi motivi, un archivio locale crittografato è più adatto per archiviare in modo semplice un singolo valore o un set di valori che possono essere facilmente codificati in un ByteArray. Un database crittografato è invece più adatto per set di dati estesi in cui è preferibile disporre di funzioni strutturate per l'esecuzione di query e la memorizzazione dei dati. Per ulteriori informazioni sull'uso di un archivio locale crittografato, vedete Archiviazione locale crittografata .

Per utilizzare un database crittografato, è necessario crittografare il file di database al momento della creazione. Dopo avere creato un database non crittografato, non è possibile crittografarlo in seguito. In modo analogo, un database crittografato non può essere decrittografato in seguito. Se necessario, potete modificare la chiave di crittografia di un database crittografato. Per ulteriori dettagli, consultate Modifica della chiave di crittografia di un database . Se è presente un database non crittografato e desiderate usare la crittografia in quel database, potete creare un nuovo database crittografato e copiare i dati e la struttura delle tabelle esistenti nel nuovo database.

La creazione di un database crittografato è pressoché identica a quella di un database non crittografato, come descritto in Creazione di un database . Create innanzitutto un'istanza SQLConnection che rappresenta la connessione al database. Create il database chiamando il metodo open() o openAsync() dell'oggetto SQLConnection, specificando come posizione del database un file ancora inesistente. La sola differenza quando create un database crittografato consiste nel fornire un valore per il parametro encryptionKey (il quinto parametro del metodo open() e il sesto parametro del metodo openAsync() ).

Un valore valido per il parametro encryptionKey è un oggetto ByteArray contenente esattamente 16 byte.

Gli esempi seguenti mostrano la creazione di un database crittografato. Per semplicità, in questo esempio la chiave di crittografia è codificato nel codice dell'applicazione. Questa tecnica è tuttavia sconsigliata, non essendo sicura.

var conn:SQLConnection = new SQLConnection(); 
     
var encryptionKey:ByteArray = new ByteArray(); 
encryptionKey.writeUTFBytes("Some16ByteString"); // This technique is not secure! 
     
// Create an encrypted database in asynchronous mode 
conn.openAsync(dbFile, SQLMode.CREATE, null, false, 1024, encryptionKey); 
     
// Create an encrypted database in synchronous mode 
conn.open(dbFile, SQLMode.CREATE, false, 1024, encryptionKey);

Per un esempio che illustra un metodo consigliato per generare una chiave di crittografia, consultate Esempio: generazione e uso di una chiave di crittografia. .

Come per la creazione di un database crittografato, la procedura per aprire una connessione a un database crittografato è simile a quella per un database non crittografato. Tale procedura è descritta più dettagliatamente in Connessione a un database . Utilizzate il metodo open() per aprire una connessione in modalità di esecuzione sincrona oppure il metodo openAsync() per aprire una connessione in modalità di esecuzione asincrona . La sola differenza è data dal fatto che quando aprite un database crittografato dovete specificare il valore corretto per il parametro encryptionKey (il quinto parametro del metodo open() e il sesto parametro del metodo openAsync() ).

Se la chiave di crittografia specificata non è corretta, si verifica un errore. Per il metodo open() , viene generata un'eccezione SQLError . Per il metodo openAsync() , l'oggetto SQLConnection invia un evento SQLErrorEvent , la cui proprietà error contiene un oggetto SQLError . In entrambi i casi, l'oggetto SQLError generato dall'eccezione presenta il valore 3138 della proprietà errorID . Questo ID errore corrisponde al messaggio di errore “File opened is not a database file” (Il file aperto non è un file di database).

Nell'esempio riportato di seguito viene illustrata l'apertura di un database crittografato in modalità di esecuzione asincrona. Per semplicità, in questo esempio la chiave di crittografia è hardcoded nel codice dell'applicazione. Questa tecnica è tuttavia sconsigliata, non essendo sicura.

import flash.data.SQLConnection; 
import flash.data.SQLMode; 
import flash.events.SQLErrorEvent; 
import flash.events.SQLEvent; 
import flash.filesystem.File; 
     
var conn:SQLConnection = new SQLConnection(); 
conn.addEventListener(SQLEvent.OPEN, openHandler); 
conn.addEventListener(SQLErrorEvent.ERROR, errorHandler); 
var dbFile:File = File.applicationStorageDirectory.resolvePath("DBSample.db"); 
     
var encryptionKey:ByteArray = new ByteArray(); 
encryptionKey.writeUTFBytes("Some16ByteString"); // This technique is not secure! 
     
conn.openAsync(dbFile, SQLMode.UPDATE, null, false, 1024, encryptionKey); 
     
function openHandler(event:SQLEvent):void 
{ 
    trace("the database opened successfully"); 
} 
     
function errorHandler(event:SQLErrorEvent):void 
{ 
    if (event.error.errorID == 3138) 
    { 
        trace("Incorrect encryption key"); 
    } 
    else 
    { 
        trace("Error message:", event.error.message); 
        trace("Details:", event.error.details); 
    } 
} 

Nell'esempio riportato di seguito viene illustrata l'apertura di un database crittografato in modalità di esecuzione sincrona. Per semplicità, in questo esempio la chiave di crittografia è hardcoded nel codice dell'applicazione. Questa tecnica è tuttavia sconsigliata, non essendo sicura.

import flash.data.SQLConnection; 
import flash.data.SQLMode; 
import flash.filesystem.File; 
     
var conn:SQLConnection = new SQLConnection(); 
var dbFile:File = File.applicationStorageDirectory.resolvePath("DBSample.db"); 
     
var encryptionKey:ByteArray = new ByteArray(); 
encryptionKey.writeUTFBytes("Some16ByteString"); // This technique is not secure! 
     
try 
{ 
    conn.open(dbFile, SQLMode.UPDATE, false, 1024, encryptionKey); 
    trace("the database was created successfully"); 
} 
catch (error:SQLError) 
{ 
    if (error.errorID == 3138) 
    { 
        trace("Incorrect encryption key"); 
    } 
    else 
    { 
        trace("Error message:", error.message); 
        trace("Details:", error.details); 
    } 
} 

Per un esempio che illustra un metodo consigliato per generare una chiave di crittografia, consultate Esempio: generazione e uso di una chiave di crittografia. .

Quando un database è crittografato, potete modificare la relativa chiave di crittografia in un secondo tempo. Per modificare la chiave di crittografia di un database, aprite innanzitutto la connessione al database creando un'istanza SQLConnection e chiamando il relativo metodo open() o openAsync() . Una volta aperta la connessione al database, chiamate il metodo reencrypt() passando la nuova chiave di crittografia come argomento.

Come per tutte le operazioni relative al database, il comportamento del metodo reencrypt() varia a seconda che la connessione al database utilizzi la modalità di esecuzione sincrona o asincrona. Se usate il metodo open() per connettervi al database, l'operazione reencrypt() viene eseguita in modo sincrono. Al termine dell'operazione, l'esecuzione prosegue con la riga successiva del codice:

var newKey:ByteArray = new ByteArray(); 
// ... generate the new key and store it in newKey 
conn.reencrypt(newKey);

D'altra parte, se la connessione al database viene aperta tramite il metodo openAsync() , l'operazione reencrypt() viene eseguita in modo asincrono. Se chiamate il metodo reencrypt() , viene iniziato di nuovo il processo di crittografia. Al termine dell'operazione, l'oggetto SQLConnection invia un evento reencrypt . Per determinare quando termina il processo, potete usare un listener di eventi:

var newKey:ByteArray = new ByteArray(); 
// ... generate the new key and store it in newKey 
     
conn.addEventListener(SQLEvent.REENCRYPT, reencryptHandler); 
     
conn.reencrypt(newKey); 
     
function reencryptHandler(event:SQLEvent):void 
{ 
    // save the fact that the key changed 
}

L'operazione reencrypt() viene eseguita in una transazione specifica. Se l'operazione viene interrotta o non riesce (ad esempio, se l'applicazione viene chiusa prima che termini l'operazione) la transazione viene annullata. In tal caso, la chiave di crittografia originale sarà ancora quella valida per il database.

Non potete usare il metodo reencrypt() per rimuovere la crittografia da un database. Se passate un valore null o una chiave di crittografia che non è un ByteArray di 16 byte, il metodo reencrypt() restituisce un errore.

Nella sezione Vari usi di un database crittografato vengono illustrati diversi casi in cui è opportuno usare un database crittografato. È evidente che gli scenari di impiego delle diverse applicazioni (inclusi questi e altri) presentano requisiti diversi per quanto riguarda la riservatezza. Il modo in cui progettate l'uso della crittografia nella vostra applicazione svolge un ruolo importante nel controllo del grado di riservatezza dei dati di un database. Se, ad esempio, utilizzate un database crittografato per proteggere i dati personali, anche dagli utenti dello stesso computer, dovete creare una chiave di crittografia per il database di ciascun utente. Per maggiore sicurezza, l'applicazione può generare la chiave dalla password immessa da un utente. La chiave di crittografia basata su una password assicura che qualora un'altra persona fosse in grado di rappresentare l'account di un utente del computer, non potrà comunque accedere ai dati. Da un altro punto di vista della riservatezza, supponete di voler rendere un database leggibile da parte di qualsiasi utente della vostra applicazione, ma non da altre applicazioni. In tal caso, ogni copia installata dell'applicazione deve poter accedere a una chiave di crittografia condivisa.

Potete progettare la vostra applicazione, e in particolare la tecnica utilizzata per generare la chiave di crittografia, in base al livello di riservatezza che desiderate per i dati dell'applicazione. Di seguito sono riportati alcuni suggerimenti per la progettazione dei vari livelli di riservatezza dei dati:

• Per rendere il database accessibile a tutti gli utenti che accedono all'applicazione su qualsiasi computer, usate un'unica chiave che sia disponibile per tutte le istanze dell'applicazione. La prima volta che l'applicazione viene eseguita, può ad esempio scaricare la chiave di crittografia condivisa da un server usando un protocollo sicuro, come SSL. La chiave può quindi essere salvata nell'archivio locale crittografato per l'uso futuro. In alternativa, crittografate i dati per ogni utente sul computer e sincronizzateli con un archivio dati remoto, ad esempio un server, in modo da consentire la portabilità dei dati.

• Per rendere un database accessibile a un singolo utente su qualsiasi computer, generate la chiave di crittografia da un dato segreto dell'utente (ad esempio una password). In particolare, per generare la chiave non usate un valore qualsiasi collegato a un computer specifico (ad esempio un calore memorizzato nell'archivio locale crittografato. In alternativa, crittografate i dati per ogni utente sul computer e sincronizzateli con un archivio dati remoto, ad esempio un server, in modo da consentire la portabilità dei dati.

• Per rendere un database accessibile solo a un utente su un solo computer, generate la chiave di crittografia da una password e da un valore salt generato. Per un esempio di questa tecnica, consultate Esempio: generazione e uso di una chiave di crittografia. .

Di seguito sono riportate alcune importanti considerazioni aggiuntive da tenere presenti durante la progettazione di un'applicazione che utilizza un database crittografato:

• La sicurezza di un sistema è direttamente proporzionale alla sicurezza suo collegamento più debole. Se usate una password immessa dall'utente per generare una chiave di crittografia, considerate la possibilità di imporre una lunghezza minima e delle restrizioni relative alla complessità delle password. Una password breve che utilizza solo caratteri di base può essere individuata velocemente.

• Il codice sorgente di un'applicazione AIR viene archiviato sul computer di un utente in formato testo semplice (per il contenuto HTML) o in un formato binario facilmente decompilabile (per il contenuto SWF). Poiché il codice è accessibile, occorre considerare due punti:

  • Non usate mai una chiave hardcoded nel codice sorgente

  • Partite sempre dal presupposto che la tecnica usata per generare una chiave di crittografia (ad esempio un generatore di caratteri casuali o un particolare algoritmo di hash) può essere facilmente individuata da un utente malintenzionato

• Nella crittografia dei database AIR viene utilizzato AES (Advanced Encryption Standard) in modalità Counter con CCM (CBC-MAC). Questa modalità di crittografia richiede la combinazione di una chiave immessa dall'utente con un valore salt per essere sicura. Per un esempio di questa modalità, consultate Esempio: generazione e uso di una chiave di crittografia. .

• Quando decidete di crittografare un database, tutti i file su disco utilizzati dal motore di database assieme al database vengono crittografati. Il motore di database, tuttavia, mantiene alcuni dati temporaneamente in una cache in memoria per migliorare le prestazioni dei tempi di lettura e scrittura delle transazioni. Tutti i dati residenti in memoria non sono crittografati. Se un utente malintenzionato riesce ad accedere alla memoria utilizzata da un'applicazione AIR, ad esempio tramite un debugger, i dati in un database attualmente aperto e non crittografato diventano disponibili.

Questa applicazione di esempio dimostra una tecnica per la generazione di una chiave di crittografia. Questa applicazione è progettata per fornire il massimo livello di riservatezza e sicurezza per i dati dell'utente. Un aspetto importante relativo alla protezione dei dati privati è rappresentato dalla necessità di chiedere all'utente di immettere una password a ogni connessione dell'applicazione al database. Di conseguenza, come illustrato nell'esempio, un'applicazione che richiede questo livello di privacy non deve mai memorizzare direttamente la chiave di crittografia del database.

L'applicazione è composta da due parti: una classe ActionScript che genera una chiave di crittografia (la classe EncryptionKeyGenerator) e un'interfaccia utente di base che dimostra come utilizzare la classe. Per il codice sorgente completo, consultate Esempio di codice completo per la generazione e l'uso di una chiave di crittografia .