Verwenden von Verschlüsselung mit SQL-Datenbanken

Die Verschlüsselung ist immer dann sinnvoll, wenn Sie den Zugriff auf Informationen, die in einer Datenbank gespeichert sind, beschränken möchten. Die Datenbankverschlüsselung von Adobe AIR lässt sich für verschiedene Zwecke einsetzen. Einige Beispiele für Situationen, die sich für verschlüsselte Datenbanken anbieten, sind folgende:

• Ein schreibgeschützter Cachespeicher von privaten Anwendungsdaten, die von einem Server heruntergeladen werden.

• Ein lokaler Anwendungsspeicher für private Daten, die mit einem Server synchronisiert werden (Daten werden an einen Server gesendet und vom Server heruntergeladen).

• Verschlüsselte Dateien, die als Dateiformat für Dokumente verwendet werden, die in der Anwendung erstellt und bearbeitet werden. Die Dateien könnten für einen bestimmten Benutzer gedacht sein oder von allen Benutzern der Anwendung gemeinsam genutzt werden.

• Jede beliebige andere Verwendung eines lokalen Datenspeichers, wie zum Beispiel unter Verwendungszwecke lokaler Datenbanken beschrieben, bei der die Daten vor Personen, die Zugriff auf den Computer oder die Datenbankdateien haben, geschützt werden sollen.

Wenn Ihnen klar ist, warum Sie eine verschlüsselte Datenbank verwenden möchten, können Sie leichter entscheiden, wie Sie Ihre Anwendung aufbauen. Insbesondere hat dies Auswirkungen darauf, wie Ihre Anwendung den Verschlüsselungsschlüssel für die Datenbank erstellt, erhält und speichert. Weitere Informationen zu diesen Aspekten finden Sie unter Überlegungen zur Verschlüsselung von Datenbanken .

Eine Alternativmethode zum Schutz vertraulicher Daten ist die Verwendung eines verschlüsselten lokalen Speichers . Dabei wird ein einzelner ByteArray -Wert mit einem Stringschlüssel gespeichert. Nur die AIR-Anwendung, die den Wert gespeichert hat, kann darauf zugreifen, und auch dies nur auf dem Computer, auf dem der Wert gespeichert wurde. Wenn Sie den verschlüsselten lokalen Speicher verwenden, brauchen Sie keinen eigenen Verschlüsselungsschlüssel zu erstellen. Aus diesem Grund eignet sich der verschlüsselte lokale Speicher am besten zum einfachen Speichern eines einzelnen Werts oder einer Gruppe von Werten, die sich unkompliziert in einem ByteArray kodieren lassen. Eine verschlüsselte Datenbank eignet sich am besten für größere Datenmengen, für die eine strukturierte Datenspeicherung und Abfragefunktionen erwünscht sind. Weitere Informationen zur Verwendung des verschlüsselten lokalen Datenspeichers finden Sie unter Verschlüsselter lokaler Speicher .

Die Datenbankdatei muss beim Erstellen verschlüsselt werden, wenn eine verschlüsselte Datenbank verwendet werden soll. Wenn eine Datenbank unverschlüsselt erstellt wird, kann sie später nicht verschlüsselt werden. Dies gilt auch im umgekehrten Fall; eine verschlüsselte Datenbank kann später nicht zu einer unverschlüsselten gemacht werden. Bei Bedarf können Sie den Verschlüsselungsschlüssel einer verschlüsselten Datenbank ändern. Ausführliche Informationen finden Sie unter Ändern des Verschlüsselungsschlüssels einer Datenbank . Wenn Sie eine vorhandene nicht verschlüsselte Datenbank mit Datenbankverschlüsselung nutzen möchten, erstellen Sie eine neue verschlüsselte Datenbank und kopieren Sie die vorhandene Tabellenstruktur und die Daten in die neue Datenbank.

Das Erstellen einer verschlüsselten Datenbank ist fast identisch mit dem Erstellen einer unverschlüsselten Datenbank wie unter Erstellen von Datenbanken beschrieben. Sie erstellen zunächst eine SQLConnection -Instanz, die die Verbindung zur Datenbank darstellt. Sie erstellen die Datenbank durch einen Aufruf der open() - oder openAsync() -Methode des SQLConnection-Objekts. Geben Sie dabei für den Speicherort der Datenbank eine noch nicht vorhandene Datei an. Der einzige Unterschied beim Erstellen einer verschlüsselten Datenbank besteht darin, dass Sie einen Wert für den encryptionKey -Parameter angeben (dies ist der fünfte Parameter der open() -Methode und der sechste Parameter der openAsync() -Methode).

