MySQL BLOB encryption

[ExceptionOverflow]

Hallo,

ich habe die Aufgabe bekommen mich zu erkundigen wie wir unsere MySQL Datenbank Daten verschlüsseln könnten. MySQL bietet hier ja schon ein paar schöne Möglichkeiten an ohne, dass man sich selbst großartig die Finger schmutzig machen muss. Es geht aber in meinem Fall nicht darum string Werte zu verschlüsseln sondern die gespeicherten Dateien (BLOB Felder) unserer Kunden. Die MySQL Datenbank verwalte ich, sie wird noch nicht produktiv eingesetzt und ich habe somit noch alle Möglichkeiten der Welt Veränderungen daran vorzunehmen, was eben nötig sein sollte.

Die built-in Verschlüsselungsmöglichkeiten von MySQL habe ich mir schon mal kurz angesehen, doch scheint es mir hier nicht einfach so möglich zu sein ein BLOB Feld zu verschlüsseln außer ich würde meine bytes in einen string basteln .

Der Idealfall unserer Verschlüsselung würde so aussehen (So wäre das eben gewünscht, falls das so zu realisieren ist):
- MySQL / oder auch Client verschlüsseln die Daten
- Daten sind nur mit einem speziellen Schlüssel / Passwort zu entschlüsseln

Da ich mich mit Datenbanken und SQL nicht besonders gut auskenne bin ich hier mal auf euren Rat angewiesen und würde mich sehr über eine kleine Hilfestellung freuen!

[sx2008]

Mal angenommen du würdest die Blobs auf dem Client mit AES256 verschlüsseln.
AES gibt es mit 128, 192 und 256 Bit - das entspricht einer Schlüssellänge von 8, 12 oder 16 Bytes.
Dann würde ich den Key für AES so berechnen: key := SHA256(password+tabellenname+primaryschluesselfeld);
Somit erhält jeder einzelne Blob einen eigenen Schlüssel.
Ein Angreifer könnte z.B. einen Blob aus einem best. Record kopieren und in einen anderen Record einfügen.

username	blob
administrator	ethert8h88z5w45h8dfb8hsfdh....
guest	jerwgw34t43guefguhw5gurefgsdfgsdf...
service	jieg4589gw485gsdufghuwreguherg...

Er weiß zwar nicht was sich hinter den Blobs verbirgt, aber wenn er den Blob vom adninistrator beim guest einfügt könnte das ja ganz interessant werden...
Das Ergebnis wäre allerdings Datenmüll weil dann der berechnete Schlüssel nicht passt.
Eine Änderung des Primärschlüssels darf deine Anwendung natürlich nicht vorsehen; sonst wären die Blobs nicht mehr zu entschlüsseln.
Anstelle des Primärschlüssels kann man auch andere eindeutige Felder in den Schlüssel einbringen.

[Sir Rufo]

Wieso gibt es einen Direktzugriff auf die Datenbank?
Wer greift da alles direkt zu und wie (inhouse..Internet)?

[ExceptionOverflow]

Zitat von Sir Rufo:

Wieso gibt es einen Direktzugriff auf die Datenbank?
Wer greift da alles direkt zu und wie (inhouse..Internet)?

Das war für mich als Entwickler der DB gemeint und nicht für den User / Client. Der Client kommuniziert nur mit einem WCF Service und dieser (WCF Service) hat dann den direkten Zugriff zur DB.

@sx2008: Danke dieser Ansatz gefällt mir schon ganz gut, ich denke ich hatte auch einen Denkfehler oder einfach noch nicht genügend Hintergrundwissen.
Meine eigentliche Idee war ja das BLOB Feld 'selbst' zu verschlüsseln beim einfügen über das SQL Statement, das scheint aber ja so (zumindest bei BLOBs) nicht vorgesehen zu sein, auf dem Weg zum Service hätten die Daten auch abgegriffen werden können.

Ich werde wohl die Verschlüsselung auf dem Client vornehmen somit sind die Daten auch auf dem Weg sicher, der Schlüssel sollte natürlich so generiert sein, dass man das nicht selbst rekonstruieren sein, also wie im Vorschlag von sx2008 über das PW und ein paar andere Indikatoren. (Entspricht ja eigentlich auch dem Vorschlag von sx2008, ich wollte nur aufzeigen, dass ich meinen ersten Ansatz [oben Beschrieben] verworfen habe)