Einige Fragen zum DEC

[fkerber]

Hi!

Sorry für den Titel, aber es sind wirklich einige (natürlich zusammenhängende) Fragen, sodass ich glaube, sie ruhig in einem gemeinsmen Thread stellen zu können:

Ich habe mir das DEC besorgt und fühle mich leicht erschlagen von der Vielfalt an Verschlüsselungsalgorithmen.
Wonach wäge ich denn ab, welcher nun für meinen Zweck der richtige ist? Hat das Ausgabeformat Auswirkungen auf die Sicherheit? Welche Auswirkung hat der Verschlüsselungs-Modus? (cmCBCx etc.)


Konkret geht es um die Verschlüsselung von Datensätzen in einer Datenbank. Es werden also hauptsächlich Text, aber auch einige Zahlen zu verschlüsseln sein...


Ciao, Frederic

[negaH]

1.) die Vielzahl der Algorithmen ist nur eine Frage der Kompatibilität vom DEC als Bibliothek. Du wählst dir 1-3 Algorithmen aus den über 70 vorhanden aus. Wichtig für dich ist nur das alle verfügbaren Algorithmen identisch programmierbar sind, du kannst also in Zukunft ohne Probleme von deinen 1-3 ausgewählten Verfahren wechseln auf die anderen Verfahren. Darin besteht der Sinn vom DEC.

2.) auswählen wirst du dir ein Hashverfahren, ein Verschl. Verfahren und ein oder zwei Text Konvertierungs Verfahren. Als Hash hat sich SHA1 durchgesetzt, als Cipher AES (Rijndael) und als Textformat ist MIME64 zu empfehlen.

3.) die Wahl des Ciphrmode (cmCBCx etc.pp.) ist da schon kritischer. Du kanst wählen ob du konform zu anderen Standards sein möchtest (alle ausser cmCTSx und cmCFSx) oder ob du es sicherer haben möchtest dafür nicht standardkonform (zb. cmCTSx/cmCFSx die ich entwickelt habe). Du kannst wählen ob du nur in Blöcken a x Bytes ver/entschl. musst oder ob du auf Bytegröße genau arbeiten möchtest (cmCBCx oder cmCBC8). Diese Entscheidung ist eine technischologisch und auch sicherheitsrelevante Entscheidung.

Kurz: du möchtest Inhalte von Datenbankfeldern schützen, also sehr kurze Informationsblöcke. In diesem Falle sollte es nicht so sehr auf Geschwindigkeit ankommen sondern auf Sicherheit und die vermeidung des Paddings der Daten. Modis wie cmCFS8, cmOFB8, cmCBC8 wären die Wahl. Willst du einigermaßen Standardkonform bleiben wären cmCBC8 oder cmOFB8 richtig, möchtest du höhere Sicherheit dann cmCFS8.

Zitat:

Hat das Ausgabeformat Auswirkungen auf die Sicherheit?

Nein, darfs es auch garnicht. Als Format in einer Datenbank solltest du eines wählen das

1.) nicht durch Sprachtreiber der DB zerstört wird
2.) möglichst keine hohe Datenexpansion hat. MIME64 expandiert die binären Daten zb. um ein Ratio von 3 auf 4 Zeichen. HEX expandiert dagegen schon von 2 auf 4 Zeichen.

In jedem Falle werden die Daten expandiert, da du aus Sicherheitsgründen immer mit einem Zufallssalt arbeiten solltest. D.h. ein Addressfeld wird verschlüsselt indem bis zu 16 Bytes Zufall + die Addressdaten in einem Rutsch verschlüsselt werden. Machst du dies nicht so hat ein Angreifer die Chance über viele Addressdatensätze hinweg eine differentielle Kryptroanalyse anszusetzen.

Das größte Problem dürfte aber an ganz anderer Stelle entstehen:

Du möchtest das mehrere Benutzer die gleichen Daten bearbeiten können. Also kannst du nicht die Daten mit den Benutzerpasswörtern verschlüsseln. Stattdessen benötigst du einen zufälligen Masterkey der als Datensatz für jeden Benutzer verschlüsselt gespeichert wird. Du kannst dies auf Datenbankebene machen oder auf Datensatzebene. Machst du es auf Datenbankebene so heist dies es gibt nur einen Masterekey. Das erhöht das Risiko das ein Angreifer als regulärer Benutzer diesen Masterkey ausspioniert und somit alle Daten entschlüsseln kann. Zudem musst du denoch wie oben angedeutet mit einem Salt für die Daten arbeiten.
Arbeitest du auf Datensatzebene so musst du für jeden DS einen eigenen Schlüssel verwalten (zufallserzeugt). Damit sparst du dir die Zufallssalts ein. Andererseits musst du aber nun für diesen Schlüssel und pro Datensatz für alle Benutzer diesen Schlüssel geschützt abspeichern. ZB. bei 6 Benutzern also pro Datensatz 6 mal verschl. in einem Datenfeld hinterlegen.

