Wie Verschlüsselung realisieren? (Datenbank)

Hallo,
ich möchte eine Datenbank verschlüsseln und möchte mich erkundigen wie man vorgehen sollte und was sich als probates Mittel dafür erweist.

Gerade was den IV angeht fühle ich etwas überfragt - genauer gesagt kommen meine aktuelle Bedenken daher, dass mir nur Lösungsansätze einfallen, bei denen der IV fest ein programmiert ist. Hat jemand eine Idee wie man diesen nicht fix anbietet?

Besten Dank vorab.
Martin

Willst du einzelne Spalten verschlüsseln? Du kannst den IV im Prinzip wie ein Salt benutzen, also im Klartext (bzw geeignet mit base64 o.ä. codiert) vorne vor das Chiffrat packen und dann beim Auslesen das entsprechend wieder auseinanderpuzzeln.

Bei den IV muss du Dir keine Sorgen machen. Der kann bei AES öffentlich sein.

Initialisierungsvektor

Ahh, das erklärt schon Einiges, vielen Dank für die Infos.

Sprich, eine guter Ansatz ist eine weitere Spalte anzubieten, die nur die Aufgabe hat die IVs zur Verfügung zu stellen. Wie sieht es da mit der Performance aus? Es soll ja möglichst so umgesetzt werden, dass die Erstellung eines Schlüssels eine gewisse Zeit benötigt, um Sicherheit vor BruteForce-Angriffen zu bekommen. Wie ließe sich das gewährleisten (und testen? - auf das Bauchgefühl würde ich mich ungern verlassen^^)

Und wie verhält sich die Sache, wenn es keinen "Klartext" gibt. Angenommen man speichert ein einziges Passwort, baut damit den Schlüssel (bswp AES) und verschlüsselt es dann "mit sich selbst". Wie sicher ist das anzusehen?
Bei der zweiten Frage gehts praktisch darum den Zugang zum eigentlichen Schlüssel (der dann, entschlüsselt mit sich selbst, die Datenbank unter Berücksichtigung der einzelnen IVs wieder entschlüsselt) zu ermöglichen.
Hab irgendwo (meine sogar auf SO) gelesen, dass es nicht sinnvoll sein soll einen Schlüssel mit sich selbst zu verschlüsseln. Stimmt das? Falls ja wie könnte eine Alternative aussehen? Da der Nutzer am Ende auch ohne online-Verbindung auf seine Daten zu können soll, suche ich nach einer Lösung die nach Möglichkeit 100%tig offline nutzbar ist.

Besten Dank vorab und euch schon mal einen schönen Karfreitag

Das würde mcih auch interressieren. Du möchtest also clientseitig verschlüsseln?

Ich weiß nur:

ist der Schlüssel erst mal beim Client hast du kaum Sicherheit dass es bestand hat.

Und einen Schlüssel mit sich selber verschlüsseln klingt für mich wie seine PIN auf die Kreditkarte schreiben

Hehe, mir geht's nicht mal so sehr darum, dass "meine" Daten (sprich zB der In-App-Billings-Key o.ä.) ausgelesen werden... Was das angeht habe ich schon einen relativ guten Weg gefunden. Jedenfalls kann ich bei meiner anderen App sehen wie viele Leute bezahlt haben und wie viele "Premium"-Features nutzen und dort gibts keinen, der sich eine Premium-Freischaltung erschlichen hätte. Machbar wäre es (mit etwas Aufwand) trotzdem. <- über das Thema kann man sich ja per PN oder im Chat austauschen, würde dazu ungern "öffentlich" mehr sagen.
Aber ich stimme dir voll zu, was "diese" Keys angeht, ist man wohl nie komplett auf der sicheren Seite - jedenfalls nicht, wenn man dem Nutzer eine möglichst reibungslose Abwicklung anbieten will (klar, kann man bei jedem App-Start auf dem Google-Server nachfragen, ob der Nutzer auch brav bezahlt hat - aber das Ende vom Lied sind wahrscheinlich unzufriedene Nutzer, die Premium-Features nicht nutzen können, wenn sie im Wald ohne Verbindung dastehen. Das will ich niemandem zumuten, da ich selbst auch ziemlich säuerlich werde, wenn ich für was gezahlt habe und es dann nicht funktioniert)

