Verschlüsselung macht mich Wahnsinnig!

Thallius · 10. Dezember 2014, 11:50

Hi,

ich komme auf keinen grünen Zweig. Ich hoffe jemand von euch hat eine Idee wie ich meine Anforderung umsetzen kann. Ich weiß jetzt echt nicht mehr weiter.

Ich habe eine Java Application welche an Kunden herausgegeben wird. Diese App schickt einen Datensatz an einen Datenbank-Server welcher durch eine Unique ID gekennzeichnet ist. Wird ein neuer Datensatz mit der selben Unique ID geschickt, so muss der vorherige Datensatz geupdated werden und kein neuer angelegt.

Dann gibt es eine zweite App, welche nur ausgewählte Personen bekommen (Und die auch nich in Java sein muss) mit der man die verschlüsselten Daten komplett vom Server zieht (Es werden maximal so 500-1000 Datensätze sein, von daher ist es nicht schlimm, dass durch die verschlüsselung die DB eigentlich ausgehebelt wird), die diese Daten dann entschlüsselt und man sie sich ansehen und editieren kann.

Jetzt kommen die Anforderungen die erfüllt werden müssen:

Die Unique ID selber muss verschlüsselt auf dem Server sein!
Der Server selber darf die Daten nciht entschlüsseln können!
Der Schlüssel zum Entschlüsseln darf nicht in der Java App vorhanden sein (Zu leicht zu decompilieren)!

Ich dachte also, ich mache eine asynchrone Verschlüsselung und gebe der Java App nur den Public key. Das funktioniert so aber nicht, da ich mit einer RSA Verschlüsselung ja nur KeyLength/8-11 Zeichen verschlüsseln kann. Mache ich eine synchrone Verschlüsselung, dann ist der Key zum Entschlüsseln auch in der Java App. Da kann ich mir das Verschlüsseln auch gleich sparen.

Die einzige Idee die ich jetzt noch hätte wäre, dass ich bei jedem Verschlüsseln in der Java App einen neuen synchronen Key erzeuge, damit verschlüssele und dann diesen Key mit dem RSA Public key verschlüssele und das Ganze dann an denr Server schicke. Das würde aber bedeuten, dass die App die die Daten entschlüsselt, für jeden Datensatz erstmal den synchronen Key mit seinem private key entschlüsseln muss um dann mit diesem Key die Daten synchron zu entschlüsseln. Ganz schön aufwendig.
usserdem, wie sicher ist denn so eine synchrone AES Verschlüsselung in dem Fall dann überhaupt? Kann man eine AES Verschlüsselung ohne den Key zu haben entschlüsseln und wenn ja wieviel Aufwand ist das?

Hat jemand vielleicht noch eine ganz andere Idee wie ich mich da aus der Affäre ziehen kann?

Gruß

Claus

macmoonshine · 10. Dezember 2014, 11:57

Thallius schrieb:

Ich dachte also, ich mache eine asynchrone Verschlüsselung und gebe der Java App nur den Public key. Das funktioniert so aber nicht, da ich mit einer RSA Verschlüsselung ja nur KeyLength/8-11 Zeichen verschlüsseln kann.

asymmetrisch.

Was machst du genau? Du kannst mit RSA beliebig lange Nachrichten verschlüsseln. In Java geht das beispielsweise über die Klasse Cipher.

Thallius · 10. Dezember 2014, 11:59

macmoonshine schrieb:

Thallius schrieb:

Ich dachte also, ich mache eine asynchrone Verschlüsselung und gebe der Java App nur den Public key. Das funktioniert so aber nicht, da ich mit einer RSA Verschlüsselung ja nur KeyLength/8-11 Zeichen verschlüsseln kann.

asymmetrisch.

Was machst du genau? Du kannst mit RSA beliebig lange Nachrichten verschlüsseln. In Java geht das beispielsweise über die Klasse Cipher.