Das sind alles Vorschläge die mir reiner sym. Verschl. funktionieren.

Du kannst es dir aber auch einfacher machen. Zb. installierst du dir eine Sofwtare wie E4M die ein virtuelles Laufwerk auf eine Datei mappen kann. Dieses Laufwerk ist online verschlüsselt und in dem speicherst du deine Access DB. Der Admin muss dann für alle Benutzer beim Hochfahren dieses Laufwerk erst mappen.

Gruß Hagen

[fkerber]

Hi!

Danke für deine sehr ausführliche Antwort!
Wo kann cih denn nähere Infos bzgl. der Modi finden? So ganz blicke ich da noch nicht durch, was was bewirkt und was du mit "standardkonform" meinst...

Zitat von negaH:

Das größte Problem dürfte aber an ganz anderer Stelle entstehen:

Du möchtest das mehrere Benutzer die gleichen Daten bearbeiten können.

Glücklicherweise habe ich dieses Problem nicht. Sorry, wenn dieser Eindruck entstanden ist...
Jeder Nutzer hat eigene Daten und jeder darf auch nur seine Daten sehen. Gemeinsame Daten wird es nicht geben.


Ciao, Frederic

[negaH]

Na das nenne ich doch "ideale Rahmenbedingungen".

Du solltest dann folgendes machen:

1.) ein Datenbankfeld "Salt" binär mit 16 Bytes anlegen. Dieses Datenbankfeld wird mit 16 Bytes Zufall gefüttert.
1.1.) ein Datenbankfeld "Check" binär mit 16 Bytes, enthält verschlüsselt einen Hash über den Sessionkey als Überprüfung ob der Benutzer das richtige Passwort benutzt (optional, wenn du's benutzen möchtest frage mich nochmal danach)
2.) dieser Salt dient in einer KDF -> Key Derivation Function -> Schlüsselableitungsfunktion zur Erzeugung eines Sessionkeys für diesen einen Datensatz.
3.) mit THash_SHA1.KDFx(Salt || Userpasswort) erzeugst du diesen Sessionkey.
4.) wenn der Benutzer nur 1 Datenfeld des Datensatzes ändert verschlüsselst du alle anderen Datenfelder immmer neu. Du speicherst als alle zu schützenden Felder immer neu. Denn bevor du speicherst erzeugst du einen neuen Salt. Das bedeutet das bei jder Änderung im Datensatz dieser immer mit einem komplett neuen, zufallsähnlichem ander Benutzerkey abhängigem Sessionkey verschlüsselt wird. Das verhindert effektiv einige der modernsten Angriffe.
5.) als Ciphermode würde ich cmCBC8 oder cmCFS8 benutzen. Die 8 bedeutet das diese Modis auf 8 Bit arbeiten. Beim AES, der ein Blockcipher ist, werden immer 16 Bytes der Nachricht in einem Rutsch verschlüsselt. Der Ciphermode stellt nun sicher ds diese Blöcke untereinander verknüpft werden, und somit bestimte Angriffe (Austasuch voin Datenblöcken) verhindert werden. Normalerweise würde man also mit AES immer in 16 Bytes Schritten eine Nachricht schützen. Das führt aber dazu das diese Nachricht in der Größe ein Mehrfaches von 16 sein muß oder aber auf dieses Merhfache expandiert werden muß, in short wir benötigen ein Padding. Verschiedene Padding-Verfahren wie CipherText Stealing sind aber bei Nachrichten < 16 Bytes unsicher ! Die Cipher Modis die auf 8 Bit = 1 Byte arbeiten benutzen im Falle von AES intern auch einen 16 Bytes Block. Allerdings wenden sie die Verschlüsselungsfunktion auch 16 mal auf diesen Block an also pro Datenbyte einmal. Statt normalerweise 1 mal pro 16 Bytes. Damit wäre der cmCBC8 Modus im Falle von AES im vergleich zum cmCBCx Modus eine 16 fache Verschlüsselung, also auch 16 mal so langsam wie cmCBCx. Dafür entfällt aber die Notwendigkeit eines Paddings. Eine Nachricht mit 17 Bytes benötigt auch nur 17 Bytes an Speicher und jedes der 17 Bytes wäre gleich stark geschützt. Nimmt man dageben cmCBCx so würde der erste 16 Bytes Block vollständig geschützt sein. Das Byte 17 würde entweder durch weitere 15 Bytes zu einem vollständigen Datenblock expandiert und dann verschlüsselt. Das bedeutet aber unser Ciphertext wäre nun 32 Bytes statt 17 Bytes groß, also expandiert. Desweiteren müssen wir diese 15 Bytes mit einer bekannten Signature versehen damit wir bei der ENtschlüsselung wieder die exakten 17 Bytes restaurieren können. Diese bekannte Signature ist aber ein Problem stellt sie ja ein Angriffsziel eines Angreifers dar. Oder man benutzt CipherText Stealiung als Padding-Verfahren. Dann würde man aus 17 bytes auch 17 Bytes Ciphertext erzeugen, also keine Expansion. Man "stiehlt" aber bestimmte Bytes zur virtuellen Expansion aus dem vorherigen Datenblock. Existiert aber kein vorheriger Datenblock, die Nachricht ist als < 16 Bytes lang, dann haben wir ein Problem, denn wir "stehlen" quasi Informationen direkt aus dem Passwort. Der so entstehende CipherText ist also schwach und könnte unter Umständen für Angriffe empfindlich sein.