Ein gültiger Wert für den encryptionKey -Parameter ist ein ByteArray -Objekt, das genau 16 Byte enthält.

Die folgenden Beispiele veranschaulichen die Erstellung einer verschlüsselten Datenbank. Der Einfachheit halber ist der Verschlüsselungsschlüssel in diesen Beispielen im Anwendungscode fest vorgegeben. Von dieser Methode wird jedoch dringend abgeraten, da sie nicht sicher ist.

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);

Ein Beispiel für das empfohlene Verfahren zum Generieren eines Verschlüsselungsschlüssels finden Sie unter Beispiel: Generieren und Verwenden von Verschlüsselungsschlüsseln .

Wie beim Erstellen von Datenbanken gibt es auch beim Herstellen einer Verbindung zu einer unverschlüsselten bzw. zu einer verschlüsselten Datenbank große Ähnlichkeiten. Das Verfahren wird ausführlicher unter Herstellen von Verbindungen mit Datenbanken beschrieben. Sie verwenden die open() -Methode zum Öffnen einer Verbindung im synchronen Ausführungsmodus oder die openAsync() -Methode zum Öffnen einer Verbindung im asynchronen Ausführungsmodus . Der einzige Unterschied besteht darin, dass Sie beim Öffnen einer verschlüsselten Datenbank den richtigen Wert für den encryptionKey -Parameter angeben müssen (dies ist der fünfte Parameter der open() -Methode und der sechste Parameter der openAsync() -Methode).

Wenn Sie einen falschen Verschlüsselungsschlüssel angeben, wird ein Fehler ausgegeben. Für die open() -Methode wird eine SQLError -Ausnahme ausgegeben. Für die openAsync() -Methode löst das SQLConnection -Objekt ein SQLErrorEvent -Ereignis aus, dessen error -Eigenschaft ein SQLError -Objekt enthält. In beiden Fällen hat das von der Ausnahme generierte SQLError-Objekt die errorID -Eigenschaft mit dem Wert 3138. Diese Fehler-ID entspricht der Fehlermeldung „File opened is not a database file“ (Die geöffnete Datei ist keine Datenbankdatei).

Im folgenden Beispiel wird das Öffnen einer verschlüsselten Datenbank im asynchronen Ausführungsmodus beschrieben. Der Einfachheit halber ist der Verschlüsselungsschlüssel in diesem Beispiel im Anwendungscode fest vorgegeben. Von dieser Methode wird jedoch dringend abgeraten, da sie nicht sicher ist.

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); 
    } 
} 

Im folgenden Beispiel wird das Öffnen einer verschlüsselten Datenbank im synchronen Ausführungsmodus beschrieben. Der Einfachheit halber ist der Verschlüsselungsschlüssel in diesem Beispiel im Anwendungscode fest vorgegeben. Von dieser Methode wird jedoch dringend abgeraten, da sie nicht sicher ist.

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); 
    } 
} 

Ein Beispiel für das empfohlene Verfahren zum Generieren eines Verschlüsselungsschlüssels finden Sie unter Beispiel: Generieren und Verwenden von Verschlüsselungsschlüsseln .

Wenn eine Datenbank verschlüsselt ist, können Sie den Verschlüsselungsschlüssel auch zu einem späteren Zeitpunkt ändern. Um den Verschlüsselungsschlüssel einer Datenbank zu ändern, öffnen Sie zunächst eine Verbindung mit der Datenbank, indem Sie eine SQLConnection -Instanz erstellen und ihre open() - oder openAsync() -Methode aufrufen. Wenn die Verbindung zur Datenbank hergestellt wurde, rufen Sie die reencrypt() -Methode auf und übergeben den neuen Verschlüsselungsschlüssel als Argument.

Wie bei den meisten Datenbankoperationen richtet sich das Verhalten der reencrypt() -Methode danach, ob die Datenbankverbindung den synchronen oder den asynchronen Ausführungsmodus verwendet. Wenn Sie die Verbindung zur Datenbank mit der open() -Methode herstellen, wird die reencrypt() -Operation synchron ausgeführt. Wenn die Operation abgeschlossen ist, wird die Ausführung mit der nächsten Codezeile fortgesetzt:

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