Genau die Klasse benutze ich. Und die sagt mir dann dass ich maximal 245 byte verschlüsseln darf wenn ich einen 2048 bit key benutze.

Quellcode

public byte[] encrypt(String text, PublicKey key)
{
byte[] cipherText = null;
try
{
// get an RSA cipher object and print the provider
final Cipher cipher = Cipher.getInstance("RSA");
// encrypt the plain text using the public key
cipher.init(Cipher.ENCRYPT_MODE, key);
cipherText = cipher.doFinal(text.getBytes());
}
catch (Exception e)
{
Logger.Log(e.getMessage());
e.printStackTrace();
}
return cipherText;
}

Alles anzeigen

Gruß

Claus

macmoonshine · 10. Dezember 2014, 12:05

Hast du schon mal Multipart-Verschlüsselungen über eine der verschiedenen update-Methoden versucht?

MyMattes · 10. Dezember 2014, 12:09

Bei Deinem Ansatz könnte aber der Server entschlüsseln, weil er den symmetrischen DB-Schlüssel mit seinem Private Key bekäme.

Warum nichts einen generischen symmetrischen Schlüssel für alle DB-Sätze nutzen? Asymmetrisch braucht er nicht sein, weil immer nur der Client ver-/entschlüsselt. Diesen auf dem Server mit dem Public-Key der Clients verschlüsselt ablegen und nur nach einem Client-Login an diesen übermitteln.

So kann der Server nicht die Daten lesen, der Client hat den Key nicht in der App und die Admin-App braucht nur einen Key.

Nur als Denkanstoß, die "Verschlüsselungsexperten" haben bestimmt Kommentare (so dieser Thread nicht auch abdriftet)

Mattes

Edit: HTML-Tags entfernt...

Thallius · 10. Dezember 2014, 12:23

MyMattes schrieb:

Bei Deinem Ansatz kônnte aber der Server entschlüsseln, weil er den symmetrischen DB-Schlüssel mit seinem Private Key bekäme.

Warum nichts einen generischen symmetrischen Schlüssel für alle DB-Sätze nutzen? Asymmetrisch braucht er nicht sein, weil immer nur der Client ver-/schlüsselt. Diesen auf dem Server mit dem Public-Key der Clients verschlüsselt ablegen und nur nach einem Client-Login an diesen übermitteln.

So kann der Server nicht die Daten lesen, der Client hat den Key nicht in der App und die Admin-App braucht nur einen Key.

Nur als Denkanstoß, die "Verschlüsselungsexperten" haben bestimmt Kommentare (so dieser Thread nicht auch abdriftet)

Mattes

Ich kann das zwar nicht richtig lesen aber du hast da was falsch verstanden. Der Server bekommt KEINEN key nie und niemals. Der kann also auch nichts ver- oder entschlüsseln.

Gruß

Claus

Thallius · 10. Dezember 2014, 12:23

macmoonshine schrieb:

Hast du schon mal Multipart-Verschlüsselungen über eine der verschiedenen update-Methoden versucht?

Ich bastele gerade mit blockCypher rum. Denke damit bekomme ich das zumindest hin.

Danke

Claus

gandhi · 10. Dezember 2014, 12:46

Das was Du vorhast (symmetrischen Schlüssel mit asymmetrischen Schlüssel verschlüsseln und verschicken) ist ein gängiges Verfahren (Hybrid-Verschlüsselung), man macht das aus Performance-Gründen: Kleine Teilchen (Also der 256-Bit-AES Schlüssel) mit dem RSA-Verfahren (z.B. 1536-Bit Schlüssellänge) und die eigentlichen großen Daten dann eben mit AES.

Oder denk' mal an eine Session: Einmal den Session-Key erzeugt, mit RSA verschlüsselt und ausgetauscht und anschliessend nur noch diesen verwendet.

Kommt halt auf die Datenmengen drauf an, die Du hast, ob es sich lohnt eine Hybrid-Verschlüsselung aufzuziehen