Deshalb benutzt DEC eine Methode bei der im cmCBCx Modus bei denn verbleibenden Bytes in den korresponierenhden cmCBC8 Modus gewechselt wird. Das IST NICHT STandardkonform, obwohl ich mit dieser Wahl im DEC nicht die einzigste Bibliotrhek bin die es genauso macht. Es gibt aber keinen Standard dafür ;(

Davon abgesehen relativiert sich diese "Standard"-gehabe im Falle der Ciphermodis erheblich. Denn defakto existiert noch garkein international annerkannter und wissenschaftlich geprüftere Standard. AES/NIST arbeitet noch immer daran und hat schon einige Modis selektiert aber noch nicht endgültig verabschiedet.

Ergo: Standardkonform heist hier nur ob du kompatibel zu den meisten Librarys sein möchtest, und das wäre mit cmCBC8, cmCBCx, cmCFB8, cmOFB8 auf jeden Falle gegeben.
Wichtig ist nur eines, niemals cmECB benutzen, es sei den deine Daten bestehen aus Zufall !!

Gruß Hagen

[negaH]

Deine Datenbank könnte also so aussehen:

Salt (16 Bytes binär), Check (16 Bytes binär), verschlüsselte Datenfelder (binär), unverschl. Datenfelder, evetuell Indexdaten zur Sortierung nach verschl. Datenfelder (komplizerte Aufgabe)

Die Speicherroutine könnte so arbeiten:

1.) neuen 16 Bytes Salt per Zufall erzeugen
2.) neuen Sessionkey erzeugen, SessionKey := THash_SHA1.KDFx(Password, Salt, Cipher.Context.KeySize, TFormat_COPY)
3.) Check erzeugen, dazu 8 Bytes Zufall erzeugen diesen invertiert hintendran hängen um so auf 16 Bytes zu kommen und mit Sessionkey verschlüsseln
4.) jedes Datenfeld mit Sessionkey verschlüsseln
5.) Salt,Check und Daten speichern

Beim Lesen der Daten
1.) Salt laden
2.) wie oben in Punkt 2.) Sessionkey erzeugen
3.) Check laden und entschlüsseln, überprüfen das die ersten 8 Bytes invertiert identisch zu den 2'ten 8 Bytes sind, wenn nein falsches Passwort
4.) restlichen Felder laden und mit Sessionkey erzeugen

Der Check stellt sicher das es zu 2^64 möglichen Werten auch 2^64 mögliche korrekte Prüfcodes existieren. Ein Angreifer kann also diesen Check nicht misbrauchen in einer Brute Force Attacke um festzustelle ob er das richtige Passwort ermittelt hat.

Der Salt stellt sicher das es 2^128 verschiedene Sessionkeys gibt zu dem einen Benutzerpasswort. Somit werden alle als Wörterbuch-Angriffe bekannte Attacken ausgeschlossen, besonders die Rainbow Tabellen.

Desweiteren verhindert der Salt die differentielle Kryptoanalyse. Dh. auf Grund dessen das man fast identische Daten merhfach verschlüsselt kann man nicht das Passwort ermitteln, eben differntiell kryptoanalysieren. Logisch wir erzeugen ja bei jedem Speichern einen neuen zufälligen Salt der dann über die Hashfunktion zu einem ebenfalls pseudo-zufälligen aber Benutzerpasswort abhängigen Sessionkey führt.

Ein besonderes Augenmerk gilt eventuell notwenigen Indizes zur Sortierung der Datenbank nach den verschlüsselten Datenfeldern. Du musst ja dann separate und für die DB auswertebare Felder als Indexfelder benutzen. Es sollte dann aber sichergestellt sein das ein Angreifer aus diesen Indexfelder nicht auf die Daten in den verschl. feldern rückschließen kann. Das ist defakto sehr schwierg, wenn nicht sogar unmöglich.

Gruß Hagen

[fkerber]

Hi!

Danke für die ausführlichen Erläuterungen. Ich werde mir das Ganze mal ausdrucken und versuchen zu verstehen. Wenn ich dann mal durchgestiegen bin und noch Fragen habe, werde ich mich wieder melden!

Ciao, Frederic