Wird die Verbindung zur Datenbank dagegen mit der openAsync() -Methode hergestellt, wird die reencrypt() -Operation asynchron ausgeführt. Mit dem Aufruf von reencrypt() beginnt die Neuverschlüsselung. Nach Abschluss der Operation löst das SQLConnection-Objekt ein reencrypt -Ereignis aus. Sie verwenden einen Ereignis-Listener, um festzustellen, wann die Neuverschlüsselung abgeschlossen ist:

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 
}

Die reencrypt() -Operation wird in einer eigenen Transaktion ausgeführt. Wenn die Operation unterbrochen wird oder fehlschlägt (zum Beispiel, weil die Anwendung vor Abschluss der Operation beendet wird), wird die Transaktion zurückgenommen. In diesem Fall ist der ursprüngliche Verschlüsselungsschlüssel weiterhin der gültige Verschlüsselungsschlüssel für die Datenbank.

Mit der reencrypt() -Methode kann der Verschlüsselungsschlüssel nicht von der Datenbank entfernt werden. Wenn Sie einen null -Wert oder einen Verschlüsselungsschlüssel, der kein 16-Byte-ByteArray ist, an die reencrypt() -Methode übergeben, wird ein Fehler ausgegeben.

Im Abschnitt Verwendungszwecke einer verschlüsselten Datenbank sind verschiedene Fälle aufgeführt, in denen die Verwendung einer verschlüsselten Datenbank angebracht ist. Selbstverständlich gelten für unterschiedliche Verwendungsszenarien unterschiedliche Datenschutzanforderungen. Wie Sie den Einsatz von Verschlüsselung in Ihre Anwendung einbinden, spielt eine wichtige Rolle beim Schutz der Daten in einer Datenbank. Wenn Sie zum Beispiel eine verschlüsselte Datenbank verwenden, um private Daten zu schützen, auch vor Benutzern desselben Computers, benötigt die Datenbank der einzelnen Benutzer jeweils einen eigenen Verschlüsselungsschlüssel. Die höchstmögliche Sicherheit erzielen Sie, wenn die Anwendung den Schlüssel aus einem vom Benutzer eingegebenen Kennwort generieren kann. Wenn der Verschlüsselungsschlüssel auf einem Kennwort basiert, wird sichergestellt, dass auch dann kein Zugriff auf die Daten möglich ist, wenn eine andere Person das Konto des Benutzers auf dem Computer verwendet. Ein anderes Szenario liegt vor, wenn eine Datenbankdatei von allen Benutzern Ihrer Anwendung, aber nicht von anderen Anwendungen gelesen werden soll. In diesem Fall benötigt jede installierte Kopie der Anwendung Zugriff auf einen gemeinsam genutzten Verschlüsselungsschlüssel.

Sie können Ihre Anwendung und insbesondere das Verfahren zum Generieren des Verschlüsselungsschlüssels entsprechend Ihren Anforderungen für den Schutz der Anwendungsdaten entwerfen. In der folgenden Liste finden Sie verschiedene Vorschläge für unterschiedliche Stufen des Datenschutzes:

• Damit eine Datenbank für jeden Benutzer, der Zugriff auf die Anwendung hat, auf jedem Computer zugänglich ist, verwenden Sie einen einzelnen Schlüssel, der allen Instanzen der Anwendung zur Verfügung steht. Zum Beispiel kann eine Anwendung, wenn sie zum ersten Mal ausgeführt wird, den gemeinsam genutzten Verschlüsselungsschlüssel über ein sicheres Protokoll wie SSL von einem Server herunterladen. Der Schlüssel kann dann zur späteren Verwendung im verschlüsselten lokalen Speicher gespeichert werden. Alternativ dazu können Sie die Daten auf dem Computer auf Benutzerbasis verschlüsseln und die Daten mit einem Remote-Datenspeicher, zum Beispiel einem Server, synchronisieren, damit die Daten übertragbar sind.