Zum eigentlichen Thema: Die neue App soll eine Art Passwort-Manager werden, mit ein paar speziellen Funktionen und da darf es natürlich auf keinen Fall sein, dass irgendwas undicht ist - sind ja immerhin Passwörter. Da der Nutzer aber selbst an seine Daten rankommen soll und selbst ein individuelles Passwort setzt, ist die Problematik nicht mit der vom IAB-Key zu vergleichen (also technisch realisierbar ist eine sichere Implementierung definitiv). Wenn ein Dritter aber ein Leck findet, wohl um ein Vielfaches schlimmer.

So an sich fällt mir nichts ein, warum es extrem unsicher sein sollte einen Schlüssel mit sich selbst zu verschlüsseln. Wenn der Nutzer ein ausreichend langes Passwort eingestellt hat und der Verschlüsselungsalgor. sicher ist, sollte es schon mehr oder weniger "sicher" sein. Aber sicher bin ich mir nicht.

Wenn jemand ein verständliches Buch zum Thema Kryptographie empfehlen kann, wäre mir vielleicht auch schon geholfen. Die Thematik finde ich schon ziemlich interessant, aber leider findet man im Netz gerade bei diesem Thema auffallend viele Aussagen, die sich widersprechen. :-/

Man kann den Schlüssel verschlüsseln. Warum auch nicht.

Bei AES braucht man aber trotzdem den unverschlüsselten Schlüssel um an den verschlüsselten Schlüssel heranzukommen.

Einfach gesagt, man sollte dafür sogen, das der Schlüssel nicht auf dem Device liegt. Mit ein bisschen Aufwand bekommt man ihn immer heraus. Man kann z.B. den Speicher eines Device auslesen.

Bei Verschlüsselung sind es meist nicht Verschlüsselungen, die fehlschlagen, sondern die Implementierungen sind einfach nur schlecht.

Was nützt ein md5 Hash eines Passwort, wenn die Hash's aller Passworte mit UserId offen im internen Speicher der App liegen (oder mit HTTP offen in einem XML übertragen werden)?
Denn man kann mit vertretbaren Aufwand ein Password erzeugen, das den gleichen md5 Hashwert hat.

Da kann man sich die Arbeit auch gleich sparen.

Der ursprüngliche Beitrag von 09:42 Uhr wurde um 09:46 Uhr ergänzt:

---

Angewandte Kryptographie - Hanser Fachbuch

Der ursprüngliche Beitrag von 09:46 Uhr wurde um 09:56 Uhr ergänzt:

---------------------
Noch ein Nachtrag.

Du solltest die App als OpenSource entwickeln.

Gerade bei einer Passwort-App sollte man dafür sorgen, dass sie vernünftig implementiert wird.
Und das erreicht man am besten, in dem man sie von andern überprüfen lässt.

Nur mal so ein anderer Ansatz...

Was spricht dagegen ein Format zu nutzen was sehr weit verbreitet ist und schon sehr lange von vielen genutzt wird? Da haben schon viele über das Format geschaut.

Ich denke da (natürlich als Keepass Fan) an das Keepass2 Datenbank Format.
Dann sparst du dir da selbst was auszudenken.
Und du erleichtest den Nutzern die Migration zu deiner App und von deiner App weg (ja, auch das ist wichtig ;-) ).

cu

Bin gerade dabei die Implementierung mit dem IV auszustatten.
Eigentlich funktioniert es schon.
Wobei das "eigentlich" hier so zu verstehen ist, dass der Code im "Trocken-Test" funktioniert - nicht aber wenn er in der Datenbank zum Einsatz kommt.
Bzw. dort funktioniert er eigentlich auch, aber irgendwas passt dann (mal wieder) mit der Konvertierung nicht. Sprich die Daten werden so "halb korrekt" angezeigt.
Aktuell generiere ich den IV mittels der Systemzeit (via long = System.currentMS).
Habe schon versucht den Wert als TEXT und als INTEGER abzuspeichern, leider beides ohne Erfolg.

An was kann das liegen? Ich werde noch verrückt mit den Base64 Strings und diesem ganzen Konvertierungskram. Gibts irgendwo eine verlässliche Anleitung wo man das mal nachlesen kann? Ohhje :-/

Danke vorab

Hehe, damit ich den Cipher in seiner vollen Stärke nutzen konnte musste ich in der IDE eine Library laden, damit der Status auf "unlocked" steht. Meines Wissens erklärt man damit, dass man es nicht für illegale Zwecke verwendet. Besagte Erweiterung habe ich von Oracle bezogen.

Nachtrag: Habs hinbekommen. Hatte eine Base64 Konvertierung doppelt angewendet, bzw durch den Zusatz NO_WRAP gabs Unstimmigkeiten.