ciao

gandhi

Thallius · 10. Dezember 2014, 12:58

Also meine jetzige Lösung sieht so aus:

die DB hat folgende Spalten

system_id int unique autoincrement // Normaler Zähler ist nicht unbedingt nötig tut aber auch nicht weh
system_identifier varchar[128] // Der Hash des mit sha512 und einem 2048bit Salt gehashte Unique ID des Kunden
system_data Text // Das Datenobject zu einem JSON-String gemacht und dann mit blockCypher RSA und 2048 bit public key encrypted. Dieses Paket enthält natürlich auch den system_identifier

Da der Server die keys nicht kennt, kann nun ruhig jemand den Server haken er wird mit den Daten trotzdem nichts anfangen können. Selbst wenn er die Client App hat, kann er weder den system_identifier hash noch kann er die system_data entschlüsseln.
Was ist wernn er den Salt aus der Client App decompiliert. Kann er dann den Hash rückrechnen? Bzw kann er dann die anderen Hashes in der DB einem eindeutigen systen_identifier zuweisen?

Damit müßte ich doch eigentlich die größtmögliche Sicherheit haben die man im Moment so bekommen kann oder?

Gruß

Claus

MyMattes · 10. Dezember 2014, 13:44

Sorry, Posting auf dem iPhone spinnt

Mattes

Edit: HTML-Tags entfernt...

gritsch · 10. Dezember 2014, 14:02

Thallius schrieb:

Also meine jetzige Lösung sieht so aus:

die DB hat folgende Spalten

system_id int unique autoincrement // Normaler Zähler ist nicht unbedingt nötig tut aber auch nicht weh
system_identifier varchar[128] // Der Hash des mit sha512 und einem 2048bit Salt gehashte Unique ID des Kunden
system_data Text // Das Datenobject zu einem JSON-String gemacht und dann mit blockCypher RSA und 2048 bit public key encrypted. Dieses Paket enthält natürlich auch den system_identifier

Da der Server die keys nicht kennt, kann nun ruhig jemand den Server haken er wird mit den Daten trotzdem nichts anfangen können. Selbst wenn er die Client App hat, kann er weder den system_identifier hash noch kann er die system_data entschlüsseln.
Was ist wernn er den Salt aus der Client App decompiliert. Kann er dann den Hash rückrechnen? Bzw kann er dann die anderen Hashes in der DB einem eindeutigen systen_identifier zuweisen?

Damit müßte ich doch eigentlich die größtmögliche Sicherheit haben die man im Moment so bekommen kann oder?

Gruß

Claus

eigentlich sollte man für jeden eintrag einen eigenen salt verwenden.
den kannst du dann auch in eine eigene spalte ablegen (den kann problemlos jeder lesen).
falls der kunde jetzt nur 3 einträge in die tabelle macht, kann man das aber auch vernachlässigen wenn der salt aus der userid generiert wird (die man hoffentlich nicht ändern kann ;-))

MyMattes · 10. Dezember 2014, 17:47

Thallius schrieb:

Ich kann das zwar nicht richtig lesen aber du hast da was falsch verstanden. Der Server bekommt KEINEN key nie und niemals. Der kann also auch nichts ver- oder entschlüsseln.

Ja, das Missverständnis beruhte auf Deiner Aussage

...dass ich bei jedem Verschlüsseln in der Java App einen neuen synchronen Key erzeuge, damit verschlüssele und dann diesen Key mit dem RSA Public key verschlüssele und das Ganze dann an denr Server schicke.

Aus dem Verschlüsseln mit dem "RSA Public key" hatte ich angenommen, dass Du den Key des Servers meinst, was hiesse, dass dieser wiederum entschlüsseln kann. Du meintest aber den öffentlichen Schlüssel des Clients... Hat sich also geklärt.

Mattes

Quellcode

Ähnliche Themen