• Damit die Daten nur für einen einzelnen Benutzer auf einem Computer zugänglich sind, generieren Sie den Verschlüsselungsschlüssel aus einer benutzerspezifischen geheimen Eingabe (zum Beispiel aus einem Kennwort). Verwenden Sie keinen Wert, der einem bestimmten Computer zugeordnet ist (zum Beispiel ein Wert, der im verschlüsselten lokalen Speicher gespeichert ist), um den Schlüssel zu generieren. Alternativ dazu können Sie die Daten auf dem Computer auf Benutzerbasis verschlüsseln und die Daten mit einem Remote-Datenspeicher, zum Beispiel einem Server, synchronisieren, damit die Daten übertragbar sind.

• Damit eine Datenbank nur einer einzelnen Person auf einem einzelnen Computer zugänglich ist, generieren Sie den Schlüssel aus einem Kennwort und einem „Salt“ (zufällig gewählte Bitfolge). Ein Beispiel für diese Vorgehensweise finden Sie unter Beispiel: Generieren und Verwenden von Verschlüsselungsschlüsseln .

Nachstehend sind zusätzliche Sicherheitsüberlegungen aufgeführt, die beim Entwickeln einer Anwendung zu beachten sind, die eine verschlüsselte Datenbank verwendet:

• Ein System ist immer nur so sicher wie sein schwächster Bestandteil. Wenn der Verschlüsselungsschlüssel anhand eines vom Benutzer eingegebenen Kennworts generiert wird, ziehen Sie in Betracht, Mindestlänge und Komplexitätsstufe des Kennworts festzulegen. Ein kurzes Kennwort, das nur Buchstaben oder Ziffern enthält, ist relativ leicht herauszufinden.

• Der Quellcode einer AIR-Anwendung wird als einfacher Text (für HTML-Inhalte) oder im leicht zu dekompilierenden Binärformat (für SWF-Inhalt) auf dem Computer des Benutzers gespeichert. Da der Quellcode zugänglich ist, beachten Sie diese zwei Punkte:

  • Geben Sie Verschlüsselungsschlüssel nie mit Hard-Coding im Quellcode an.

  • Gehen Sie immer davon aus, dass Angreifer das zum Generieren des Verschlüsselungsschlüssels verwendete Verfahren (zum Beispiel durch einen Zeichenzufallsgenerator oder einen bestimmten Hashing-Algorithmus) leicht herausfinden können.

• Für die AIR-Datenbankverschlüsselung wird der Advanced Encryption Standard (AES) mit Zähler im CBC-MAC-Modus (CCM) verwendet. Bei dieser Verschlüsselungsart muss ein vom Benutzer eingegebener Schlüssel mit einem Salt-Wert kombiniert werden, damit er sicher ist. Ein Beispiel für diese Vorgehensweise finden Sie unter Beispiel: Generieren und Verwenden von Verschlüsselungsschlüsseln .

• Wenn Sie eine Datenbank verschlüsseln, werden alle Festplattendateien verschlüsselt, die von der Datenbankengine zusammen mit dieser Datenbank verwendet werden. Die Datenbankengine speichert einige Daten jedoch in einem Arbeitsspeicher-Cache, um die Lese- und Schreibzeitleistung bei Transaktionen zu verbessern. Alle speicherresidenten Daten bleiben unverschlüsselt. Wenn ein Angreifer auf den von einer AIR-Anwendung verwendeten Arbeitsspeicher zugreifen kann, zum Beispiel durch Verwenden eines Debuggers, sind die Daten in einer geöffneten, unverschlüsselten Datenbank zugänglich.

In dieser Beispielanwendung wird ein Verfahren zum Generieren eines Verschlüsselungsschlüssels veranschaulicht. Diese Anwendung soll die höchste Datenschutz- und Sicherheitsstufe für Benutzerdaten bieten. Ein wichtiger Aspekt beim Sichern privater Daten ist es, vom Benutzer zu verlangen, dass er jedes Mal ein Kennwort eingeben muss, wenn die Anwendung eine Verbindung zur Datenbank herstellt. Demzufolge sollte eine Anwendung, die diese Datenschutzstufe erfordert, den Verschlüsselungsschlüssel der Datenbank nie direkt speichern, wie in diesem Beispiel gezeigt.

Die Anwendung besteht aus zwei Teilen: einer ActionScript-Klasse, die einen Verschlüsselungsschlüssel generiert (die EncryptionKeyGenerator-Klasse), und einer Basisbenutzeroberfläche, die die Verwendung dieser Klasse veranschaulicht. Den vollständigen Quellcode finden Sie unter Vollständiger Beispielcode für das Generieren und Verwenden eines Verschlüsselungsschlüssels .