Entw.: DB-Verschlüsselung

Datenbankverschlüsselungen gewinnen im Zuge des Cloud-Computing's und der Ausgliederung der Server-Hardware zu großen Hosting-Anbietern immer mehr an Bedeutung. Es häufen sich immer mehr die Programmanforderungen, wonach personenbezogene Daten zu verschlüsseln sind, wenn die Daten von Dritten einsehbar sind. Dieser Artikel zeigt wohl einer der effizientesten Datenbankverschlüsselungtechniken in einer 3-Tier-Architektur.

Die Möglichkeiten der wichtigsten Datenbanken (z.B. Oracle, SQLServer) zur Eigenverschlüsselung sind augenscheinlich ausreichend. Sie werden aber bei meinem derzeitigen Projekt aus guten Gründen nicht verwendet. Wird aber zukünftig von den Datenbankherstellern eine schnelle homomorphe Verschlüsselung angeboten, so ist auf diese umzuschwenken. Diese Verschlüsselung gilt als heiliger Gral des Cloud-Computings, da sich hier letztendlich der Erfolg vom Cloud-Computing entscheiden wird.
Wichtig für die Sicherheit der Datenbankverschlüsselung ist der richtige Umgang mit den Schlüsseln und wo verschlüsselt bzw. entschlüsselt wird.

Schlüsselverwaltung

Beim Umgang mit den Schlüsseln sind 3 Vorgehensweisen möglich:

• → Der oder die Schlüssel werden in der Datenbank gespeichert. Problematisch bei diesen Vorgehensweisen ist, dass privilegierten Benutzern, also z.B. Datenbankadministratoren, der Zugriff auf diese Schlüssel und damit auf die verschlüsselten Daten kaum zu entziehen ist.
• → Der oder die Schlüssel werden in einer Betriebssystemdatei abgelegt, die im Rahmen der Verschlüsselung bzw. Entschlüsselung gelesen wird.
• → Schließlich können die Schlüssel durch die Benutzer selbst verwaltet werden. Hier besteht allerdings die Gefahr, dass Schlüssel entweder vergessen werden - mit der Folge, dass der Zugriff auf die verschlüsselten Daten endgültig verloren geht.

Die 2. Vorgehensweise wird hier bevorzugt, da dieses Verfahren bequem die Verschlüsselung bzw. Entschlüsselung außerhalb der Datenbank zulässt. Der Datenbankadministrator besitzt dabei keine Kenntnisse über die Verschlüsselungstechnik und den Key’s.

Technische Umsetzung

Konkrete technische Umsetzungen werden von keiner bekannten Datenschutzrichtlinie vorgegeben. Das Zauberwort heißt angemessen. Man muss also angemessene Maßnahmen ergreifen um die Daten zu schützen.

Eine sichere und damit starke Datenbankverschlüsselung verbraucht immer mehr CPU-Ressourcen als eine schwache Verschlüsselung. Die Performance-Einbußen sind merklich. Bei Systemen, die schon Laufzeitprobleme haben, ist eine starke Datenbankverschlüsselung wegen weitgehenden Akzeptanzproblemen kaum zu implementieren.

Bei einer 3-Tier-Architektur mit Datenbank, REST Server und HTML5-Thin-Client reicht i.d.R. eine Verschlüsselung der betroffenen Spalten. Aus der SQL-Verarbeitungssicht ist die Verschlüsselung für den Entwickler ideal, wo die Sortierreihenfolgen in verschlüsselten und unverschlüsselten Zuständen gleich sind.

Eine einfache angemessene symmetrische Verschlüsselung ist die XOR-Verschlüsselung. Sie ist sehr effizient, da die Performance kaum leidet, ist leicht zu implementieren und ist dabei noch recht sicher.

Zusatzanforderungen

Beim derzeitigen Projekt gibt es zusätzlich noch folgende Anforderungen:

• → Die Verschlüsselung und Entschlüsselung erfolgt im REST Server durch kompilierte Methoden. Zusätzlich sind diese Methoden besonders gegen Decompilieren zu schützen. Ein Administrator hat somit keine Möglichkeit die Daten leicht zu entschlüsseln.
• → Jeder Key wird automatisch erzeugt und bedarf keiner Administration.
• → Regelmäßig werden die verschlüsselten Daten neu mit einem anderen Key verschlüsselt. Das Datum der Neuverschlüsselung wird in der Datenbank vermerkt, um eine spätere Zuordnung der Schlüssel zu ermöglichen.
• → Die Key’s werden nicht in der Datenbank abgelegt, sondern binär und wiederum verschlüsselt in einer Betriebssystemdatei des REST Servers. Zu allen Key’s werden die Gültigkeitszeiträume mit abgespeichert, so dass beim Einspielens eines Datenbank-Backup’s der korrekte Key verwendet werden kann.
• → Datenbank und Key-Datei des REST Servers sind zur gleichen Zeit zu sichern.

Beispiel-Source

Das folgende Code-Beispiel zeigt eine mögliche XOR-Verschlüsselung mit Delphi-XE2-Mitteln:

function BuildKeyBytes(const sKey: String): TBytes;
var
 i, l_iKeyLng: Integer;
 l_arBytes: TBytes;
begin
 l_arBytes:= TDBXPlatform.WideStrToBytes(sKey);
 l_iKeyLng:= Length(l_arBytes);
 for i := 0 to l_iKeyLng-1 do begin
   if l_arBytes[i] = 0 then
     l_arBytes[i] := 1;
 end;
 Result := l_arBytes;
end;
 
(* this function should be used ONLY for encryption *)
function EncryptText(const arKey: TBytes; const sText: String): String;
var
 i, n, l_iKeyLng, l_iTextLng: Integer;
 l_arTextBytes: TBytes;
begin
 l_arTextBytes := TDBXPlatform.WideStrToBytes(sText);
 l_iKeyLng  := Length(arKey);
 l_iTextLng := Length(l_arTextBytes);
 for i := 0 to l_iTextLng-1 do begin
   n := i mod l_iKeyLng;
   l_arTextBytes[i] := l_arTextBytes[i] xor arKey[n];
 end;
 Result := TDBXPlatform.BytesToWideStr(l_arTextBytes);
end;
 
(* this function should be used ONLY for decryption *)
function DecryptText(const arKey: TBytes; sText: String): String;
begin
 Result := EncryptText(arKey,sText);
end;
 
procedure TForm1.btnEncryptClick(Sender: TObject);
var
 i: Integer;
 l_arKeyBytes: TBytes;
begin
 if Length(txfKey.Text) > 0 then begin
   l_arKeyBytes := BuildKeyBytes(txfKey.Text);
   mDest.Lines.Clear;
   for i := 0 to mSource.Lines.Count-1 do begin
     mDest.Lines.Add(EncryptText(l_arKeyBytes,mSource.Lines[i]));
   end;
 end
 else
   ShowMessage('Please enter key!');
end;
 
procedure TForm1.btnDecryptClick(Sender: TObject);
var
 i: Integer;
 l_arKeyBytes: TBytes;
begin
 if Length(txfKey.Text) > 0 then begin
   l_arKeyBytes := BuildKeyBytes(txfKey.Text);
   mSource.Lines.Clear;
   for i := 0 to mDest.Lines.Count-1 do begin
     mSource.Lines.Add(DecryptText(l_arKeyBytes,mDest.Lines[i]));
   end;
 end
 else
   ShowMessage('Please enter key!');
end;

Copyright © 17.05.2012 hadv.de. All Rights Reserved.